Comments 3
Из статьи не понял какой сервис за что отвечает и в чем практическая польза от размазывания такого приложения на отдельные микросервисы.
Хочется сказать что помимо langchaingo есть еще eino. Который как будто бы более серьезный, но с своими нюансами. Также хочется заметить что в этой задаче весьма удобно отделять rag часть в MCP модуль, представляющий из себя отдельный сервис.
Я ваял rag приложение -ассистента для ответов с учетом данных в базе знаний confluence, самое печальное что ембеддинг моделей с большим контекстом, которые могут в русский прям не густо. Да и в целом gguf варианты моделей, у ml энтузиастов как то не особо популярны.
На самом деле, я ни то чтобы сильно много задумывался о преимуществах разбиения на микросервисы подобных приложений. Но, в целом, по классике можно выделить масштабируемость. Как минимум мы можем развернуть несколько экземпляров генераторов с разными моделями и оркестрировать их через вышележащий сервис. Если проект вырастет - проще будет развивать.
Про eino не слышал, надо будет изучить, спасибо.
Да, тут.. преимущества от масштабирования разбиваются об ollama. Да и если использовать облачные решения, узким местом будет не производительность вашего сервиса, а скорость генерации облака. Собственно по этой причине мне кажется что микросервисы тут являются переусложнением.
Мне eino не особо понравился, просто потому что он куда сложнее налезает на голову. Плюс он использует нативный tool call от ollama, а не парсит ответы модели как это делает langchaingo. Это еще больше уменьшает пул моделей которые можно использовать
Полноценное RAG-приложение на Go — безумие?