SavePearlHarbor

Зачем вашей LLM внешняя память: полный разбор RAG-системы от теории до продакшена

—

от автора

admin

RAG для бизнеса и разработчиков: архитектура, Python-туториал, стоимость и кейсы

Что такое RAG-система? Retrieval-Augmented Generation — «генерация, дополненная извлечением»: так называют архитектурный подход, при котором модель усиливает ответы, динамично дополняя внутренние знания актуальной информацией из внешних источников. В практическом смысле: RAG — это способ увеличить релевантность ответов языковой модели без хлопот с переобучением.

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

Зачем нужна RAG, если есть Chat GPT

Стандартная языковая модель — будь то GPT или любая другая LLM — знает только то, что было в данных на момент обучения, отсюда проблемы и ограничения.

  • Если в компании вышел новый продукт, изменилась политика или обновилась документация — модель об этом не знает. 

  • Так как публичные модели обучаются на открытых данных интернета, им неведома внутренняя терминология компании, ее процессы, клиентская база и проприетарные документы. 

  • А когда точных данных нет — модель склонна активно «додумывать» факты — галлюцинировать.

Разделяя модель и знания, RAG решает все три проблемы одновременно. База знаний существует отдельно от модели и обновляется постоянно, но без переобучения. Модель не пытается вспомнить или придумать ответ, а получает его в виде конкретного фрагмента текста — а когда источник известен, фантазировать нет нужды.

RAG и fine-tuning: в чем разница

Когда возникает задача «научить модель работать с нашими данными», первой мыслью обычно становится: а давайте просто переучим ее на наших документах. Этот подход называется fine-tuning (тонкая настройка): модель специально «прогоняют» через нужные материалы, чтобы новые знания стали ее частью. Метод рабочий, но в корпоративной реальности часто оказывается неудобным.

  • Во-первых: fine-tuning — дорогая и медленная операция. Каждый раз, когда данные меняются — а в бизнесе они меняются постоянно — нужно переучивать модель заново, при этом стоимость одного такого цикла для крупной модели может исчисляться тысячами долларов, а время — днями и даже неделями.

  • Во-вторых, дообучение способно непредсказуемо изменить поведение модели: она может «забыть» часть прежних навыков или переобучиться на узкий домен — подстроиться под обучающую выборку, забыв то, что знала раньше. У данного эффекта есть даже свое название — catastrophic forgetting — катастрофическое забывание.

RAG работает иначе: модель всегда остается неизменной, не впадая в деменцию при трансформации базы знаний. Изменилась политика компании — обновили файл — он как равный встал в ряд остальных и сразу доступен для поиска. Никакого переобучения, никаких простоев.

Если упрощать: fine-tuning учит модель — как говорить, RAG — что говорить. В бизнесе выбор между ними чаще всего сводится к простому вопросу: что должно меняться чаще — стиль ответов или сами данные? Если данные — выбор очевиден. А если параллельно нужно еще и «приручить» тон модели, ничто не мешает использовать оба подхода в одной системе.

Архитектура RAG-системы

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

Источник данных

Все начинается с контента. Это могут быть PDF-документы, страницы корпоративной wiki, таблицы, базы знаний, тикеты из службы поддержки и веб-страницы. RAG не предъявляет жестких ограничений к формату — важно лишь, чтобы данные можно было извлечь и преобразовать в текст.

Ключевое правило этапа: качество источника определяет качество ответов. Идеальный документ для RAG — структурированный, актуальный и однозначный: четкие заголовки, последняя версия, никаких противоречий с другими файлами в базе. Чем ближе материалы к этому стандарту, тем точнее система будет отвечать. Если же документы устаревшие, небрежно структурированы или противоречат друг другу — система будет воспроизводить те же проблемы в ответах. Тезис «мусор на входе — мусор на выходе» работает здесь в полную силу.

Чанкинг: почему текст нельзя брать целиком

Целый документ — не самая лучшая единица поиска: слишком много лишнего текста вокруг факта, и модель это лишнее тоже читает. Представьте, что вам нужно отыскать цитату в книге, не зная страницы. Поэтому, чтобы упростить поиск, документы разбиваются на небольшие смысловые фрагменты — чанки (от англ. chunk — кусок).

Размер чанка — ключевой параметр системы. Слишком маленький фрагмент (100–200 символов) теряет контекст: вырванная из середины фраза будет лишена смысла. Слишком большой (3000+ символов) снижает точность поиска — релевантная информация тонет в лишнем тексте. Оптимальным считается диапазон 500–1500 символов с перекрытием между соседними чанками в 10–20% — так фраза, разорванная на стыке двух чанков, не потеряет смысла.

Разбить текст на чанки можно не только по размеру. Существуют стратегии разделения по блокам, по предложениям, по заголовкам, по семантической близости. 

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

Эмбеддинги: как текст превращается в числа

После чанкинга у нас есть набор кусочков текста — но искать по тексту напрямую система не умеет. Ей нужен «отпечаток смысла» каждого фрагмента в виде набора чисел. Такой отпечаток называется embedding — числовой вектор, в котором зашифрован смысл текста.

Представьте, что каждый фрагмент текста — это точка в многомерном пространстве. Тексты с близким смыслом оказываются рядом, с далеким — на расстоянии. «Как оформить отпуск» и «заявление на отгул» будут близко друг к другу, а «рецепт борща» — совсем в другой части пространства. 

