Сервис RAG с опорой на источники

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

Теперь сделай векторы доступными для запросов. Загрузи каждый эмбеддинг вместе с метаданными в векторное хранилище, затем возьми входящий вопрос, построй для него эмбеддинг тем же способом и достань top-k ближайших чанков по косинусной близости или скалярному произведению. Первая ловушка — несовпадение метрики или нормализации между тем, как ты хранил векторы, и тем, как их запрашиваешь: расстояния выглядят правдоподобно, но ранжируют не те чанки первыми, и ты этого не заметишь, пока опора не поедет вкось. Вторая ловушка — относиться к top-k как к магическому числу: слишком мало — и подтверждающий факт оказывается чуть вне досягаемости, слишком много — и ты набиваешь контекст почти-промахами, которые соблазняют модель уплыть. Прозондируй: задай несколько вопросов с известными ответами, выведи найденные чанки с их оценками и убедись, что нужный фрагмент реально оказывается у верха. Этот слой поиска — фундамент, на котором стоит каждый следующий этап.

Это этап, который превращает строку поиска в сервис RAG. Передай найденные чанки модели с промптом, который строго делает две вещи: отвечает только по предоставленному контексту и указывает id чанка за каждым утверждением. Когда в контексте нет ответа, правильный вывод — «по этим источникам не знаю», а не уверенная догадка, сшитая из претрейна модели. Сделай цитаты контрактом, а не пожеланием: распарси вывод модели, проверь, что каждый процитированный id реально был в найденном наборе, и отклони или почини ответ, который ссылается на чанк, который ты не отправлял. Структурированный вывод или tool-calling здесь помогает, потому что свободный текст «Источники: ...» расползается и его мучительно проверять. Сам сверь несколько ответов с процитированными чанками — в момент, когда поймаешь модель на цитировании чанка 7 под предложение, которое чанк 7 не подтверждает, ты поймёшь, почему опору нужно принуждать, а не доверять ей.

Пока ты не можешь это измерить, «ответы выглядят хорошо» — это ощущение, а не гарантия, и ощущения тихо деградируют в следующий раз, когда ты подправишь промпт или сменишь модель эмбеддингов. Собери фиксированный eval-набор: список вопросов по корпусу, каждый в паре с эталонным подтверждающим фрагментом и ожидаемой сутью. Затем оценивай каждый ответ на faithfulness — действительно ли каждое утверждение прослеживается до процитированного чанка? — наряду с более дешёвыми сигналами вроде recall поиска (нашёлся ли нужный чанк вообще?) и корректности воздержания (сказал ли он «не знаю» ровно тогда, когда должен?). Оценивать можно LLM-судьёй, которому дают ответ и его источники, но зафиксируй промпт судьи и выборочно проверяй его вердикты, ведь ненадёжный оценщик просто отмывает проблему. Свяжи харнес так, чтобы он запускался по требованию и выдавал единственное число faithfulness; именно это число позволяет менять что угодно в пайплайне и сразу видеть, стало ли лучше или тихо хуже.

У чистого векторного поиска есть слепое пятно: он силён в смысле, но слаб на точных токенах — артикул, код ошибки, редкое имя собственное, которое эмбеддинг размазывает в соседние понятия. Добавь лексический ретривер (BM25 или полнотекстовый поиск твоего хранилища) и слей его результаты с векторными попаданиями, например через reciprocal rank fusion, чтобы чанк, который и означает нужное, и содержит точный термин, поднимался наверх. По желанию переранжируй слитых кандидатов кросс-энкодером для финального прохода на точность. Дисциплина тут — доказать, что гибрид реально помогает: перепрогони eval-набор с прошлого этапа и покажи, что recall поиска и faithfulness растут, а не стоят на месте. Если нет — ты добавил задержку и сложность впустую; скажи это честно, а не держи более тяжёлый пайплайн потому, что он звучит солиднее.

Eval-набор ловит регрессии пачкой; барьер ловит их на живом запросе, прежде чем плохой ответ дойдёт до пользователя. Добавь проверочный проход, который по черновику ответа и процитированным чанкам проверяет, что каждое утверждение действительно следует из найденного, — проверка вторым моделью «подтверждает ли это источник?» или более строгий разбор, отбрасывающий любое предложение, чья цитата не выдерживает. Когда утверждение не проходит, сервис должен деградировать безопасно: срезать неподтверждённое предложение, понизить уверенность или воздержаться — но никогда не выпускать выдумку. Затем сделай всё это наблюдаемым, ведь обоснованный сервис, который падает молча, — это просто уверенный лжец с лишними шагами: логируй на каждый запрос id и оценки найденных чанков, какие утверждения прошли или были отброшены, сработал ли барьер и стоимость в токенах, чтобы по жалобе на неверный ответ ты мог воспроизвести ровно то, что было найдено и почему модель сказала то, что сказала. Считай частоту срабатывания барьера продакшен-сигналом, за которым следишь, а не галочкой, которую поставил однажды.