Зависит от того, для какой цели используете. Но главное, решение очень просто подстраивать под свои задачи, буквально изменением промта и анализируемых источников. В любом слусае, под конкретный кейс нужна будет доработка.
Могу ошибаться, но термины несут в рамках статьи схожее значение. Как минимум они ближе друг к другу, чем к идентификации, хотя если смотреть строго терминологически, отличия у них есть. Немного уточнил в статье, спасибо.
Это только если есть иностранная карта. С ней можно еще несколько вариантов найти. В этом случае много что проще становится в плане хостинга n8n, которой нужно общаться с API LLM.
Red Hat OpenShift, AWS EKS, Google GKE это больше про Kubernetes. Остальное, скорее это контейнерные среды, но да, можно назвать их Serverless с определенным допущением
Есть профессиональные сервисы, которые на порядок глубже анализируют текст, чем MS Word. И их много разных. В одних хорошо грамотность проверить, в других стилистику поправить. MS Word только совсем примитивные ошибки подсвечивает. Иначе бы такой сервис как grammarly не стал бы супер успешным.
Возможно сделаем, но сейчас для Python нужен именно requirements.txt. И по второму вопросу - сейчас все взаимодействие (даже при загрузке через интерфейс) идет через git push с равертыванием в контейнере, и по соображениям безопасности прямого доступа в контейнер по ssh нет
Все бесплатные хостинги плохо подходят для работы 24/7. У них либо частые остановки проектов, либо долгий холодный старт, либо БД стираются, либо еще что-то из ограничений, причем часто неожиданных. Поэтому если нет желания потом переносить проект - лучше выбрать что то хорошее из недорогого сразу. Отладить на промо-периоде, и если понравится, перейти на платный тариф
Еще можно добавить, что способ деплоя не оптимален. Зачем грузить образ на Docker Hub, который отрубают для РФ, потом пляски с VPS. Воспользуйтесь Heroku, или российским аналогом - Amvera если иностранной карты нет. Просто запушите в Git код с докерфайлом, и все развернется и заработает. GitOps подход намного удобнее, три команды в консоли и все
Просто когда мы публикуем статью, просим ребят из команды написать комментарий-другой к ней, чтобы оживить дискуссию) Это создает отправную точку для обсуждения вопроса и люди более активно предлагают другие варианты решения задачи описанной в самой статье
Да, как вариант можно, это реально намного дешевле выйдет. Но Kong не для всего подходит. А если брать их open-source версию, она сильно уступает корпоративной
Кирилл, в продолжении комментария, спасибо, добавил информацию в статью. P.S. Тут можно править статьи, не обязательно в комментариях раскрывать уточнения)
Это сильно зависит от провайдера хостинга. Плюс надо правильно настроить.
Зависит от того, для какой цели используете. Но главное, решение очень просто подстраивать под свои задачи, буквально изменением промта и анализируемых источников. В любом слусае, под конкретный кейс нужна будет доработка.
Для RAG приложений ещё бывает полезно использовать MCP и такие фреймворки, как Langchain.
Могу ошибаться, но термины несут в рамках статьи схожее значение. Как минимум они ближе друг к другу, чем к идентификации, хотя если смотреть строго терминологически, отличия у них есть. Немного уточнил в статье, спасибо.
Это только если есть иностранная карта. С ней можно еще несколько вариантов найти. В этом случае много что проще становится в плане хостинга n8n, которой нужно общаться с API LLM.
Red Hat OpenShift, AWS EKS, Google GKE это больше про Kubernetes. Остальное, скорее это контейнерные среды, но да, можно назвать их Serverless с определенным допущением
Спасибо за внимательность. Поправил. Некоторые таблицы брал из англоязычных источников и просмотрел ошибку перевода. Еще раз благодарю
Есть профессиональные сервисы, которые на порядок глубже анализируют текст, чем MS Word. И их много разных. В одних хорошо грамотность проверить, в других стилистику поправить. MS Word только совсем примитивные ошибки подсвечивает. Иначе бы такой сервис как grammarly не стал бы супер успешным.
Возможно сделаем, но сейчас для Python нужен именно requirements.txt. И по второму вопросу - сейчас все взаимодействие (даже при загрузке через интерфейс) идет через git push с равертыванием в контейнере, и по соображениям безопасности прямого доступа в контейнер по ssh нет
Сложный проект так, конечно, не сделать, но небольшой прототип/демо - реально если не за пол часа, так за час организовать
Есть еще managed kubernetes от T1-Cloud и еще от пары провайдеров
Все бесплатные хостинги плохо подходят для работы 24/7. У них либо частые остановки проектов, либо долгий холодный старт, либо БД стираются, либо еще что-то из ограничений, причем часто неожиданных. Поэтому если нет желания потом переносить проект - лучше выбрать что то хорошее из недорогого сразу. Отладить на промо-периоде, и если понравится, перейти на платный тариф
Еще можно добавить, что способ деплоя не оптимален. Зачем грузить образ на Docker Hub, который отрубают для РФ, потом пляски с VPS. Воспользуйтесь Heroku, или российским аналогом - Amvera если иностранной карты нет. Просто запушите в Git код с докерфайлом, и все развернется и заработает. GitOps подход намного удобнее, три команды в консоли и все
Ложечки нашлись, осадочек остался. Лично мы пол дня в огне все перенастраивали. Обратно откатывать уже не будем. Доверия Докеру больше никакого нет
Просто когда мы публикуем статью, просим ребят из команды написать комментарий-другой к ней, чтобы оживить дискуссию) Это создает отправную точку для обсуждения вопроса и люди более активно предлагают другие варианты решения задачи описанной в самой статье
Да, как вариант можно, это реально намного дешевле выйдет. Но Kong не для всего подходит. А если брать их open-source версию, она сильно уступает корпоративной
В другой инструкции еще встречал, что для него нужно отдельно поднимать PostgreSQL
А если сохранить данные, не в указанную папку /data, а просто рядом с кодом в директории, что произойдет в данном случае?
А обязательно писать Dockerfile для деплоя в данном случае?
Кирилл, в продолжении комментария, спасибо, добавил информацию в статью. P.S. Тут можно править статьи, не обязательно в комментариях раскрывать уточнения)