Что особенно важно — система оценивает именно смысл, а не совпадение слов. В обычном поиске «отпуск» и «отгул» — два слова с разным смыслом, и одно по другому не найдется. В векторном пространстве они оказываются рядом, потому что описывают одну и ту же ситуацию: человек хочет на время не работать. То же самое с фразами: «как уволиться» и «процедура расторжения трудового договора» формально не имеют ни одного общего слова, но смысл у них один — и в векторной модели они окажутся в одной области.

Именно это свойство делает RAG принципиально умнее обычного поиска: система находит релевантные фрагменты даже тогда, когда сотрудник сформулировал запрос совсем не теми словами, которые использованы в документе. Бухгалтер пишет «командировочные», в регламенте — «возмещение расходов на служебные поездки» — для человека это одно и то же, и теперь это одно и то же для машины.

Для создания эмбеддингов используются специальные модели-переводчики — например, text-embedding-3-small от OpenAI или multilingual-e5-large для работы с русскоязычными текстами. Каждый чанк прогоняется через такую модель и сохраняется в векторной базе данных уже в числовом виде.

Векторная база данных и поиск по смыслу

Векторная база данных — это специализированное хранилище, оптимизированное для единственной задачи: быстро находить векторы, близкие к заданному. Когда пользователь формулирует вопрос, его текст тоже превращается в вектор, после чего база возвращает ему N ближайших чанков — тех, чей смысл наиболее близок к теме.

Близость измеряется через косинусное сходство (cosine similarity). Математически это угол между двумя векторами: чем он меньше — тем ближе смыслы, и тем выше оценка релевантности. Значение 1.0 означает полное совпадение, 0 — полное отсутствие связи. Пороговым считается значение от 0.7 и выше.

Самые популярные сейчас векторные базы: 

  • Qdrant — производительное open-source решение с удобным API.

  • Weaviate — с поддержкой гибридного поиска.

  • FAISS от Meta — библиотека для локального использования без серверной инфраструктуры. 

Отдельно упомянем pgvector — расширение для PostgreSQL, превращающее обычную реляционную базу в полноценную векторную. Решение будет особенно полезно компаниям, у которых PostgreSQL уже внедрен в инфраструктуру: не нужно поднимать отдельный сервис, векторный поиск работает рядом с привычными SQL-таблицами. 

LLM: финальная генерация

Когда релевантные фрагменты найдены, они вместе с исходным вопросом передаются в языковую модель. Система получает не просто вопрос, а готовый контекст: «Вот выдержки из документов, вот вопрос пользователя — ответь, опираясь на эти данные». Именно здесь и происходит то, что отличает RAG от обычного поиска: модель не просто возвращает найденный текст, а синтезирует связный ответ, при необходимости объединяя информацию из нескольких фрагментов.

В базовой схеме векторный поиск определяет топ-N чанков по косинусному сходству. Этот метод быстр, но не всегда точен: два текста могут быть статистически близки, но один из них — более релевантен для конкретного вопроса.

Здесь помогает Reranker — дополнительная модель-ранжировщик (Cross-Encoder), которая получает пары «запрос + чанк» и заново оценивает их релевантность, уже с пониманием смысловой связи между ними. Векторный поиск делает первичный отбор быстро и грубо — как предфильтр, который пропускает кандидатов «примерно по теме». Reranker же работает медленнее и тщательнее, поэтому его не запускают по всей базе, а применяют только к 20–50 отобранных фрагментов.

В итоге языковая модель оперирует не просто списком похожих текстов, а использует дважды проверенные данные, выдавая 3–5 действительно лучших ответов. Чем точнее этот финальный отбор, тем меньше шансов, что модель собьется на постороннем фрагменте и уйдет в сторону. Среди популярных решений — Cohere Rerank, BGE-reranker и cross-encoder от Sentence Transformers.

Naive RAG и продвинутые подходы: Advanced, Graph, Fusion и Agentic RAG

Naive RAG — базовая, «наивная» реализация, которая справляется с большинством типовых задач, но у нее есть ограничения. Простой запрос к векторной базе данных работает стабильно, когда вопрос четкий, а документы хорошо структурированы. Но как только вопросы становятся составными, источники разрозненными и появляется необходимость в сложных логических рассуждениях, Naive RAG начинает сбоить. Для таких сценариев и созданы продвинутые архитектуры.

Advanced RAG

Advanced RAG (Advanced Retrieval‑Augmented Generation — улучшенная генерация ответа, дополненная результатами поиска) — это не отдельный фреймворк, а надстройка над базовой схемой. Если Naive RAG работает по простой логике «получил вопрос → нашел похожие фрагменты → передал модели», то Advanced RAG добавляет дополнительные слои обработки на каждом шаге: умнее формулирует поисковый запрос, ищет сразу несколькими способами параллельно, перепроверяет найденное и отбирает лучшее. Эти улучшения можно применять по отдельности или в комбинации — в зависимости от того, где именно базовая схема дает сбой.

