Comments 16
Все проще, это NIH синдром. И можно продать "мы сделаем лучше", "мы статейку на хабр напишем".
Чтобы решить, что "нам нужен свой RAG" правильнее метрики сначала собрать и датасет с бенчмарками.
Переизобрели велосипед, но стал ли он от этого лучше?
Интересный взгляд, на статью. Но все зависит от того с какой стороны мы посмотрим на проблему. Заказчика, разработчика, интегратора или конечного пользователя.
Если говорить про NIH синдром в контексте RAG, то в первую очередь необходимо понимать цели и задачи реализации, если в ресурсоемкой разработке как правило принято довольствоваться имеющимся на рынке решениями, то для относительно доступных технологий и открытого стека заказчик за свои деньги хочет получить ровно то что ему необходимо по ТЗ, и это не путь готовых решений
В части метрик Вы затронули важную тему, и я соглашусь метрики и бенчмарки это основа любого RAG кейса. Без этого этапа любой вариант реализации лотерея. Другой вопрос что в статье намеренно не рассматриваются конкретные кейсы, а приводится только архитектурная часть разработки
Если оперировать категорией изобретения велосипеда, то они тоже бывают разные ), тут скорее разработка направлена в сторону унификации и упрощения с ориентиром на реальный рынок, состоящий из конкретных запросов
В этом контексте какие минусы у Elastic semantic_text + agent builder?
У Elastic сейчас действительно интересный стек для таких задач. Для многих кейсов это может быть очень быстрый способ собрать RAG. Особенно если уже используется для поиска. Это отличный старт для неспецифичных пайплайнов, но может стать проблемой когда Вам понадобится нестандартная логика фрагментации, специфический гибридный поиск с весами источников или доступ к промежуточным данным для отладки. здесь Elastic может быть неостаточно прозрачным. Кроме того Agent Builder в продакшене добавляет аналогичный слой абстракции
А чё Гита не будет ?:)
Зачем все это, если в РФ есть уже готовые продукты, которые позволяют для бизнеса в один клик начать пользоваться ими?
Например?
https://ai.orlime.ru как уже готовая система из коробки с RAG и ИИ
https://corpgpt.ru как no-code платформа для разработки ИИ сценариев
https://sologpt.ru для чатов и чат ботов
Это только 3 за пару минут поиска. На самом деле, видел еще штук 5 таких.
По всем ссылкам Вы привели приведены только SaaS решения, ограниченные по количеству документов, генераций и пользователям.
При этом ни по одной ссылке нет решений для локального развертывания, тем более за 15 минут от старта до первого запроса и без ограничений на обьем документов, количество запросов и пользователей.
Локализация основная проблема корпоративных систем, вряд ли условная бухгалтерия или отдел кадров вместе с производством, захочет слить все свои корпоративные документы (первичку, личные дела работников, технологические карты и регламенты) тому же ИП, которого Вы привели в одной из ссылок
Я вижу на их сайтах On-premise тариф (Enterprise) у corpgpt и ai orlime. У обоих есть размещение как SaaS так и он прем.
На соло такого не нашел, ну ок, убирем их из выборки.
Есть еще teamly сервис, тоже нашел.
Он прем под заказчика\по согласованию и онпрем из коробки это абсолютно разные продукты, не говоря о их стоимости, фактически по ссылкам корпоративные варианты с доступом по заявке\индивидуальному предложению через менеджеров, с согласованием, лицензиями, и это уже точно не в "один клик"
Вы писали "в РФ есть уже готовые продукты, которые позволяют для бизнеса в один клик начать пользоваться ими", я таких предложений найти не смог, он прем с стартом за 15 минут без ограничений на генерацию, количество документов и пользователей никто не предлагает
И да, кстати говоря, вы сильно удивитесь, насколько людям все равно где хранить свои данные. Вы же в гугл диске или яндексе храните личные данные? Может даже сканы паспорта? Или в облаке icloud / google? Или фото личного характера? С компаниями также. Если мы говорим про SMB — им без разницы. У них нет денег и желания ставить свои сервера. А вот уверенный средняк с оборотами от 1.5 млрд, им уже важен он-прем, безусловно.
Моя отсылка к критичности локализации это ответ на Ваш вопрос в стартовом комментарии "зачем все это".
Локализация, как на уровне хранения, так и генерации это ключевой момент для компаний, где безопасность и конфиденциальность критичны. И не всегда это зависит от оборота, например небольшая оптика или косметологическая клиника с мед. данными клиентов или учебный центр с персональными данными несовершеннолетних не менее остро нуждаются в закрытом контуре обработки данных.
Автор интересно сам себя опроверг. "обычно RAG состоит из 5 стандартных компонентов" vs "давайте мы напишем свой пайплайн на голых вызовах методовконкретных хранилищ ". Мысль "фреймворки порождение Сатаны" в какой то момент посещает любого, столкнувшегося с их сложностью и некоторым влиянием тяжеловесности абстракции. В случае Langchain - да, вам для сложных вещей не хватит его базовых модулей, но никто не запрещает написать свои и улучшить существующие. Плюс фреймворка - ваши элементы кода абстрагированы и работают по интерфейсам. Хотите вызывать методы векторного хранилища сами, так как ретривер стал подводить - ок, пользуйтесь vectorstore абстракцией. Можно и API обернуть в vectorstore, и в BaseChatModel, и в Retriever. Некоторых продвинутых ретриверов в langchain на виду нет, но сделать их на порядок проще из имеющихся. Плюсы фреймворка - собираем из кирпичиков (какие то из них вы писали сами) и переиспользуем. Надоело одно векторное хранилище-поставили другое. Главное убедиться, что методы классов работают. Обычно боттлнек все еще на уровне LLM. Если же пайплайн идеален, но важны даже миллисекунды- окей, можно экономить миллисекунды, переписываем с питона на С, Go или еще что быстрое-но оптимизацию алгоритма проще на питоне и делать. Отлаживать чужой код можно, но нежелательно, обычно ошибки пайплайна на уровне функций в цепочках, даже если они параллельны, то брейкпойнты ставим на них, смотрим обычно не дальше вызываемого метода класса, скажем для классов, наследующих от BaseChatModel, нет смысла дебажить ниже чем вызов _generate/_agenerate класса для работы с API вашей LLM. В общем, если вы не любите кошек - скорее всего, вы не умеете их готовить
Вы очень точно сформулировали позицию сторонников фреймворков, и в Ваших тезисах действительно есть рациональное зерно.
Фреймворк отличный вариант для старта, для нетребовательных пайплайнов и MVP экспериментов. На сложных пайпалайнах он уступает место низкоуровневой разработке. Речь идет не о старте на самописном RAG, а о архитектурных ограничениях фреймворков. Вы без труда найдете в Issue Langchain "Closed as not planned" кейсы, а также форки связанные с ограничением исходной архитектуры, публикации с лозунгами "Уходим с Langchain", где будут подробно описаны причины и конкретные кейсы.
Поэтому идея статьи скорее не "фреймворки зло", а "важно понимать, как это работает без фреймворка". Тогда уже осознанно выбираешь - оставить Langchain, написать свои компоненты или выбрать гибридный поход.
Большое спасибо автору. Мне статья очень понравилась. Интересная идея. На фреймворках и сторонних облачных сервисах действительно очень быстро и удобно делать MVP и закрывать какие-то стандатные истории. Но не всегда этого бывает достаточно.
Hybrid RAG knowledge base за 15 минут — почему пришлось собрать свою lite версию RAG и в чем опасность RAG фреймворков