Запрос, поиск и генерация

Конвейер запросов — это онлайн-часть RAG, то есть код, который выполняется в реальном времени, когда пользователь задаёт вопрос. Он связывает все компоненты, созданные во время индексации: модель эмбеддингов, векторное хранилище, шаблон запроса и LLM. Хорошо реализованный конвейер запросов завершается менее чем за 500 мс для большинства рабочих нагрузок и создаёт обоснованные ответами источников ответы с цитатами. В этом уроке мы с нуля создадим каждый этап.

На первом шаге естественно-языковой вопрос пользователя преобразуется в векторный эмбеддинг с помощью той же модели, которая использовалась при индексации. Этот эмбеддинг кодирует смысл вопроса и будет сравниваться с эмбеддингами фрагментов документов в векторном хранилище. Сделайте этот шаг быстрым: используйте лёгкую модель, например text-embedding-3-small, и кэшируйте эмбеддинги для повторяющихся идентичных запросов.

Отправьте вектор запроса в векторное хранилище, чтобы найти K наиболее близких по смыслу фрагментов. Возвращённые совпадения ранжируются по показателю косинусного сходства (обычно от 0,0 до 1,0; чем выше, тем лучше). Идеальное значение K обеспечивает баланс между информативностью контекста и расходом окна контекста: распространённая начальная настройка — K=5. Здесь также можно применить фильтры метаданных, чтобы ограничить поиск конкретным подразделением, типом документа или диапазоном дат.

Не все извлечённые фрагменты действительно релевантны: некоторые могут иметь низкие показатели сходства, но всё равно попасть в число K лучших, если запрос выходит за пределы охвата индекса. Применяйте минимальный порог оценки, чтобы отфильтровать совпадения с низкой уверенностью. Если все извлечённые фрагменты ниже порога, верните ответ «информация не найдена», вместо того чтобы отправлять нерелевантный контекст в LLM: это привело бы к худшему ответу, чем корректный отказ.

Объедините извлечённые фрагменты в структурированный блок контекста, который прочитает LLM. Пометьте каждый фрагмент его источником, чтобы модель могла точно указать цитату. Для ясности добавьте разделитель между фрагментами. Удерживайте общий контекст в пределах бюджета токенов: подсчитывайте токены с помощью tiktoken и сокращайте контекст или удаляйте фрагменты с более низкими оценками, если превышен лимит. Блок контекста вставляется в запрос между системной инструкцией и вопросом пользователя.

Объедините блок контекста, системную инструкцию и вопрос пользователя в итоговый запрос. Системное сообщение сообщает модели, что нужно использовать только предоставленный контекст и указывать источники. Сообщение пользователя содержит отформатированный контекст, за которым следует вопрос. Такое чёткое разделение не позволяет модели смешивать содержимое контекста с вопросом и однозначно обозначает границу между извлечёнными данными и вводом пользователя.

Отправьте подготовленный запрос в LLM с помощью API Chat Completions. Для фактических вопросов и ответов используйте низкую температуру (от 0,0 до 0,3), чтобы получать стабильные ответы, основанные на контексте. Более высокая температура делает ответы творческими, но повышает риск того, что модель добавит сведения, отсутствующие в контексте. Обработайте ответ и верните как текст ответа, так и извлечённые источники, чтобы приложение могло отобразить пользователю цитаты.

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

В конвейере запросов есть два шага, ограниченных операциями ввода-вывода: вызов для создания эмбеддинга и вызов LLM. Выполняйте их без лишних ожиданий: вызов для создания эмбеддинга быстрый (<100 мс), а вызов LLM медленный (500 мс–3 с). Чтобы уменьшить воспринимаемую задержку, передавайте ответ LLM потоково, чтобы токены появлялись по мере генерации, а не после ожидания полного ответа. Кэшируйте эмбеддинги повторяющихся идентичных запросов, чтобы избежать лишних вызовов API.

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

Если Ваше приложение получает много повторяющихся или почти идентичных запросов, например в ботах FAQ, где пользователи часто задают одни и те же вопросы, кэширование эмбеддингов запросов становится простой и очень эффективной оптимизацией. Получите хеш строки запроса, проверьте в кэше Redis соответствующий эмбеддинг и вызывайте API эмбеддингов только при отсутствии записи в кэше. В промышленных FAQ и чат-ботах поддержки доля попаданий в кэш эмбеддингов часто составляет 30–60 %, что существенно снижает расходы на API и уменьшает задержку на 50–100 мс для каждого запроса, обработанного из кэша.

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