Собирается такая надстройка по следующим направлениям:

  • Переформулировка запроса — прежде чем идти в поиск, модель сама придумывает несколько вариантов исходного вопроса и обрабатывает каждый отдельно. Это решает одну из главных слабостей Naive RAG: пользователь спросил одними словами, а в документах ответ записан другими — и базовый поиск его не находит. Несколько формулировок страхуют от такой ситуации.

  • Гибридный поиск — вместо одного типа поиска работают сразу два. Векторный находит фрагменты по смыслу, полнотекстовый (BM25) — по точным совпадениям: артикулам, именам, специфической терминологии, номерам договоров. Naive RAG умеет только первое, и на запросах вроде «найди договор №А-127/24» он буксует. Гибридный подход закрывает обе ситуации.

  • Reranker (о нем говорили выше) в Advanced RAG становится обязательным звеном. После гибридного поиска кандидатов оказывается заметно больше, чем в базовой схеме, и Cross-Encoder отбирает из них действительно лучшие. Без этого шага в контекст модели попадает лишний «шум», и качество ответа падает.

Advanced RAG оправдан там, где высока цена ошибки, а работа связана с большими массивами документов (от нескольких тысяч страниц), включает запросы с неочевидной формулировкой и предъявляет высокие требования к точности ответа.

Graph RAG: когда связи важнее фрагментов

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

Graph RAG помогает решить эту задачу, он строит поверх документов карту связей: люди, компании, продукты и события превращаются в узлы, а отношения между ними («работает в», «принял решение о», «повлиял на») — в мосты — линии, соединяющие эти узлы. Когда поступает запрос, система не перебирает похожие абзацы, а переходит от факта к факту, следуя логическим связям, и собирает ответ в виде цепочки, а не набора явных и неявных совпадений.

Пример: вопрос «Как решение совета директоров в 2022 году повлияло на текущую продуктовую стратегию?» требует связать несколько документов цепочкой причинно-следственных связей. Векторный поиск найдет фрагменты о совете директоров и о продуктовой стратегии, но не соединит их: система не понимает, что между ними есть причинно-следственная связь. 

Graph RAG при индексировании извлекает из документов связи: 

  • «совет директоров → принял решение → сократить линейку продуктов → в 2022 году», «сокращение линейки → повлекло за собой → пересмотр продуктовой стратегии → в 2023 году». 

Эти связи сохраняются в виде именованных отношений между конкретными сущностями. Когда поступает запрос, система не просто ищет похожие фрагменты — она проходит по цепочке графа от одного узла к другому и собирает полный путь от причины к следствию. Именно поэтому ответ получается связным, а не набором цитат.

Эталонная реализация подобной архитектуры — проект Microsoft GraphRAG, доступный по адресу github.com/microsoft/graphrag. Компания активно развивает его и регулярно выкладывает результаты тестов, которые демонстрируют превосходство GraphRAG над Naive в задачах с многоуровневыми зависимостями.

Когда применять: аналитика больших корпоративных архивов, юридические и финансовые документы с перекрестными ссылками, задачи, требующие понимания причинно-следственных связей.

RAG Fusion: несколько запросов вместо одного

Опытный аналитик, изучая тему, не ограничивается одним поисковым запросом — он перебирает формулировки, пока не получит полную картину. RAG Fusion делает то же самое автоматически.

Система автоматически генерирует несколько вариантов исходного запроса, по каждому из них выполняет отдельный поиск, а затем объединяет результаты с помощью алгоритма Reciprocal Rank Fusion (RRF). Суть его проста: документ, который часто встречается сразу в нескольких списках, получает высокий итоговый рейтинг. Случайные «попадания» из отдельных запросов нивелируются, а стабильно релевантные фрагменты поднимаются наверх.

Эффект — значительно более устойчивый и полный контекст для языковой модели, особенно при работе с расплывчатыми или неоднозначными запросами.

Когда применять: пользовательские интерфейсы, в которых нельзя требовать от пользователя точных формулировок; исследовательские и аналитические задачи, в которых важно не упустить релевантную информацию.

Agentic RAG: модель сама управляет поиском

В предыдущих подходах процесс поиска был детерминированным: запрос → поиск → передача в языковую модель. Agentic RAG меняет этот подход: языковая модель сама решает, что искать, когда остановиться и достаточно ли найденной информации для ответа.

Агент работает итеративно. Получив вопрос, он формирует первый поисковый запрос, анализирует результаты, определяет, чего не хватает, формирует уточняющий запрос — и так до тех пор, пока не соберет достаточно информации для полного ответа. По сути, это исследовательский процесс, а не разовый поиск.

Такой подход открывает возможности, недоступные для линейных архитектур: работа с несколькими источниками данных, сравнение информации из разных баз, декомпозиция сложных вопросов на подзадачи. Обратная сторона — непредсказуемое время ответа и более высокая стоимость логического вывода: каждый шаг рассуждения — это отдельный вызов модели.

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

RAG для бизнеса

Полнотекстовый поиск — это то, к чему все привыкли: вы вводите слова в строку, а система находит документы, в которых эти слова встречаются. Так работает поиск в Word, корпоративных файловых системах, базах данных вроде Confluence или 1С. Технология проверенная и надежная, но принципиальная разница между ней и RAG-системой заключается в том, что происходит после поиска.

При стандартной схеме система закрывает запрос списком документов или фрагментов — пользователь вынужден сам читать, анализировать и если требуется, то и формулировать ответ. RAG делает это за человека, возвращая уже готовый ответ. 

  • Вместо логики «найди, где написано», здесь работает принцип «скажи, что делать».

Второе принципиальное отличие — как именно ведется поиск информации. Полнотекстовый движок реагирует только на точное совпадение слов. Запрос «как досрочно расторгнуть контракт» не затронет документ, в котором написано «условия расторжения договора до истечения срока», хотя, по сути, речь идет об одном и том же. RAG-система ищет не по словам, а по смыслу: для нее разные формулировки одного и того же запроса равнозначны.

