Production-ready RAG в 2026: векторные базы, embedding-модели и архитектура корпоративного поиска по знаниям

Между демонстрацией «модель отвечает по нашим документам» и системой, которой доверяют юристы, поддержка и бухгалтерия, лежит несколько слоёв инженерии. Собрать связку «векторный поиск плюс языковая модель» за вечер может любой разработчик. А довести её до состояния, когда RAG (Retrieval-Augmented Generation, генерация ответа с опорой на найденные во внутренних источниках фрагменты) отвечает точно, не выдумывает и не показывает сотруднику то, к чему у него нет доступа, — задача другого порядка.

Разберём корпоративный поиск по знаниям как инженерную систему: из чего он собирается, что выбрать на каждом слое и как считать стоимость. Отдельно — суверенность данных, контроль доступа к фрагментам и работа моделей в закрытом контуре под 152-ФЗ.

Наивный RAG и почему он не доходит до продакшена

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

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

Четыре боли наивного пайплайна: точность, полнота, контекст, галлюцинации

Провалы наивного RAG раскладываются на четыре типа — с каждым борются разными слоями.

• Точность (precision). В выдачу попадают фрагменты, похожие по теме, но не отвечающие на вопрос. Лечится реранкингом и гибридным поиском.
• Полнота (recall). Нужный фрагмент есть в корпусе, но не попал в top-k — его «перебили» более похожие по вектору, но бесполезные куски. Помогают расширение окна кандидатов и качественный чанкинг.
• Контекст. Фрагмент вырван из структуры: пункт договора без раздела, строка таблицы без заголовков. Формально релевантно, а ответить нельзя. Решается иерархическим чанкингом и метаданными.
• Галлюцинации. Когда найденного не хватает, модель достраивает ответ из внутренних знаний. Купируется жёстким промптингом, привязкой к источникам (grounding) и цитированием.

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

RAG против дообучения и длинного окна контекста: как выбрать подход

Прежде чем строить пайплайн, стоит честно ответить: нужен ли здесь RAG вообще. Есть три конкурирующих подхода.

Дообучение меняет стиль и поведение модели, но плохо годится для фактов, меняющихся еженедельно. Длинное окно контекста соблазняет простотой «загрузим всё в запрос», но упирается в стоимость и в эффект «потерянного в середине» (Lost in the Middle): модель хуже удерживает информацию из центра длинного ввода. RAG выигрывает там, где корпус большой, меняется часто и требует прослеживаемости источника. На практике подходы комбинируют: дообученная под доменную лексику модель поверх RAG работает лучше каждого по отдельности.

Подготовка знаний: чанкинг, эмбеддинги и модели под русский язык

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

Чанкинг и ingestion сложных документов: PDF, сканы, таблицы, презентации

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

• Семантический чанкинг режет по границам смысла — абзацам, разделам, пунктам. Ориентир — около 512 токенов с перекрытием (overlap) в 10–15%, чтобы мысль на стыке не терялась.
• Иерархический (parent/child) чанкинг индексирует мелкие точные фрагменты, но модели отдаёт родительский блок целиком. Поиск остаётся точным, а контекст — полным.
• Обогащение метаданными. К каждому чанку крепятся источник, раздел, дата, версия и права доступа — по ним дальше фильтруют выдачу, и это критично для безопасности.

Отдельная сложность — ingestion сложных форматов. PDF со сканами требуют OCR, презентации теряют логику при линейном извлечении, но особенно коварны таблицы: разрезанная построчно таблица превращается в набор чисел без заголовков. На практике таблицы выносят в отдельный тип чанков, сохраняя шапку в каждом фрагменте, либо переводят в структурированный вид (Markdown, «ключ-значение») ещё при парсинге. Для распознавания структуры применяют специализированные парсеры (layout-модели), а не регулярные выражения.

Embedding-модели для русского: dim, длина контекста, работа в закрытом контуре

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

Три параметра при выборе. Размерность (dim) влияет на объём индекса и память: 1024 против 3072 — троекратная разница в размере базы. Длина контекста эмбеддера ограничивает максимальный чанк: BGE-m3 с окном до 8192 токенов индексирует крупные фрагменты целиком. Работа в закрытом контуре для многих российских заказчиков обязательна: e5 и BGE-m3 разворачиваются на своей GPU без выхода в интернет.

По нашему опыту, для русскоязычного корпуса с ограничением на периметр разумная база — self-hosted BGE-m3 или e5-large; зарубежные API стоит рассматривать только для заведомо не чувствительных данных. Универсального лидера нет: качество нужно мерить на своём корпусе.

Векторные базы, гибридный поиск и реранкинг

