В этой статье
Главная мысль
Если нужный фрагмент не попадает в модель, смена промпта редко помогает. Оценивайте поиск отдельно: точные термины, семантические совпадения, структура документов и ранжирование исправляют разные причины ошибок.
Разделяйте внешне похожие вопросы
«Как сбросить это устройство?» и «Что означает ошибка AX-204?» похожи на вопросы поддержки. Первому полезен семантический поиск, если руководство использует другие слова. Второму нужен точный идентификатор. Соберите небольшой набор обоих типов, добавив аббревиатуры, разные языки и вопросы по нескольким документам.
Попросите эксперта указать нужные фрагменты для каждого вопроса. Проверяйте результаты поиска до генерации ответа: гладкий текст может скрыть выбор руководства другого продукта. Сохраните простой лексический вариант как основу; сложность оправдана, только когда исправляет конкретную ошибку.
Объединяйте точность терминов и смысловой охват
Гибридный поиск объединяет полнотекстовый и векторный. Azure AI Search описывает слияние параллельных списков через reciprocal rank fusion. Инженерная идея — сохранить точные совпадения и находить иначе сформулированные фрагменты. Подход нужно оценивать: это не доказательство превосходства любой гибридной настройки над любым векторным поиском.
В нашем примере фильтры продукта и доступа должны совпадать в обоих путях поиска. Изучите вклад каждого пути и не вытесняют ли копии одного документа другие доказательства. Сравнивайте с базой на одинаковых вопросах и версиях источников. Улучшение среднего балла может скрывать ухудшение для точных кодов ошибок, наиболее важных поддержке.
Два способа найти одни доказательства
Примеры вопросов поддержки. Сравните оба пути на своих документах.
Точные слова
«AX-204» → сохранить код ошибки, название продукта и идентификаторы.
Смысл
«Устройство не перезапускается» → найти инструкцию с другой формулировкой.
Объединённые сведения
Объедините кандидатов, удалите дубли и оцените итоговое ранжирование.
Каждый фрагмент должен быть понятен отдельно
Фрагмент — единица текста для поиска. Начните со структуры документа: раздел с заголовком, полная процедура или таблица с названиями столбцов. Разбиение по одинаковому числу символов может оторвать исключение от правила. Слишком большое перекрытие создаёт дубликаты и расходует контекст.
Универсального размера фрагмента без изучения материала нет. Проверьте несколько подходов на типичных документах, включая сканы PDF и длинные таблицы. Сохраняйте ссылку на исходное место и соседний контекст для выражений вроде «следующие условия». Если извлечение потеряло заголовок таблицы, дорогая модель не восстановит его надёжно.
Добавляйте переранжирование при измеримой пользе
Переранжирование — повторное упорядочивание найденных кандидатов перед сборкой контекста. Сохранив поисковый механизм, сравните отобранные доказательства с этим этапом и без него. Измеряйте релевантные фрагменты наверху списка, пропуски, задержку и стоимость. Переранжировщик не спасёт источник, исключённый неверным фильтром.
Сохраняйте модульность для отдельной проверки подготовки запроса, поиска и сборки контекста. Документация RAG в Spring AI показывает такой подход через advisor API. До расширения запишите обнаруженный дефект и ожидаемое улучшение. Выпускайте простую конфигурацию, если дополнительный этап не улучшает важные вопросы.
Проверьте точную ссылку и вопрос обычным языком
Возьмите два запроса: «Ошибка E-417 на контроллере X2» и «контроллер останавливается, когда в помещении жарко». Первый зависит от точного идентификатора; второму может понадобиться смысловой поиск, поскольку руководство называет проблему «тепловым отключением». Проверочный набор должен содержать оба типа, а не только гладкие естественные вопросы.
Изучите кандидатов до финального ответа. Если нужное руководство не попало в набор, переранжирование не вернёт его. Сначала проверьте токенизацию ID, фильтры, язык и наличие документа. Если нужный фрагмент есть, но спрятан среди менее полезных, исследуйте ранжирование. Так вы не меняете сразу три этапа и сохраняете объяснение улучшений.
Используйте матрицу ошибок вместо одного общего балла
Группируйте вопросы по ошибкам: точный код, перефразирование, отсутствующий источник, неоднозначный продукт и противоречивые редакции. Сравнивайте конфигурации на одинаковых группах, сохраняя найденные фрагменты. Одно среднее скрывает ухудшение для кодов, которыми поддержка пользуется чаще всего.
Измеряйте время вместе с релевантностью и объёмом контекста генерации. Больше фрагментов может означать выше стоимость и больше противоречий без улучшения ответа. Выберите лимит кандидатов и стратегию переранжирования по наблюдаемым случаям, затем повторяйте проверки после изменений документов или эмбеддингов. Результат — обоснованное решение о качестве поиска, а не заявление об универсальном превосходстве гибридного подхода.
Найдите этап, потерявший доказательство
Примеры диагностики; результаты бенчмарков не подразумеваются.
Прокрутите по горизонтали, чтобы прочитать таблицу →
| Симптом | Что проверить | Следующий эксперимент |
|---|---|---|
| Точный код не найден | Индексацию, токенизацию, фильтры | Запрос точного идентификатора |
| Перефразирование не находит руководство | Семантических кандидатов и охват | Сравнить лексические и семантические результаты |
| Релевантный фрагмент слишком низко | Порядок кандидатов и дубликаты | Оценить переранжирование на тех же случаях |
| Хороший фрагмент, неверный ответ | Генерацию и противоречивый контекст | Сверить утверждения с выбранными доказательствами |
Источники и дополнительное чтение
Документация проверена .
ВОПРОСЫ / РЕШЕНИЯ
Частые вопросы
Достаточно ли векторной БД для RAG?+
Она подходит для первого поискового конвейера, но извлечение документов, права, ранжирование и оценку ответов всё равно нужно проектировать. Проверяйте точные идентификаторы наравне с вопросами обычным языком.
Каждой RAG-системе нужен переранжировщик?+
Нет. Добавляйте его, когда сравнение на ваших вопросах показывает, что улучшение контекста оправдывает дополнительную задержку и стоимость.