Hybrid RAG knowledge base за 15 минут — почему пришлось собрать свою lite версию RAG и в чем опасность RAG фреймворков

Автор интересно сам себя опроверг. "обычно RAG состоит из 5 стандартных компонентов" vs "давайте мы напишем свой пайплайн на голых вызовах методовконкретных хранилищ ". Мысль "фреймворки порождение Сатаны" в какой то момент посещает любого, столкнувшегося с их сложностью и некоторым влиянием тяжеловесности абстракции. В случае Langchain - да, вам для сложных вещей не хватит его базовых модулей, но никто не запрещает написать свои и улучшить существующие. Плюс фреймворка - ваши элементы кода абстрагированы и работают по интерфейсам. Хотите вызывать методы векторного хранилища сами, так как ретривер стал подводить - ок, пользуйтесь vectorstore абстракцией. Можно и API обернуть в vectorstore, и в BaseChatModel, и в Retriever. Некоторых продвинутых ретриверов в langchain на виду нет, но сделать их на порядок проще из имеющихся. Плюсы фреймворка - собираем из кирпичиков (какие то из них вы писали сами) и переиспользуем. Надоело одно векторное хранилище-поставили другое. Главное убедиться, что методы классов работают. Обычно боттлнек все еще на уровне LLM. Если же пайплайн идеален, но важны даже миллисекунды- окей, можно экономить миллисекунды, переписываем с питона на С, Go или еще что быстрое-но оптимизацию алгоритма проще на питоне и делать. Отлаживать чужой код можно, но нежелательно, обычно ошибки пайплайна на уровне функций в цепочках, даже если они параллельны, то брейкпойнты ставим на них, смотрим обычно не дальше вызываемого метода класса, скажем для классов, наследующих от BaseChatModel, нет смысла дебажить ниже чем вызов _generate/_agenerate класса для работы с API вашей LLM. В общем, если вы не любите кошек - скорее всего, вы не умеете их готовить