Наконец, классический подход не умеет объединять данные из нескольких документов — он показывает их по отдельности. RAG-система делает это по умолчанию, становясь незаменимой там, где правильный ответ нужно собирать из нескольких документов-источников.

Ниже приведены четыре сценария, в которых преимущества RAG перед обычным поиском проявляются особенно ярко. К каждому из них прилагаются реалистичные цифры, отражающие стоимость внедрения.

Корпоративный чат-бот для работы с внутренней документацией

Корпоративная документация — классический пример информации, которая формально есть, но практически недоступна. Сотрудники часами мучат поиск, копаясь в регламентах, а HR-отдел ежедневно отвечает на десятки однотипных вопросов об отпусках, льготах и больничных. Обычная модель здесь помогает слабо: она находит документ, но не отвечает на вопрос. 

RAG-система устраняет этот разрыв. Она индексирует весь массив внутренних материалов — регламенты, приказы, часто задаваемые вопросы, вводные документы — и принимает вопросы в свободной форме, опуская необходимость знать точное название документа или формулировку из него, отвечая не ссылкой на источник, а готовой рекомендацией (обосновывая ссылкой на конкретный раздел) — сотруднику остается только проверить и применить. 

Что особенно ценно для бизнеса: база обновляется бесшовно. Появился новый регламент, документ, отдел — система мгновенно включит его в работу, без переобучения и технических работ.

По данным компаний, внедривших такие решения, нагрузка на HR- и административные службы по типовым запросам снижается на 30–50%, а в отдельных проектах показатель доходит до 80%. Параллельно ускоряется адаптация новичков: вместо «глупых» вопросов занятым коллегам сотрудник получает умного помощника с актуальными ответами и ссылками на первоисточники.

Поддержка клиентов

Служба поддержки — одна из сфер, где эффект от RAG наиболее ощутим. Получая вопрос, операторы вынуждены тратить время не только на поиск информации в зачастую разрозненных базах, статьях и инструкциях, но также анализировать их, а затем формулировать ответы. Каждое типовое обращение превращается в ритуал: открыть пять вкладок, пробежаться глазами по истории похожих тикетов, собрать ответ из трех источников. 

RAG-система делает это за человека: объединяет базу знаний, историю решенных тикетов и техническую документацию, за секунды выдавая готовый черновик ответа со ссылкой на источники. Сотруднику остается только проверить и нажать «Отправить».

Эффективность такого взаимодействия подтверждена множеством кейсов. 

  • LinkedIn создал гибридное решение на основе RAG и графа знаний: система не просто ищет похожие обращения в архиве, а выстраивает связи между ними. В результате внедрения среднее время решения тикета сократилось на 28%. 

  • В HubSpot RAG-ассистент извлекает ответы из более чем 700 часов образовательного контента академии и подсказывает их прямо в момент обращения — пользователи получают ответ без участия оператора, а служба поддержки концентрируется на действительно сложных случаях.

  • Показателен пример российской платформы Robovoice: после внедрения LLM+RAG скорость обработки запросов сократилась с 10 минут до 8–15 секунд (Карл!!!), а доля кейсов, которые система закрывает без передачи оператору, выросла с 20% до 90%. 

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

Если оператор обрабатывает 60–80 обращений в смену — а это типичная норма, — себестоимость одного ответа составляет 50–100 рублей. При потоке в 10 000 обращений в месяц это 500 000–1 000 000 рублей только на фонд оплаты труда. Это цифры для небольшой компании — крупный интернет-магазин или банк оперируют уже многомиллиардными бюджетами.

RAG-система меняет эту арифметику. Стоимость автоматического ответа — копейки: при использовании облачного API — это сотые доли рубля за запрос, при локальном развертывании — практически ноль. Когда автоматика берет на себя 80–90% типовых обращений, штат службы поддержки можно либо сократить, либо перенаправить высвободившиеся ресурсы на сложные кейсы и работу с лояльностью клиентов. И в обоих случаях это прямая экономия — миллионы рублей в год для среднего бизнеса, десятки и сотни миллионов для крупного.

Поиск по технической документации и базам знаний

Инженерная документация и регламенты бухгалтеров имеют много общего: они есть, их масса, и почти всегда не там, где нужно. По данным опроса Stack Overflow 2024, 61% разработчиков тратят на поиск ответов более 30 минут в день, а каждый четвертый — больше часа. В пересчете на месяц это 10–20 часов чистого времени, которое оплачивается как разработка, но фактически уходит на чтение спецификаций, API-справок и архивов задач.

При средней зарплате российского бэкенд-инженера в 200 000–350 000 рублей стоимость одного «потерянного» часа, с учетом налогов и накладных расходов, составляет около 1500–2500 рублей. Команда из 20 инженеров теряет на поиске информации по самым скромным оценкам 600 000 рублей в месяц, или 7 миллионов в год, — и это без косвенного ущерба в виде замедления работы над проектами и срыва сроков.

Показывая вместо списка ссылок на 10 страниц готовый ответ, RAG-система исправляет такую порочную практику. По данным banki.ru, внедривших RAG-бота на базе Confluence, инструмент стал основным каналом получения информации внутри инженерных команд — и это уже не уникальная, а типичная история.

