Вы задаёте своему новому RAG-ассистенту простой вопрос — «Какова наша политика возврата для годовых планов?» — и он уверенно отвечает абзацем о сроках доставки. Или того хуже, выдумывает политику, которой не существует. Вы проверяете логи: векторная база данных вернула пять фрагментов, все они выглядят смутно связанными, а LLM сделала то, что LLM делают всегда — превратила расплывчатый контекст в беглый, но неверный ответ. Подробнее об этом — в статье Промты для продуктовой аналитики.
Проблема почти никогда не в LLM. Она в поиске. И решения конкретны: размеры фрагментов, гибридный поиск, фильтры по метаданным, переранжирование и способ измерить полноту до того, как вы обвините модель. Эта статья разбирает реальную механику с работающим примером на pgvector/Qdrant и цифрами до/после, которые вы можете воспроизвести.
Почему векторный поиск кажется магией, пока не перестаёт
Векторная база данных хранит эмбеддинги — плотные числовые представления текста, изображений или аудио — и находит ближайших соседей по косинусному сходству или скалярному произведению. Она блестяще справляется с нечётким смыслом: «как отменить подписку» совпадает с «прекращение вашего плана», даже если нет ни одного общего слова.
Но та же нечёткость — это ловушка. Чистый поиск по эмбеддингам не имеет понятия о точных токенах. Если в вашем корпусе есть коды продуктов вроде SKU-4471 или номера юридических пунктов вроде Раздел 12.3(б), эмбеддинг SKU-4471 почти идентичен SKU-4472 — отличаются на одну цифру в тексте, почти та же точка в векторном пространстве. Поиск возвращает неверный SKU с высокой уверенностью, LLM его повторяет, и ваша служба поддержки получает тикет.
Пошаговый разбор: исправляем сломанный RAG-конвейер
Представьте B2B SaaS-компанию с 4000 статей поддержки, внутренней вики и RAG-ботом для команды по работе с клиентами. Бот хорошо отвечает на 70% вопросов и плохо на 30% — классическое соотношение. Вот как практик диагностирует и исправляет это по порядку.
Шаг 1: измерьте полноту поиска, прежде чем трогать промпт
Прежде чем что-либо менять, создайте небольшой оценочный набор: 50 реальных вопросов с отмеченным правильным исходным фрагментом. Затем вычислите recall@5 — долю вопросов, где правильный фрагмент появляется в топ-5 результатов. Если recall@5 ниже 0,8, никакой инжиниринг промптов вас не спасёт. В примере выше recall@5 был 0,61. LLM получала нерелевантный контекст в 4 случаях из 10.
Шаг 2: исправьте стратегию разбиения на фрагменты
Большинство команд начинают с фрагментов по 1000 токенов и без перекрытия. Это слишком много: фрагмент, охватывающий три темы, встраивается как размытое среднее, и поисковик вытаскивает его для любой из трёх. Решение — меньшие фрагменты с перекрытием, обычно 300–500 токенов с перекрытием 10–15% (30–75 токенов). Перекрытие не даёт предложению, пересекающему границу, разорваться пополам.
Ещё лучше: разбивать по структуре. Сначала по заголовкам, затем по абзацам и только потом по количеству токенов. Статья поддержки о возвратах должна давать один фрагмент на пункт политики, а не один фрагмент на всю страницу.
Шаг 3: добавьте гибридный поиск (BM25 + вектор)
Чистые эмбеддинги пропускают точные термины. BM25 — классическая функция ранжирования по ключевым словам — их ловит. Гибридный поиск запускает оба и объединяет оценки, обычно с помощью Reciprocal Rank Fusion (RRF): каждый результат получает оценку 1/(k + ранг), где k обычно равно 60, и оценки суммируются.
В нашем примере добавление BM25 решило проблему SKU-4471 и подняло recall@5 с 0,74 до 0,86. Это самое эффективное изменение в большинстве RAG-конвейеров.
Шаг 4: фильтрация по метаданным и ключи разделов
Если ваш бот обслуживает нескольких арендаторов, запрос от арендатора A никогда не должен извлекать фрагменты арендатора B. Решение — фильтр по метаданным tenant_id — или, в Qdrant, ключ раздела по этому полю, который физически изолирует данные для более быстрого фильтрованного поиска. В pgvector вы добавляете условие WHERE tenant_id = $1 рядом с сортировкой по вектору.
Шаг 5: переранжируйте топ-20
Переранжировщик на основе кросс-энкодера (например, небольшая модель на BERT) совместно оценивает каждую пару запрос-фрагмент и гораздо точнее косинусного сходства — но слишком медленный, чтобы работать по всему корпусу. Схема: извлеките топ-20 с помощью гибридного поиска, переранжируйте до топ-5, передайте их LLM. В нашем примере переранжирование подняло recall@5 до 0,93 и — что не менее важно — в большинстве случаев вывело правильный фрагмент на первое место, что снижает галлюцинации, поскольку LLM видит правильный контекст первым. Подробнее об этом — в статье LLM против сканера.
Шаг 6: работающий фрагмент кода на pgvector
Вот ядро гибридного поиска в PostgreSQL с pgvector:
-- векторный канал
SELECT id, content, 1 - (embedding <=> $1) AS score
FROM chunks
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 20;
-- лексический канал (полнотекстовый поиск PostgreSQL как замена BM25)
SELECT id, content, ts_rank(tsv, plainto_tsquery($3)) AS score
FROM chunks
WHERE tenant_id = $2 AND tsv @@ plainto_tsquery($3)
ORDER BY score DESC
LIMIT 20;
Затем объедините два набора результатов в коде приложения с помощью RRF. В Qdrant та же идея — один запрос с prefetch для каждого канала и fusion: "rrf".
Где ломается сама схема
Даже хорошо настроенный конвейер имеет режимы отказа, которые не исправить никаким разбиением. Замечайте их рано.
1. Запрос неоднозначен. «Как отменить?» может означать подписку, заказ или встречу. Поиск по эмбеддингам выбирает одну интерпретацию и уверенно её возвращает. Решение — переписывание запроса: попросите LLM расширить запрос в два-три варианта, извлеките по каждому и объедините. Цена: дополнительная задержка и токены.
2. Ответ охватывает несколько фрагментов. Политика, которая гласит: «возврат возможен в течение 30 дней, кроме годовых планов, которые не подлежат возврату после 14 дней», может быть разбита на два фрагмента. Поиск возвращает только один, и LLM отвечает половиной правды. Решение — извлечение родительского документа: встраивайте мелкие фрагменты, но возвращайте LLM более крупный родительский раздел. Компромисс: больше токенов контекста, выше стоимость запроса.
3. Корпус дрейфует. Добавляются новые статьи, редактируются старые, но эмбеддинги устаревают. Фрагмент, верный полгода назад, теперь противоречит текущей политике. Решение — инкрементальная переиндексация, запускаемая изменениями контента, плюс периодическое полное перевстраивание при обновлении модели эмбеддингов, поскольку векторы из разных моделей несопоставимы.
4. Модель эмбеддингов не подходит для предметной области. Модель общего назначения может не различать «нарушение SLA» и «промах SLO», если ваш корпус полон жаргона. Решение — либо дообученная на домене модель, либо, что дешевле, добавление канала по ключевым словам (который у вас уже есть с BM25).
Пути обучения и их реальные компромиссы
Вы можете изучить это, создавая, читая или на структурированном курсе. У каждого есть своя цена.
Самостоятельное изучение дешевле всего по деньгам и дороже всего по времени. Вы подключите pgvector по статье из блога за один день, но не поймёте, почему recall равен 0,6 — вы неделю будете крутить промпты, прежде чем заподозрите разбиение. Ловушка в том, что сбои RAG выглядят как сбои LLM.
Создание побочного проекта — лучший учитель, если у вас есть реальный корпус и реальные вопросы. Возьмите вики вашей компании, постройте бота и измерьте recall@5 на 50 вопросах. Цена — часы, которые вы тратите на отладку в одиночку, без кого-либо, кто проверит ваш оценочный набор на предвзятость.
Структурированный курс обменивает деньги на карту. Ценность в сравнениях — pgvector против Qdrant против Pinecone, HNSW против IVF против DiskANN, когда гибридный поиск стоит сложности, а когда нет — и в том, что кто-то проверяет ваши решения. Если вам нужна эта карта, Векторные базы данных — от поиска до RAG проходит именно по этим компромиссам с работающим кодом и таблицами сравнения; уроки персонализированы и адаптируются к вашему уровню. Для более широкого взгляда на то, как LLM ошибаются в технических задачах, см. нашу статью о том, почему LLM угадывают CVE и как заставить их работать по-настоящему.
Кому подходит этот путь — и кому нет
Эта работа подходит инженерам, которые любят отлаживать системы, а не только модели. Если вам нравится создавать оценочные наборы, читать кривые полноты и спорить о размерах фрагментов, вы будете процветать. Она также подходит инженерам данных, переходящим в инфраструктуру ИИ, потому что навыки — индексирование, фильтрация, масштабирование — знакомы.
Она не подходит людям, которые хотят «просто использовать API». Управляемые векторные базы данных легко запустить и трудно настроить; настройка — это и есть ценность, и она требует терпения к цифрам. Она также не подходит тем, кто ожидает, что один инструмент решит проблему поиска — гибридный поиск, переранжирование и оценка все необходимы, и ни один не является опциональным в продакшене.
Если вы когда-нибудь видели, как RAG-бот уверенно отвечает на неправильный вопрос, вы уже знаете, почему это важно. Решение не в лучшем промпте — в лучшем конвейере поиска. Начните с измерения recall@5 на вашем собственном корпусе, затем проработайте разбиение, гибридный поиск и переранжирование в этом порядке. Для структурированного пути через компромиссы Векторные базы данных — от поиска до RAG охватывает весь конвейер с работающими примерами и обратной связью по вашим решениям.