Слой хранения и поиска обычно сводят к перечислению «Qdrant, Pinecone, Weaviate, Chroma, pgvector». Разберём, где у каждого варианта пределы и почему одного векторного поиска мало.

Выбор векторной БД под реальную нагрузку: ANN, HNSW, IVF, метаданные

В основе любой векторной базы — приближённый поиск ближайших соседей, ANN (Approximate Nearest Neighbor). Точный перебор по миллионам векторов слишком дорог, поэтому строят индекс. Два основных типа: HNSW (граф из слоёв, быстрый поиск, высокая точность, но требователен к RAM) и IVF (кластеры, экономнее по памяти, но чуть менее точен). HNSW — фактический стандарт там, где важна точность.

• pgvector. Отличный старт, если данные уже в PostgreSQL. Предел наступает в районе нескольких миллионов векторов и при активной фильтрации по метаданным: HNSW-индекс в Postgres тяжело обновлять на лету, а постфильтрация по правам рушит точность.
• Qdrant. Надёжный вариант для self-hosted. Нативная фильтрация по метаданным вместе с векторным поиском, встроенный гибридный режим, предсказуемое поведение под нагрузкой. Для закрытого контура — один из первых кандидатов.
• Weaviate, Chroma, Pinecone. Weaviate — богатый функционал и модульность; Chroma хорош для прототипов; Pinecone удобен как управляемый облачный сервис, но это внешнее облако — для чувствительных данных чаще мимо.

Про память стоит помнить заранее. HNSW-индекс на 1 млн векторов размерностью 1024 в float32 занимает порядка 4 ГБ только под вектора, плюс граф связей — закладывайте 6–8 ГБ RAM на миллион. При обновлении корпуса граф HNSW деградирует: массовые удаления и вставки со временем требуют перестроения индекса.

Гибридный поиск и реранкинг: dense + sparse, RRF, BGE / Cohere rerank

Чистая семантика проваливается на точных совпадениях. Ответ индустрии — гибридный поиск: комбинация плотного (dense, векторного) и разреженного (sparse, лексического) поиска. Роль лексики играет BM25 — классический алгоритм ранжирования по совпадению слов, который точно ловит коды, имена и редкие термины.

Результаты двух поисков сводят через RRF (Reciprocal Rank Fusion) — метод объединения ранжированных списков по обратным рангам, устойчивый к тому, что у dense и sparse разные шкалы оценок. На выходе — единый список кандидатов, где учтены и смысл, и буква.

Финальный слой — реранкинг. После гибридного поиска берут расширенный набор кандидатов (например, top-50) и прогоняют через cross-encoder — модель, оценивающую пару «запрос-фрагмент» целиком, а не по расстоянию между заранее посчитанными векторами. Это точнее, но дороже, поэтому реранкер работает только по короткому списку. Из открытых решений для русского подходит BGE-reranker (локально), из облачных — Cohere Rerank и Voyage rerank. Задержка порядка 50–150 мс, а прирост точности ощутимый. Именно связка «гибридный поиск → реранкинг» вытягивает основную часть разрыва между демо и продом.

Безопасность, контроль доступа и суверенность данных

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

Контроль доступа к чанкам и row-level security на этапе поиска

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

Правильный подход — фильтрация на этапе retrieval. Права доступа зашиваются в метаданные каждого чанка при индексации, а поисковый запрос сразу ограничивается тем, что пользователю разрешено видеть. Это тот же принцип, что row-level security (RLS) в СУБД, только применённый к фрагментам знаний: сотрудник физически не может получить в выдаче то, к чему у него нет прав. Технически это требует векторной базы с эффективной фильтрацией по метаданным на этапе поиска — иначе на масштабе фильтр либо замедляется, либо рушит полноту. Qdrant и подобные движки с нативной фильтрацией здесь предпочтительнее pgvector с постфильтрацией.

On-premise и 152-ФЗ: закрытый контур, self-hosted LLM и эмбеддеры

Для данных под 152-ФЗ (закон о персональных данных) вопрос стоит жёстко: ПДн россиян должны обрабатываться и храниться на территории РФ, а их передача во внешние сервисы — отдельный риск и с точки зрения закона, и с точки зрения безопасности. Это исключает зарубежные API для эмбеддингов и генерации, если через них проходят ПДн или коммерческая тайна.

Отсюда курс на закрытый контур: и векторная база, и embedding-модель, и сама LLM разворачиваются внутри инфраструктуры без выхода наружу. Плюс размещения в аттестованном ЦОД уровня Tier III — это не только отказоустойчивость (доступность 99,98%+), но и выполнение требований к физической защите и обработке ПДн.