Отдельный эффект — снижение зависимости от «человека, который все знает». Экспертиза, сосредоточенная ранее в руках одного-двух специалистов, становится доступна всей команде: новички перестают дергать старших коллег по типовым вопросам, а те освобождаются для решения задач, ради которых их и нанимали.

Анализ юридических и финансовых документов

Юридическая и финансовая аналитика — одна из тех сфер, где RAG дает наибольший практический эффект. Здесь работа строится вокруг массивов документов, в которых нужно не просто найти упоминание, а сопоставить условия, выявить расхождения и проверить соответствие стандартам. Просмотр сотен договоров вручную растягивается на дни, а при таких объемах человеческая ошибка становится не риском, а статистической погрешностью. В условиях российской судебной практики, цена этой ошибки заметно возрастает.

RAG-система позволяет задавать точечные вопросы по всему массиву документов: «В каких договорах предусмотрена неустойка за нарушение сроков поставки?», «Есть ли расхождения между этим контрактом и нашей типовой формой?», «Чем условия ответственности контрагента отличаются от наших стандартов?» В ответ вы получите выдержки с указанием пункта, страницы и источника, готовые к проверке юристом. Полнотекстовый поиск такую задачу не решает в принципе: он находит упоминания слов, а не сопоставляет смысл условий.

  • Юридическая фирма Addleshaw Goddard опубликовала исследование, в котором показала, что грамотно настроенная RAG-система повышает точность анализа коммерческих контрактов с 74% до 95% — и это без дообучения базовой модели, только за счет правильной архитектуры поиска. 

  • Платформа CustomGPT.ai сообщает о сокращении времени на юридические исследования на 75% и о том, что юристы тратят 23% оплачиваемых часов на просмотр документов вручную — то самое время, которое возвращает RAG. 

  • По данным французских юристов, время поиска информации по делу сокращается с 3 часов до 20 минут, а период адаптации младшего юриста — с 6 месяцев до 2.

Для бизнеса это означает конкретное сокращение оплачиваемых часов на комплексную юридическую и финансовую экспертизу, то есть прямую экономию для клиентов и более высокую прибыль для самой фирмы. Процедуры, которые раньше занимали несколько дней, теперь укладываются в несколько часов. И главное — снижается риск упустить какую-то деталь, цена которой может перевесить весь бюджет на внедрение.

Сколько стоит RAG-система

Стоимость RAG-системы складывается из двух частей: разработки и расходов на эксплуатацию. Рынок российских разработок чат-ботов и ИИ-ассистентов сложился в 2024–2025 годах и остается вполне предсказуемым: 

  • простые типовые решения стоят 200–300 тысяч рублей;

  • более сложные кастомные ИИ-боты с RAG — 500–800 тысяч; 

  • корпоративные системы с интеграцией — от 1 до 2 миллионов и выше. 

По сводным данным Aimylogic, средняя стоимость чат-бота на заказ — около 227 000 рублей. Однако для ИИ-ассистента с RAG-логикой это нижняя планка, и она быстро смещается вверх по мере роста требований.

Простое решение на готовых фреймворках — LangChain, облачная векторная база, GigaChat или YandexGPT — обойдется сейчас в 300 000–800 000 рублей при заказе у подрядчика и займет 1–2 месяца работы одного бэкенд-разработчика с опытом в машинном обучении. 

В этот диапазон помещаются типичные задачи: HR-бот для внутренней документации предприятия среднего масштаба, система для поддержки интернет-магазина с базой до 10 000 SKU, помощник для службы делопроизводства. По данным агентства march-code, продвинутый ИИ-бот с RAG и регулярно обновляемой базой знаний стоит около 500–800 тысяч рублей и собирается за 8–12 недель.

Сложные решения с индивидуальной архитектурой, интеграцией с CRM, ERP или 1С и продвинутыми подходами вроде Graph RAG или Agentic RAG стоят дороже — 1,5–5 миллионов рублей. В эту категорию попадают системы анализа юридических документов с доступом к нескольким внутренним базам, ассистент для крупного ретейлера с подключением к складу и заказам, поисковик по архивам банка или страховой компании. Корпоративные проекты с собственной дообученной моделью и локальным развертыванием стоят от 800 тысяч до 2 миллионов на разработку и 3–6 месяцев на запуск.

Основная статья расходов при эксплуатации — вызовы API языковой модели. Здесь у российского бизнеса есть выбор: 

  • западные сервисы вроде GPT-4o-mini (0,15 доллара за миллион входящих токенов, оплата с зарубежной карты или через посредников) и российские аналоги, доступные напрямую и без VPN. 

По тарифам GigaChat от Сбера генерация в облегченной модели Lite стоит 200 рублей за миллион токенов, в продвинутой Pro — 1500 рублей, в топовой Max — около 1900 рублей. YandexGPT держит сопоставимую планку — от 200 до 1200 рублей за миллион токенов в зависимости от режима.

В переводе на бизнес-язык: содержание корпоративного чат-бота с нагрузкой 1 тыс. запросов в день обойдется в сумму от 5 до 20 тыс. рублей в месяц на API. Активная служба поддержки с десятками тысяч обращений — это уже 50–150 тыс. рублей в месяц. Для сравнения: оператор первой линии обходится компании в 70 000–110 000 рублей в месяц, и это без учета рабочего места и обучения. Когда RAG берет на себя 80% типовых обращений, экономия на фонде оплаты труда в десятки раз перекрывает возможные траты на API.

