Эра детерминированного RAG: корпоративная ИИ-инфраструктура без ценового хаоса и галлюцинаций

6 мин
RAGLLMИнфраструктураАрхитектура

Детерминированный RAG снимает ценовой хаос и галлюцинации корпоративного поиска: модель получает 3–4 верифицированных фрагмента, собранных в контуре. Прямая отправка документов в контекстное окно внешней модели упирается в два ограничения сразу. Первое — цена вопроса. По нашим замерам на проектах с поддержкой и регламентами до 75% токенов уходит на повторную передачу одних и тех же регламентов, исходного кода и истории обращений. Второе — точность: по мере роста контекста доля правильно извлечённых фактов падает, и модель увереннее отвечает на вопросы, ответов на которые в переданном тексте нет.

Мы называем это парадоксом пустого контекста. Окно заполнено, запрос помещается целиком, а полезного в нём меньше, чем в короткой выжимке релевантных фрагментов. Третье ограничение проявляется под нагрузкой: когда через контур идут тысячи одновременных сессий, p99-задержка становится случайной величиной, которую нельзя ни посчитать заранее, ни показать в SLA. Под нагрузкой видно и задержку, и границы доступа. Аудит безопасности ИИ-систем.

Поэтому мы выносим LLM из роли хранилища знаний. Модель остаётся вычислительным ядром и получает 3–4 верифицированных фрагмента, собранных локально. Ниже — контур, который мы собираем для корпоративной базы знаний. Если данные не должны покидать контур, модели разворачиваются внутри. Развёртывание суверенных моделей.

Схема контура

  Документы, репозитории, история обращений
                     │
                     ▼ очистка, чанкинг, обезличивание
┌──────────────────────────────────────────────┐
│ 0. Офлайн-конвейер индексации                │
│    чанки → эмбеддинги → версия базы знаний   │
└──────────────────────┬───────────────────────┘
                       │ offline
                       ▼ HNSW-индекс
┌──────────────────────────────────────────────┐
│    Векторная СУБД: Qdrant / pgvector         │
└──────────────────────┬───────────────────────┘
                       │ чанки по запросу
                       │
  [ Пользователь: «как подключить CRM?» ]
                       │
                       ▼ 1. эмбеддинг запроса
┌──────────────────────────────────────────────┐
│ 1. Семантический кэш                         │
│    сходство > 0.95 → ответ из памяти         │
└──────────────────────┬───────────────────────┘
                       │ промах
                       ▼ 2. dense + sparse поиск
┌──────────────────────────────────────────────┐
│ 2. Гибридный поиск по индексу                │
│    top-3–4 чанка, только верифицированные    │
└──────────────────────┬───────────────────────┘
                       │
                       ▼ 3. сборка промпта
┌──────────────────────────────────────────────┐
│ 3. Внешний инференс (приватный API)          │
│    в контексте только найденные фрагменты    │
└──────────────────────┬───────────────────────┘
                       │
                       ▼ 4. наблюдаемость
┌──────────────────────────────────────────────┐
│ 4. Langfuse: цепочка шагов, cost, latency    │
└──────────────────────────────────────────────┘

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

Векторный слой и гибридный поиск

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

Критерий Векторный слой (Qdrant / pgvector) Полнотекстовый поиск
Механика извлечения Ближайшие векторы по косинусному расстоянию Совпадение слов, стемминг, словари синонимов
Устойчивость к синонимам Высокая: смысл совпадает, термин другой Нулевая, пока синоним не внесён вручную
p99 задержки Стабильные миллисекунды на HNSW-графе Растёт вместе с числом условий в запросе
Доступ к данным Фрагменты изолированы внутри контура Наружу уходит вся база при внешнем запросе
Цена ошибки Пропущен релевантный чанк Молчаливое отсутствие точного совпадения

Гибридный поиск (Dense + Sparse) на Qdrant или расширении pgvector смотрит на запрос с двух сторон одновременно. Он считывает глубокий смысл формулировки и отдельно ловит точные идентификаторы — номера артикулов, даты, имена собственные. Так снимается пара типовых ошибок: векторный поиск не находит артикул, полнотекстовый не понимает синоним.

Отдельно стоит чанкинг. Слишком мелкий фрагмент рвёт контекст («по условию договора» без самого условия), слишком крупный тащит в промпт лишние токены и размывает внимание модели. Мы режем документ по его структуре, а не по фиксированному числу символов, и раз в спринт перечитываем выборку чанков вручную.

Семантическое кэширование

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

«Как настроить интеграцию с CRM?» и «Инструкция по подключению CRM-системы» — разные строки, один смысл.

При пороге сходства выше 0.95 такие запросы схлопываются, и пользователь получает ранее сгенерированный ответ из памяти. На потоках с выраженной повторяемостью (поддержка, регламенты, типовые интеграции) перехватывается 70–80% обращений: внешний инференс разгружается, а ответ уходит за фиксированные миллисекунды вместо сетевого вызова к провайдеру.

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

Трассировка вместо догадок

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

Из этой цепочки читаются четыре вещи, которых иначе не видно:

  • Доля попаданий в кэш. Насколько гипотеза о повторах вообще верна.
  • p99 по шагам, а не по сумме. Где именно копится задержка: в эмбеддинге, в поиске или в сети до провайдера.
  • Стоимость диалога в токенах. Считается по шагам, поэтому рост виден в день, когда он случился.
  • Доля ответов без найденного источника. Самая честная метрика. Если в 90% ответов нет ссылки на конкретный фрагмент, модель отвечает из памяти, а контур её не остановил.

Что уходит за периметр

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

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

Главный результат

Главный результат — предсказуемая цена и прослеживаемый путь ответа. Вы точно знаете, какие 3–4 фрагмента ушли в модель, сколько это стоило, сколько заняло и на каком шаге что сломалось. Месяц работы уходит на индексацию и чистку данных, и это самая недооценённая часть проекта. Зато после неё счёт за токены перестаёт быть ставкой вслепую.

Поговорите о задаче

Разберём вашу задачу и покажем, что уже работает у клиентов из вашей отрасли.

Оставить заявку