← Query Engine

RAG-маршрут

query-engine · workzone

Ядро grounding-режима: как вопрос превращается в обоснованный ответ, когда модель решает искать. RAG здесь — маршрут: вызвав search_knowledge, модель спускает запрос через пять шагов — Embed → Retrieve → Rerank → Augment → Generate. Решение позвать инструмент и сам самостоятельный запрос — за моделью (решение о поиске); зона ответственности маршрута — переранжирование, упаковка контекста и grounding-генерация; эмбеддинг запроса и сам поиск принадлежат Knowledge Store. Кто какой моделью работает — на карте моделей; где один раунд инструментов кончается и начинается агентный цикл — на границе.

Маршрут поиска: запрос спускается через пять слоёв

Маршрут — тело инструмента search_knowledge: он запускается, когда модель решила искать и передала самостоятельный запрос. Один проход сверху вниз: шаги 1–2 (embed · retrieve) исполняет Knowledge Store, шаги 3–5 (rerank · augment · generate) — Query Engine. На входе — кэш-гейт: повторный идентичный поиск той же личности отдаёт кандидатов из кэша, минуя дорогой embed/retrieve. Граница между сторонами проходит по слою, а не между секциями: тот же стек показывает, где storage отдаёт кандидатов, а RAG их доводит.

◇ Точный кэш? ключ = самостоятельный запрос + identity
hit ──▶ кандидаты из кэша · минуя embed + retrieve
miss ▼ маршрут идёт дальше
1 Embed Knowledge Store Запрос → вектор.
Эмбеддинг запроса
Самостоятельный запрос превращается в вектор той же моделью эмбеддинга, что строила индекс — общий платформенный эмбеддер (Harvester / KS), не настройка Query Engine. Шаг исполняет Knowledge Store; Query Engine лишь передаёт текст и identity пользователя. Механику поиска держит retrieval · граница.
2 Retrieve Knowledge Store Собранный hybrid-результат под правами.
Один вызов — слитые кандидаты
Query Engine берёт готовый hybrid-результат из Knowledge Store одним запросом: четыре примитива поиска, их слияние (fusion / RRF) и ACL pre-filter — всё внутри KS, под identity пользователя. Query Engine схему прав не строит и не видит — identity это вход, кандидаты под правами это выход. Маппинг личности на source-аккаунты держит retrieval · личность.
3 Rerank Query Engine Переупорядочить кандидатов под вопрос.
Порядок из KS, без модели
В v1 переранжирование опирается на RRF-порядок, уже собранный Knowledge Store, — отдельной модели нет. Cross-encoder reranker, переоценивающий top-N парами «запрос × кандидат», — отдельный шаг v2; разобран на карте rerank.
4 Augment Query Engine Упаковка контекста под модель.
Сборка промпта
Отобранные кандидаты упаковываются в контекст модели:
  • Лучший фрагмент как доказательство — при каждой сущности один самый показательный фрагмент, не весь её материал: размен полноты на разнообразие источников.
  • Отсечка под общий бюджет окна — фрагменты укладываются от важного к менее важному и обрезаются не по всему окну, а под остаток, что оставила история: место делит бюджет контекстного окна, удерживая резерв под ответ.
  • Разметка источников для цитирования — у каждого фрагмента метка происхождения, чтобы ответ мог на него сослаться.
  • Историю augment не дублирует — модель уже держит её в окне как ведущий ход, поэтому в упаковку идут только найденные фрагменты, а не вторая копия истории. Связность follow-up («разверни прошлый пункт») даёт та же история в окне; доказательная база ответа — лишь найденное.
Сверху всего ложится платформенный prompt — общий слой безопасности и правил организации, который Admin задаёт раз на инстанс; дальше идут найденные фрагменты. Здесь же закрепляется правило grounding — отвечать только из вложенного контекста; формулировку честного «не нашёл» держит grounding. Найденный контент — недоверенный вход: фрагменты подаются как данные, не как инструкции модели; усиленная защита от prompt injection — v2.
5 Generate AI Query Engine Строит ответ на найденном — та же chat-модель.
Grounding-генерация
Упакованный контекст возвращается той же chat-модели, что позвала инструмент — той, что пользователь выбрал в чате и ведёт диалог, не отдельной платформенной. Она строит ответ строго на найденном и стримит его синхронно, с цитированием источников. Раскладку моделей по шагам держит карта моделей.
Knowledge Store шаги 1–2 · embed + retrieve
▸
Query Engine шаги 3–5 · rerank + augment + generate
Карта моделей: кто чем работает
ведёт ход + generate AI
Выбранная chat-модель

Та модель, что пользователь выбрал в чате, ведёт весь ход: решает, звать ли search_knowledge, формулирует самостоятельный запрос и строит ответ на найденном. Не отдельная платформенная «модель RAG» и не служебный роутер. Назначается в admin · AI-модели.

embed AI
Общий эмбеддер

Эмбеддинг запроса — тем же платформенным эмбеддером, что строил индекс (Harvester / KS). Иначе вектор запроса и вектор чанков несравнимы.

rerank v2
v1 — без модели

В v1 переранжирование — RRF-порядок из Knowledge Store, без инференса. Cross-encoder reranker как модель — v2.

Rerank: RRF сейчас, cross-encoder потом

Переранжирование решает, что из кандидатов попадёт в контекст и в каком порядке. Развилка по итерациям, не по альтернативам — v2 надстраивается над v1, а не заменяет.

RRF из KS

Порядок берётся прямо из собранного hybrid-результата: Knowledge Store уже слил списки примитивов по reciprocal rank fusion. Query Engine упаковывает кандидатов в том порядке, что пришёл.

Cross-encoder reranker v2

Отдельная модель переоценивает top-N кандидатов парами «запрос × кандидат» — точнее RRF, потому что видит запрос и текст вместе, а не складывает позиции.

Граница: один раунд инструментов, агенты — дальше

Граница не в том, есть ли у модели инструменты, а в том, есть ли цикл. У chat-модели Query Engine — один раунд инструментов за ход: она может позвать несколько параллельно (например search_knowledge + web_search), получить результаты и обязана ответить. Петли нет — за раундом не следует второй раунд по итогам первого. Это держит ответ предсказуемым и отделяет диалоговый ход от полноценного агента. Сам tool-calling под обоими — общий харнесс: граница ниже — это его параметризация, один раунд против петли.

Query Engine один раунд инструментов

За ход модель делает один раунд: зовёт ноль, один или несколько инструментов разом (KB + веб-поиск), получает результаты и строит ответ. Без планирования и без второго раунда по итогам первого.

▸
Agent Engine агентный цикл

Многошаговый и инструментальный reasoning — циклы поиска, выбор инструмента из набора, планирование — у → Agent Engine, который вызывает примитивы Knowledge Store напрямую, минуя Query Engine.

v2 — многораундовый агентный чат: модель планирует и идёт несколькими раундами в самом диалоге, дочитывая по итогам предыдущего. Надстройка над одним раундом, а не граница доступа.

v2-исключение к одному вызову: при низкой уверенности в кандидатах Query Engine делает ограниченный (N=1) повторный поиск перед тем, как ответить «не нашёл», — одна попытка переформулировать и переспросить, не полноценный агентный цикл. Сам ответ «не нашёл» и его честность держит grounding.