Если переменные расходы критичны — а это особенно актуально для компаний, которые связаны нормативными ограничениями на передачу данных за пределы организации, — есть классическая альтернатива: локальное решение с собственной моделью и локальной же векторной базой. Оно позволяет избежать переменных расходов на токены, но требует наличия собственного сервера с графическим процессором и команды для поддержки. Окупаемость такой инфраструктуры — 6–12 месяцев при стабильно высокой нагрузке.

Как выбрать фреймворк RAG под свои задачи

Фреймворк в контексте RAG — это готовый набор инструментов, призванный решать типовые задачи: подключение к векторным базам, управление чанками, построение цепочек обработки запросов, интеграцию с языковыми моделями. Без фреймворка каждую такую деталь пришлось бы писать вручную, что вылилось бы в дополнительные месяцы разработки и зарплату еще одного-двух инженеров.

Почему к выбору фреймворка для RAG нужно быть внимательным? Потому что от него напрямую зависит, сколько времени и денег уйдет на запуск, насколько легко будет дорабатывать систему через год и не станет ли проект вотчиной узкого круга специалистов. Короче: смена фреймворка в работающем бизнесе — очень болезненная тема, от души советуем правильно выбрать его сразу.

Если сравнивать фреймворки для RAG по количеству пользователей и активности сообществ на GitHub, безусловными лидерами являются три варианта: LangChain, LlamaIndex и Haystack.

LangChain — самый популярный и универсальный фреймворк. У него больше всего интеграций с другими сервисами, на его основе собрано больше всего готовых решений, под него проще нанять разработчиков. Хорошо подходит для сложных, нестандартных проектов: ассистентов с агентным поведением, многошаговой логикой, нетипичными источниками данных. Минус — фреймворк часто обновляется, и код, написанный год назад, может потребовать доработки. 

LlamaIndex заточен именно под RAG, в нем нет ничего лишнего. Если задача — найти ответ в документах и показать пользователю, это самый быстрый способ получить результат. Подходит для типовых сценариев: внутренний чат-бот, поиск по вики, помощник службы поддержки. Менее гибок, когда нужна нестандартная логика, но в большинстве бизнес-процессов она и не требуется.

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

Пять вопросов перед выбором стека

Прежде чем остановиться на конкретном фреймворке, полезно ответить на несколько вопросов — они помогут быстро отсеять лишнее и не дадут переплачивать за функционал.

  • Сколько у вас документов? Если речь о нескольких тысячах файлов — внутренних регламентах, инструкциях, типовых договорах, — подойдет любой фреймворк с локальной векторной базой. Если же вопрос стоит о сотнях тысяч (архив корпоративной переписки, база тикетов службы поддержки за пять лет, полный каталог товаров), нужна более серьезная инфраструктура — Qdrant, Weaviate или Pinecone, способные масштабироваться без снижения скорости работы.

  • Как часто меняются данные? Если регламенты обновляются раз в квартал, это одно. Если в базу каждый день добавляются новые тикеты, договоры и письма, — другое. Во втором случае важно, чтобы система умела добавлять новые документы без полной перестройки индекса. LlamaIndex и Haystack делают это «из коробки», без лишних движений.

  • Готовы ли вы держать инфраструктуру у себя? Облачные решения позволяют запустить проект за несколько недель и избавляют от необходимости решать вопросы с серверами, обновлениями и резервированием, но привязывают к ежемесячной оплате API. Локальное развертывание обходится дешевле в долгосрочной перспективе и дает полный контроль, но требует собственных серверов с графическими процессорами и инженеров, которые будут их обслуживать. Хороший ориентир: если планируется более нескольких тысяч запросов в день, выгоднее использовать собственную инфраструктуру.

  • С чем уже работает команда? Если разработчики уверенно пишут на Python, но никогда не работали с машинным обучением, LlamaIndex подойдет лучше всего. Если у команды уже есть опыт работы с LangChain, не стоит менять инструмент ради абстрактных преимуществ — переучивание сведет на нет всю выгоду.

  • Что с безопасностью данных? Этот вопрос стоит задать в самом начале — он сразу отсеивает половину вариантов. Для банков, медицинских учреждений, государственных структур и любого бизнеса, связанного с коммерческой тайной, отправка корпоративных документов в облачный API — нерабочий сценарий. В таких проектах система изначально строится вокруг локального развертывания: собственные модели, собственные серверы, никакого внешнего трафика. На старте это обходится дороже, но снимает целый ряд рисков, связанных с регулированием и утечками.

Рекомендации по стеку под конкретные сценарии

Запуск RAG локально: без облака и внешних API

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

Локальная RAG-система собирается из тех же компонентов, что и облачная: языковая модель, эмбеддинг-модель, векторная база, фреймворк-оркестратор, но есть одно принципиальное отличие — все они работают на собственных серверах компании. Никаких обращений к OpenAI, никакой передачи данных вовне, никакой зависимости от стабильности интернета. Параллельно решается еще одна задача — экономическая: когда нагрузка возрастает до десятков тысяч запросов в день, ежемесячная плата за API начинает заметно превышать стоимость собственного оборудования.

Стек для локального запуска

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

Первый компонент — языковая модель. Здесь работает Ollama — платформа, которая позволяет развернуть саму модель на собственном сервере компании или даже на рабочем ноутбуке. Запросы пользователей в этом случае не отправляются в облако OpenAI и не покидают контур организации. Для государственного сектора, банков и любого бизнеса, работающего с конфиденциальными данными, это принципиальный момент. Ollama поддерживает десятки открытых моделей — Llama, Mistral, Qwen — и не требует лицензионных отчислений.

