Если у Вас нет Питона, но есть Керас-модель и Джава

[tzps]

Стыдно признать, но Slack-плагин для интеграции с StackOverflow мы подключили лишь пару недель назад. Так что вопроса на SO никто из нас даже не видел :(

Вы тикет на гитхабе не оставляли?

[usefultool]

Тикеты не оставлял. Только общался на gitter с разработчиками. Вопросов было много, ответы поступают не сразу, поэтому к вопросам приходилось относится очень избирательно.

[trolley813]

Если у вас нет питона, его не отравит сосед…
А серьезно, почему нельзя просто вызвать Python-код из Java (при необходимости сериализуя входные и выходные данные в какой-нибудь стандартный формат типа Apache Arrow)?

[usefultool]

Проблема не в вызове, а в том что для Python нужно подтягивать свое окружение под каждую платформу. На практике этот вариант имеет место быть. Тут уже вопрос больше не технический, а финансовый.

[roryorangepants]

Некоторые популярные фреймворки для нейронных сетей имеют порты для Java в виде JNI/JNA биндингов, но в таком случае возникает необходимость в сборке проекта под каждую архитектуру и преимущество Java в вопросе кроссплатформенности размывается. Этот нюанс может быть крайне важным в тиражируемых решениях.

Другой альтернативный подход — использование Jython для компиляции в байт-код Java; но и здесь есть недостаток — поддержка только 2-ой версии Python, а также ограниченность по возможности использования сторонних Python-библиотек.

Третий подход — наклепать за день микросервис на фласке и вызывать его.

[usefultool]

Как вариант. Если создается сервис у которого всего один прод, то можно и сервис с Flask развернуть, можно и вызвать удаленно Python-скрипт, предварительно установив окружение. Микросервисы хороши в проектных решениях. В продуктовых, где предлагается коробочное решение с высокой тиражируемостью это не лучшее решение с точки зрения архитектуры, поддержки, развертывания.

[roryorangepants]

В продуктовых, где предлагается коробочное решение с высокой тиражируемостью это не лучшее решение с точки зрения архитектуры, поддержки, развертывания.

Это отличное решение при условии, что и остальная часть продукта соответствует этой архитектуре, а поставляется всё это дело контейнерами.

[Stantin]

Если вы используете модель, только чтобы inference сделать, разумнее наверное обернуть один метод через JNI, чем продираться через конвертацию всей архитектуры?

[usefultool]

Подход с использованием модели через JNI/JNA увеличивает стоимость поддержки (насколько конкретно — в каждом отдельном случае необходимо считать), т.к. необходимо делать сборку и в последующем поддерживать под каждую архитектуру. Если все на одной архитектуре, такой проблемы нет — один раз собрал и протестировал.

Кстати говоря, фрэймворк DL4J не на чистом Java. Имеет декомпилированные классы на C++ и под капотом у него используется как раз JNI.