RAG OpenSearch: почему поиск по базе знаний выдаёт не то
Ассистент по базе знаний отвечает уверенно и по делу — но не на тот вопрос. Пользователь спрашивает, как оформить возврат при браке, а получает регламент гарантийного ремонта: совпали слова, а смысл запроса остался за кадром. Нерелевантные ответы ассистента дороже явной ошибки — по правдоподобной инструкции начинают действовать.
Причина обычно одна: слой поиска собран как надстройка над полнотекстовым индексом. Лексическое ранжирование по частоте терминов не знает синонимов, перефраза и внутреннего жаргона. Если в базе написано «дефект при приёмке», а спрашивают «пришло битое» — поиск по базе знаний не находит нужный пункт, хотя он лежит рядом. Генератор здесь не виноват: он пересказывает то, что ему передали.
Узкое место слоя поиска видно по замерам: доля запросов, где верный фрагмент попадает в топ-5, оказывается вдвое ниже ожидаемой. Чем больше в базе похожих по формулировкам документов, тем сильнее проседает качество выдачи RAG — находится соседняя тема, и ответ звучит связно, но мимо.
Закрывается это не заменой модели, а перестройкой поиска: векторное представление запроса и документов, гибридная выдача, где лексика и смысл складываются, отсечение нерелевантных фрагментов моделью переранжирования, разбиение документов с перекрытием. Разбираем, как это работает в OpenSearch и что даёт на живой базе знаний.
Что даёт управляемый слой поиска над базой знаний
Управляемый слой поиска — это набор настроек, а не «магия модели». Мы задаём, какие поля индексируются и с какими весами, как нарезается база знаний, как строится векторное представление фрагментов и что именно попадает в контекст ответа. Поэтому точность выдачи становится измеримой величиной, которой можно управлять, а не удачей от формулировки вопроса.
В основе — OpenSearch в режиме гибридного поиска: лексическая часть ловит точные термины, артикулы и аббревиатуры, векторная — смысловые перефразировки. Поверх работает переранжирование кандидатов и порог отсечения слабых совпадений, чтобы в контекст не попадал мусор. На контрольной выборке реальных вопросов доля релевантных ответов поднимается с 55–60% до 85–90%.
Отдельно закрываем устойчивость к формулировкам: синонимы, опечатки, иной порядок слов и вопросы «своими словами» больше не выбивают поиск из колеи. Это снимает целый класс отказов, когда система уверенно отвечает не по тому фрагменту базы знаний — ошибка тем опаснее, что внешне выглядит правдоподобно.
Время отклика поиска держим в пределах долей секунды на этапе отбора кандидатов; основную задержку даёт генерация ответа, её ограничиваем отдельно. Замеры ведём на фиксированном наборе вопросов с эталонными ответами, поэтому после каждой правки настроек видно, что именно изменилось — в точности, в скорости и в доле покрытых сценариев.
Режимы поиска в RAG OpenSearch: что выбрать
Режим выдачи решает, найдётся ли нужный фрагмент, когда формулировка вопроса не совпадает с текстом документа. Лексический поиск по инвертированному индексу уверенно ловит артикулы, аббревиатуры и точные формулировки, но проигрывает на перефразировках. Векторный индекс находит совпадения по смыслу, зато путается в числах и кодах. На практике выбор сводится к четырём вариантам.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Лексический поиск | Артикулы, коды, аббревиатуры, точные термины в запросе | Не находит синонимы и перефразировки, полнота падает на разговорных вопросах |
| Векторный индекс | Вопросы своими словами, разговорные формулировки, разноязычный корпус | Слабо различает числа и редкие обозначения, переиндексация при смене модели эмбеддингов |
| Гибридный поиск | Смешанные запросы, где есть и смысл, и точный термин | Нужен подобранный вес при слиянии: при перекосе теряется одна из сильных сторон |
| Гибрид и переранжирование результатов | Высокие требования к точности первых трёх-пяти фрагментов, корпус ограничен | Добавляет время на каждый запрос, требует отдельной модели и ресурсов под неё |
Все четыре режима работают на одной коллекции документов: в OpenSearch лексический и векторный поиск собираются поверх одного индекса, поэтому переключение — вопрос настройки запроса, а не перестройки хранилища. Переиндексация нужна только при смене модели эмбеддингов — план миграции закладываем заранее. Гибрид не включаем по умолчанию: замеряем на реальных вопросах, какой режим даёт верный фрагмент в топ-5, и уже после фиксируем вес веток и необходимость переранжирования.
Этапы внедрения: от аудита корпуса до передачи
Внедрение поиска по документам начинается не с настройки движка, а с разбора корпуса: пока неясно, что лежит в источниках и как связаны версии, любая конфигурация индекса — угадывание. Ниже — порядок работ; часть этапов идёт параллельно, если это не мешает проверяемости результата.
- Аудит и разметка корпуса. Сводим источники, смотрим форматы, дубликаты, версионность. Размечаем фрагменты — текст, таблицы, вложения — и поля-фильтры: тип документа, подразделение, дата редакции.
- Контрольный набор вопросов. С вашей командой собираем реальные вопросы с эталонными ответами и источниками. Набор фиксируем: он служит меркой качества до конца работ.
- Схема индексов. Решаем, что и какими порциями попадает в индекс, какие поля работают в векторном и текстовом поиске и как складывается гибридное ранжирование.
- Настройка поиска. Подбираем модель эмбеддингов под язык корпуса, размер фрагмента, перекрытие и веса гибрида — сначала на выборке, затем на всём массиве.
- Проверка на контрольных вопросах. Считаем, как часто верный источник попадает в верхние позиции, и раскладываем промахи по причинам: разбиение, устаревшая редакция, вопрос вне корпуса.
- Корректировка и передача. Правим разбиение, метаданные и фильтры до стабилизации показателей, затем отдаём конфигурации индекса, регламент обновления, скрипты замеров и документацию вашим инженерам.
Как закрывается каждый этап
Этап считается завершённым, когда есть проверяемый артефакт: разметка, набор вопросов, схема индексов, отчёт замеров. Поэтому работа системы дальше не зависит от того, кто именно с нашей стороны её вёл.
Комплект поставки: индексы, схемы, регламенты обновления
Контур остаётся работоспособным без нас: всё, что настраивается при разработке RAG на OpenSearch, передаётся в виде воспроизводимых артефактов. Инженеры заказчика могут поднять копию поиска, подключить новый источник или изменить правила доступа, не разбирая чужую конфигурацию по логам. В поставку входит следующее.
- Описание индексов: маппинги текстовых и векторных полей, размерность представлений, анализаторы, число сегментов и реплик — с пояснением, почему выбраны такие значения.
- Правила разбиения документов на фрагменты: размер окна, перекрытие, обработка таблиц и заголовков, чтобы фрагмент сохранял смысл и ссылку на исходный документ.
- Схема гибридного поиска: вклад лексической и векторной составляющих, порядок объединения и уточняющего ранжирования результатов.
- Набор проверочных запросов: эталонные вопросы с ожидаемыми документами, чтобы после любой правки видеть, не просела ли выдача.
- Настройки прав доступа к документам: как метки конфиденциальности и группы пользователей попадают в индекс и как фильтр применяется в момент поиска, не пропуская лишнего.
- Регламент обновления базы знаний: инкрементальная переиндексация изменённых файлов, расписание полного пересбора, обработка удалений и старых редакций.
- Инструкции для поддержки: чтение логов поиска, действия при падении качества ответов, откат к предыдущей схеме индекса.
Этого достаточно, чтобы команда заказчика развивала решение самостоятельно, а мы подключались точечно — на расширении или сложных изменениях.
Кейс: база знаний поддержки, метрики до и после
База знаний поддержки жила на лексическом поиске: запрос разбивался на слова, совпадения искались по точным формам. Живые формулировки это ломали — «не приходит письмо» и «нет уведомлений на почту» уходили в разные результаты, синонимы и опечатки не обрабатывались вовсе.
Метрики снимали на одной и той же выборке: 200 реальных обращений с эталонными статьями. Проверка на контрольных вопросах дала базу: нужный документ в первых трёх результатах — 41%, эскалация на вторую линию — 38%, среднее время до ответа — около 9 минут.
Что изменили
Поиск перевели на OpenSearch в гибридном режиме: лексическое совпадение плюс векторные представления фрагментов, результаты двух веток объединяются и переранжируются. Статьи нарезали на фрагменты с перекрытием и приписали метаданные — продукт, язык, тип статьи, статус актуальности. Фильтр по продукту срабатывает до ранжирования, чтобы не всплывали ответы по чужой линейке.
Что стало
Тот же набор контрольных вопросов прогнали повторно: попадание в первые три — 87%, эскалации — 14%, время до ответа — 2,5 минуты. Добавился отказ от ложных совпадений: если подходящей статьи в базе нет, система отдаёт пустой результат с пометкой, а не первую попавшуюся инструкцию.
Разбор ошибок после прогона показал, где покрытие базы неполное: часть вопросов ушла в очередь на написание статей, а не в доработку поиска.
Чем гибридный поиск отличается от чистого векторного
Чистый векторный поиск переводит запрос в числовое представление и достаёт ближайшие по смыслу фрагменты. Перефраз и вопрос своими словами он отрабатывает уверенно, но лексику теряет: артикул, шифр детали или код ошибки растворяются в усреднённом векторе, и в выдаче оказываются документы про ту же тему, но не те.
Лексический поиск работает наоборот: сравнивает термы и находит точные совпадения, зато проваливается, когда формулировка вопроса не совпадает с формулировкой в документе. Гибридный режим запускает оба запроса по одному индексу и объединяет выдачи — остаются и смысловая близость, и попадание по точному обозначению.
Оценки двух режимов не складываются напрямую: шкалы у них разные. Позиции из обоих списков пересчитываются в единый рейтинг, веса режимов задаются под корпус, а для полей с кодами и названиями моделей добавляются повышающие коэффициенты, чтобы точное совпадение поднималось выше смыслового соседства.
На коротких запросах в одно-два слова вектор шумит, на узкоспециальных с аббревиатурами и дефисами вытягивает лексика, на длинных естественных формулировках сильнее вектор. Гибрид не выбирает победителя заранее — он держит оба сигнала. Отдельная работа — разбор строки: код не должен разрезаться по дефису и терять регистр, иначе точный поиск перестаёт находить документ.
Частые технические сомнения перед стартом
Инженерные сомнения перед стартом редко про то, «сработает ли поиск вообще» — они про эксплуатацию: сколько ждать ответа, что делать при обновлении корпуса, как не выдать пять копий одного абзаца и можно ли потом сменить модель. Ниже — ответы на уровне реализации.
Насколько гибридный поиск увеличит задержку ответа?
Гибрид — это векторный и лексический проходы по индексу с объединением выдачи, поэтому сам поиск занимает небольшую долю общего времени ответа. Основное время уходит на генерацию, и оно зависит не от размера корпуса, а от объёма контекста: мы фиксируем, сколько фрагментов отдаём модели, поэтому рост базы знаний не удлиняет ответ. Задержку измеряем поэтапно — поиск, переранжирование, генерация — и оптимизируем тот участок, который реально проседает.
Как отсечь дубли документов и повторяющиеся фрагменты?
Причина обычно в подготовке корпуса: один текст лежит в нескольких файлах или фрагменты нарезаны с большим перекрытием. На загрузке считаем отпечаток содержимого и отбрасываем повторы, форматы приводим к единому виду, а перекрытие задаём так, чтобы соседние части не конкурировали между собой. В контекст модели уходит один лучший фрагмент на источник, а не все похожие.
Нужна ли полная переиндексация при каждом обновлении корпуса?
Нет. Каждый фрагмент хранится с идентификатором источника, поэтому при правке документа переиндексируются только его части, а удалённое закрывается пометкой, исключающей фрагмент из выдачи. Полная пересборка нужна, если сменилась модель векторизации или логика нарезки: её выполняем в фоне, в отдельной версии индекса, и переключаем трафик, когда новая версия проверена на контрольном наборе. Поиск в это время остаётся доступен.
Можно ли заменить модель, не переделывая поиск?
Индекс хранит векторные представления текста, а поиск отдаёт готовые фрагменты в любую модель через единый интерфейс — слои разделены. Смена генеративной модели пересборки не требует: достаточно прогнать контрольный набор вопросов и сравнить ответы. А вот смена модели векторизации означает другое пространство признаков — старые векторы с новыми несопоставимы, здесь пересборка неизбежна, и её планируют заранее, как отдельный этап.
Обсудим задачу: что прислать для оценки
Оценка поискового решения держится на двух вещах — реальном корпусе и реальных запросах. Часть данных соберём на первом этапе вместе с вашей командой, но чем больше исходных данных, тем меньше допущений в архитектуре RAG на OpenSearch и тем точнее сроки.
- Корпус документов или выгрузка: форматы (PDF, DOCX, таблицы, база знаний), объём, языки, доля сканов — от этого зависит разбиение на фрагменты и распознавание.
- 50–100 настоящих запросов пользователей в живой формулировке и ожидаемые ответы хотя бы на часть — на них измеряем качество до начала работ.
- Разметка релевантности, если велась: какие документы считаются правильным попаданием. Без неё соберём метрики на согласованной выборке.
- Правила доступа: кто какие документы вправе видеть, есть ли разделение по отделам. Права встраиваем в сам запрос, иначе появится утечка в выдаче.
- Как поиск устроен сейчас и на что жалуются пользователи: запросы без ответа, нерелевантная выдача, потерянные документы.
- Контур и ограничения: где разворачиваем сервис, допустима ли передача данных во внешние модели, нужна ли работа внутри периметра.
- Нагрузка и обновления: сколько запросов в сутки, пиковые периоды, приемлемое время ответа, как часто меняется корпус.
По этому набору вернёмся с оценкой и планом работ: схема индексации и разбиения, логика гибрида — лексический поиск плюс векторный — переранжирование, этапы и порядок приёмки. Опишите задачу в свободной форме, уточняющие вопросы зададим сразу.