Второй — векторная база данных или хранилище «оцифрованного смысла» документов. На этом месте обычно стоит ChromaDB — аналог облачных сервисов вроде Pinecone, только работающий на оборудовании пользователя. Для пилотных проектов и тестовых баз с парой тысяч документов ее более чем достаточно. Правда есть нюанс: в основе ChromaDB лежит SQLite, то есть фактически один файл, который в каждый момент времени может выполнять только одну операцию. При больших нагрузках такая схема может стать узким местом. 

Для продакшн-сценариев лучше подходит pgvector, запущенный в Docker-контейнере, — он работает значительно быстрее и не сталкивается с ограничениями файловой блокировки. Если же объем данных вырастает до сотен тысяч документов, разумным решением будет переход на Qdrant.

Третий компонент — эмбеддинговая модель — отдельная нейросеть-«переводчик», которая переводит текст в векторы для поиска. Вместо облачных API здесь используется библиотека sentence-transformers с открытыми моделями. 

В большинстве ситуаций для русскоязычных документов на старте подходит multilingual-e5-large от Microsoft — она обучена на многоязычных данных и корректно работает с кириллицей. Однако на наш взгляд, проблему русского языка лучше всего решает BGE-M3 — эта модель чуть тяжелее по требованиям к ресурсам, зато по качеству поиска заметно превосходит e5. И на локальной машине, и на сервере она запускается без особых проблем. 

Почему это важно: если выбрать модель без поддержки русского языка, система будет искать информацию по формальным совпадениям символов, а не по смыслу — качество поиска заметно пострадает.

Этого, как правило, достаточно, чтобы собрать полностью автономную RAG-систему без подписок, без ежемесячных счетов за API, без зависимости от внешних сервисов. Единственное вложение — собственное время и оборудование.

Как это выглядит на практике

Ниже — минимальный рабочий пример, который разработчик может запустить на своем компьютере за 10–15 минут. По объему кода понятно, что локальная RAG-система не требует месяцев разработки. Это буквально один файл.

Все начинается с установки Ollama (языковая модель), ChromaDB (хранилище векторов) и embedding-модели. Три команды в терминале — и инфраструктура готова.

После установки — сам пайплайн. Код ниже делает ровно то, что было описано в разделе об архитектуре, только локально. Цветные метки показывают, какой этап пайплайна выполняет каждый блок: загрузка документа, разбивка на фрагменты, векторизация, сохранение в базу, подключение модели и финальный запрос. Разработчик сохраняет этот файл, указывает путь к своим документам — и запускает.

Результат — полностью работающая RAG-система в одном Python-файле. Данные не покидают машину, внешних вызовов нет.

Какое оборудование нужно

Для пилота или внутреннего ассистента небольшой команды подойдет обычный офисный ноутбук. Языковая модель занимает на диске около 4 ГБ, комфортно работает на компьютере с 8 ГБ оперативной памяти и не требует видеокарты — покупать специальное оборудование не нужно. Такой вариант закроет потребности в RAG-системе отдела из 5–15 человек, и подойдет проектам, которые хотят протестировать идею или объединить небольшую команду вокруг внутренних регламентов.

Когда система начинает обслуживать десятки пользователей одновременно или работать с большой базой документов, без выделенного сервера с видеокартой уже не обойтись. Графический процессор ускоряет ответы в 10–20 раз и позволяет обрабатывать несколько запросов параллельно в условиях, когда сотрудники или клиенты не готовы ждать ответа больше 30 секунд.

У российского бизнеса есть два пути. Первый — купить собственное оборудование. Сервер с видеокартой уровня NVIDIA RTX 4090 или Tesla T4 обойдется в 200 000–500 000 рублей в зависимости от конфигурации, а модели уровня A100 — уже от полутора миллионов. Окупается за 6–12 месяцев при стабильной нагрузке.

Второй вариант — арендовать GPU-сервер у российского облачного провайдера. По тарифам Selectel — крупнейшего отечественного провайдера с собственными дата-центрами в Москве и Санкт-Петербурге — аренда сервера с NVIDIA Tesla T4 обойдется в 15 000–30 000 рублей в месяц, а конфигурация с A100 — в 80 000–150 000 рублей. Все серверы соответствуют требованиям 152-ФЗ, так что для большинства отечественных компаний это вполне рабочий вариант даже при работе с персональными данными. Альтернативные варианты — Yandex Cloud, VK Cloud, MTS Cloud — предлагают сопоставимые условия.

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

Для сравнения с облачными API. При нагрузке в 1 тыс. запросов в день расходы на GigaChat или YandexGPT составят 5000–20 000 рублей в месяц, на GPT-4o-mini через зарубежного посредника — 50–200 долларов. При небольших объемах облачные API всегда дешевле локального развертывания. Перелом наступает при нагрузке в десятки тысяч запросов в день — тогда собственная инфраструктура начинает обходиться в разы дешевле, и каждый дополнительный запрос становится фактически бесплатным.

Полезные репозитории