Узкое место такого сценария — GPU. Размещение открытых моделей и эмбеддеров в своём контуре требует ускорителей, а закупка собственного парка под пилот экономически сомнительна: оборудование дорогое, дефицитное и быстро устаревает. Для команд, которым нужен закрытый контур без капитальных вложений, эту задачу закрывает LLM-платформа от Cloud4Y — облачный сервис, позволяющий развернуть и дообучить открытую модель на GPU-инфраструктуре провайдера в российском ЦОД. Открытую LLM и эмбеддер под русский можно поднять и адаптировать под свои данные, не выпуская корпус за периметр и не покупая ускорители, — то есть собрать суверенный контур для RAG на арендованных мощностях.

Оценка качества, эксплуатация и экономика

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

Метрики retrieval и мониторинг деградации: golden-set, Recall@k, MRR, NDCG

Основа оценки — golden-set: набор типовых вопросов и заранее размеченных правильных ответов. Собрать его на русском — ручная работа: 100–300 реальных вопросов от будущих пользователей с экспертной разметкой. Это рутинная работа, но без золотого набора любая оптимизация — гадание.

По нему считают метрики retrieval:

• Recall@k — доля случаев, когда нужный фрагмент попал в первые k результатов. Целевой ориентир для прода — 0,9 и выше.
• MRR (Mean Reciprocal Rank) — насколько высоко в списке стоит первый релевантный результат.
• NDCG (Normalized Discounted Cumulative Gain) — учитывает и релевантность, и порядок выдачи, штрафуя за то, что важное оказалось внизу.

Качество генерации отдельно оценивают через LLM-as-judge — когда более сильная модель судит ответы по критериям «обоснованность, полнота, отсутствие выдумок». Подход масштабируемый, но судья предвзят к многословным ответам и к своему стилю, и его оценки надо периодически сверять с человеческой разметкой. Инструменты вроде Ragas автоматизируют часть метрик, но не заменяют golden-set. Главное правило — прогонять оценку при каждом изменении пайплайна и держать метрики на дашборде, чтобы поймать регрессию до пользователей.

Жизненный цикл корпуса и ТСО: обновление, актуальность и расчёт затрат

Корпус живёт: документы добавляются, редактируются, устаревают. Актуальность выдачи обеспечивается инкрементальным обновлением, а не полной переиндексацией каждую ночь: при правке документа пересчитываются только его чанки. Отдельная проблема — дедупликация почти одинаковых версий: если в индексе лежат три редакции регламента, модель может процитировать устаревшую. Помогает версионирование в метаданных и правило «в выдачу идёт только актуальная версия».

Теперь об экономике. Сравним два сценария на горизонте 3 года для корпуса ~1 млн чанков (порядка 300–500 тыс. документов) при нагрузке ~5 000 запросов в сутки: собственный контур на арендованной GPU-инфраструктуре против оплаты облачных API за каждый запрос.

Вывод не в том, что облако всегда дороже, а в точке перелома. У self-hosted почти все затраты постоянные, у облака — переменные, около 2,5 ₽ за запрос. Точка безубыточности проходит примерно на 2 000–2 500 запросах в сутки: ниже дешевле облачные API, выше — собственный контур окупается. К экономике добавляется ещё один аспект: при чувствительных данных зарубежные API часто исключаются не по цене, а по требованиям 152-ФЗ, и тогда сравнение идёт между self-hosted и российским облаком с GPU в закрытом контуре. Суммы ориентировочны: итог сдвинется на ±25% в зависимости от модели генерации, нагрузки и тарифов на электроэнергию.

Главные выводы

Production-RAG — это не векторный поиск поверх языковой модели, а многослойный конвейер, где качество ответа рождается задолго до генерации. Наивная связка top-k и LLM разваливается на реальном корпусе по четырём предсказуемым причинам, и лечит их не более сильная модель, а инженерия каждого слоя: осмысленный чанкинг и ingestion сложных документов, embedding-модель под русский язык и ограничения периметра, векторная база с понятными компромиссами, гибридный поиск с реранкингом и — обязательно — постоянная оценка по golden-set.

Для российского корпоративного сегмента к этому добавляется измерение, которое нельзя приделать потом: суверенность и безопасность. Фильтрация чанков по правам на этапе поиска, хранение корпуса и моделей в закрытом контуре, соответствие 152-ФЗ и размещение в аттестованном ЦОД — часть архитектуры, а не опция. Экономику стоит считать на горизонте нескольких лет и с честным разделением постоянных и переменных затрат: тогда видно, где облачные API выгоднее пилота, а где собственный GPU-контур окупается и заодно снимает вопрос выхода данных за периметр. Начинать разумно с простого пайплайна и golden-set из пары сотен вопросов — а дальше наращивать слои, сверяясь с метриками, а не с ощущениями.