Готовые примеры локальных RAG-систем, от которых удобно отталкиваться. Все они — открытые проекты с активным сообществом, в которых уже разобраны типовые сценарии: загрузка документов, чанкинг, индексирование, сборка пайплайна. Вместо того чтобы собирать архитектуру с нуля, разработчик берет рабочий пример, заменяет тестовые документы на свои и за день-два получает работающий прототип.

  • ollama/ollama — официальный репозиторий Ollama: документация, примеры интеграции с популярными фреймворками, список доступных моделей. Хорошая отправная точка, если в проекте делается ставка на локальные языковые модели.

  • chroma-core/chroma — ChromaDB с готовыми примерами совместного использования с LangChain и LlamaIndex. Особенно полезно для пилотов: минимум настроек, максимум скорости запуска.

  • langchain-ai/langchain — основной репозиторий LangChain. В папке cookbook собраны готовые ноутбуки с локальными RAG-пайплайнами для различных сценариев: от помощника по работе с PDF-документами до чат-бота с диалоговой памятью.

  • deepset-ai/haystack — Haystack с подробным разделом tutorials, где разобраны примеры именно с локальными моделями. В первую очередь стоит обратить внимание тем, кто с самого начала планирует промышленную эксплуатацию.

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

Часто задаваемые вопросы о RAG

Чем RAG отличается от fine-tuning?

Fine-tuning меняет веса самой модели — новые знания встраиваются в параметры нейросети. Это долго, дорого и требует повторения при каждом обновлении данных. RAG оставляет модель неизменной и подключает к ней внешнюю базу знаний, которая обновляется как обычная база данных. Если нужно изменить стиль или поведение модели — выбор за fine-tuning. Если нужно дать ей доступ к актуальным фактам — выбор за RAG.

Нужен ли GPU для RAG-системы?

Здесь важно разделить два процесса. Самой RAG-системе — то есть поиску по векторной базе и сборке контекста — GPU не требуется, этим операциям достаточно и обычного процессора. А вот языковой модели, которая генерирует финальный ответ, GPU нужен почти всегда: хотя современные процессоры и справляются с инференсом, скорость генерации токенов получается очень низкой — ответа придется ждать долго. 

Если система работает через API OpenAI или другого облачного провайдера, об этом можно не думать: вычисления происходят на его стороне. Однако при локальном развертывании уже нужна видеокарта — даже для небольших моделей на 3–7B параметров. И чем больше модель, тем мощнее GPU потребуется: системам в 13B параметров уже нужны серверные карты с большим объемом видеопамяти.

Что такое галлюцинации и как RAG их снижает?

Галлюцинации — это когда языковая модель генерирует правдоподобно звучащие, но фактически ошибочные утверждения. Происходит это потому, что приоритетом системы задана связность текста, а не достоверность фактов. RAG заметно исправляет такое поведение, передавая модели конкретный контекст из проверенных источников и явно указывая в промпте опираться только на него. Полностью галлюцинации не исчезают, но становятся значительно реже — особенно если система настроена отвечать «не знаю» при отсутствии релевантного контекста.

Какие векторные базы данных самые популярные?

Наиболее распространены четыре решения. Qdrant — производительная база с открытым исходным кодом и удобным Python API, хорошо подходит как для локального использования, так и для промышленной эксплуатации. Weaviate — поддерживает гибридный поиск из коробки. FAISS от Meta — библиотека для локального использования без серверной инфраструктуры, популярна для прототипов. Pinecone — облачное управляемое решение с минимальным порогом входа, но без возможности локального развертывания.

Можно ли запустить RAG без OpenAI локально?

Да, и это вполне рабочий сценарий. Ollama позволяет запустить Llama, Mistral, Gemma или Qwen на локальной машине за несколько минут. В качестве embedding-модели используют sentence-transformers с поддержкой русского языка, в качестве векторной базы — ChromaDB или локальный Qdrant. Единственное ограничение: качество ответов локальных моделей пока уступает GPT-4o, особенно на сложных аналитических задачах.

Как оценить качество RAG-системы?

Для этого существует фреймворк RAGAS — он автоматически проверяет систему по трем параметрам. 

  • Первый — достоверность: не придумывает ли модель факты, которых нет в источниках. 

  • Второй — релевантность: отвечает ли система на тот вопрос, который задан, а не на похожий. 

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

Каждый параметр измеряется по шкале от 0 до 1. Для рабочей системы достоверность и релевантность должны быть выше 0.85, полнота поиска — выше 0.70. Если значения ниже — это сигнал пересмотреть настройки: размер фрагментов, выбор embedding-модели или формулировку промпта.

Подходит ли RAG для работы с русским языком?

Подходит, но с оговоркой. Языковые модели для генерации ответов — GPT-4o, Llama, Qwen — русский язык поддерживают хорошо. Узкое место в другом: embedding-модель, которая переводит текст в векторы для поиска, должна быть обучена на русскоязычных данных. Если взять модель, заточенную только под английский, система не будет понимать, что «расторжение договора» и «прекращение контракта» — это одно и то же. Для русского языка хорошо зарекомендовала себя multilingual-e5-large от Microsoft, а среди облачных решений — text-embedding-3-small от OpenAI.

RAG — это не экспериментальная технология и не модное словечко из мира стартапов. Это инженерный подход, который уже прочно вошел в практику: корпоративные ассистенты, интеллектуальная поддержка, поиск по документации, анализ договоров. Люди и компании, с которыми мы общаемся и которые внедрили RAG-системы год-два назад, говорят, что не представляют, как обходились без них раньше.

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

ссылка на оригинал статьи https://habr.com/ru/articles/1029740/