Как встроить вызовы инструментов в поиск и не сломать отбор кандидатов, повторное ранжирование и контроль

TL;DR: Вызовы инструментов не заменяют поисковую систему. В продакшне они добавляют второй контур управления поверх разбора запроса, отбора кандидатов, ранжирования и повторного ранжирования. Цель не в максимальном числе вызовов. Цель в том, чтобы вызывать инструменты там, где они расширяют покрытие или полезность ответа, не ломая качество, задержку, надежность, безопасность и возможность отката.

Агентный поиск (agentic search) пока остается размытым рыночным термином. AWS использует формулировку “agentic search”, OpenSearch OSS 3.2 отдельно помечает свою реализацию как экспериментальную и без рекомендации для продакшна, а Azure AI Search говорит про “agentic retrieval” и в текущем сценарии настройки все еще пишет про public preview без SLA и без рекомендации для production-нагрузок (пример). Названия различаются, но задача управления одна и та же: как только в поисковую систему попадают вызовы инструментов (tool calling), у нее появляется второй контур управления.

Этот контур не создает новый поисковый стек, а добавляет ограниченный слой возможностей поверх разбора запроса, отбора кандидатов (retrieval), ранжирования, повторного ранжирования (reranking) и продуктовых ограничений. Отбор кандидатов и повторное ранжирование по-прежнему решают, какие свидетельства вообще допускаются к конкуренции и что продукт готов показывать первым.

Главный вопрос для эксплуатации не в том, умеет ли модель вызвать инструмент. Главный вопрос в том, где место инструмента в поисковом цикле, что он вправе менять и как быстро система возвращается на безопасный базовый путь, если инструмент начинает вести себя хуже. Если второй контур не ограничен бюджетами, не наблюдаем и не зажат правилами, качество, дисциплина задержек и ответственность за поведение начинают плыть раньше, чем ломается демонстрация.

Интерфейсы agentic retrieval уже начинают прямо задавать бюджеты рассуждения и времени работы. Например, Azure задает retrievalReasoningEffort и maxRuntimeInSeconds. Это правильный инженерный инстинкт: слово agentic в продакшне должно означать ограниченный шаг планирования с явным бюджетом, а не безразмерное “умное поведение”.

Основной поисковый контур и второй контур управления, который появляется после добавления вызовов инструментов.

Что такое агентный поиск в продакшн-поиске

Самое полезное в работе определение обычно и самое прозаичное:

Агентный поиск это поисковая система с ограниченными вызовами инструментов поверх отбора кандидатов и повторного ранжирования.

Эта формулировка сразу разводит три уровня:

1. Поисковая система: разбор запроса, отбор кандидатов, ранжирование, повторное ранжирование и продуктовые ограничения.
2. Слой возможностей: инструменты для обогащения, проверки, прав доступа, актуальности и согласованных действий.
3. Слой рабочего процесса: релизные гейты, согласование, фолбэк-пути, наблюдаемость и дисциплина отката.

Если эти уровни смешать, чисто приписывать регрессии не получится. Один и тот же пользовательский сбой может идти из переписывания запроса, дрейфа отбора кандидатов, потери признаков на повторном ранжировании, задержки инструмента, политики согласования или ошибки действия.

Недавние работы вроде SoK: Agentic RAG и Is Agentic RAG Worth It? подводят к тому же выводу: как только отбор свидетельств и вызовы инструментов становятся последовательными решениями, оценка качества усложняется, а режимы отказа начинают быстро множиться.

Почему отбор кандидатов и повторное ранжирование остаются главным контуром управления

В рабочем поиске отбор кандидатов и повторное ранжирование это точки управления, а не просто стадии качества.

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

В этой статье под ranking я имею в виду более широкую политику упорядочивания по всему стеку, а под reranking более дорогой финальный шаг уточнения поверх уже найденного набора кандидатов. Проблема управления становится особенно острой именно на шаге повторного ранжирования, поэтому этот термин я сохраняю явным.

Поэтому базовая архитектура все еще должна выглядеть так:

запрос пользователя
  -> разбор запроса по схеме
  -> отбор кандидатов
  -> ранжирование / повторное ранжирование
  -> ограниченное обогащение верхних результатов
  -> ответ или следующий шаг
  -> при необходимости согласованный шаг действия

А не так:

запрос пользователя -> агент думает -> агент вызывает инструменты -> агент сам решает, что важно

В первом варианте сохраняется поисковый контракт. Во втором критичные решения по ранжированию уезжают в открытый цикл. Если результат инструмента может незаметно вытолкнуть выше результаты, уже упорядоченные финальным ранжированием, управление релевантностью уже сломано.

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

Что слою инструментов запрещено менять

Рабочей поисковой системе нужны не только положительные сценарии применения, но и отрицательные границы.

Инструментам можно:

• извлекать структурированный смысл запроса до отбора кандидатов;
• обогащать верхнюю часть выдачи после повторного ранжирования;
• выполнять согласованное действие после выбора ответа.

Инструментам нельзя:

• незаметно переопределять результаты повторного ранжирования;
• расширять область доступа;
• прятать отсутствующие признаки или частичные сбои;
• превращать недоверенный текст из найденных документов в привилегированные инструкции;
• лишать систему возможности мгновенно вернуться на базовый путь без инструментов.

Именно это и есть контракт агентного поиска. Инструменты расширяют стек, но не подменяют собой власть отбора кандидатов, повторного ранжирования, политики и отката.

Результаты инструментов должны входить в систему как типизированные признаки, а не как свободный текст

Самый безопасный способ встроить результат инструмента в поиск это заранее решить, в каком представлении он войдет в стек.

До отбора кандидатов результат инструмента должен превращаться в типизированные признаки запроса: права доступа, фильтры, нормализованные сущности или выбор индекса.

После повторного ранжирования результат инструмента должен превращаться в поздние признаки результата или в ограниченное свидетельство, привязанное к конкретным кандидатам: наличие, право доступа, актуальность, статус ограничения или поправку уверенности, связанную с конкретным объектом.

Перед действием результат инструмента должен превращаться в состояние политики или состояние согласования, а не в автономное исполнение.

Во что он не должен превращаться, так это в блок свободного текста, который начинает играть роль нового источника авторитета. Такой текст трудно валидировать, сопоставлять между кандидатами, кэшировать и удерживать внутри политики ранжирования. Рекомендации по структурированным инструментам от OpenAI, Anthropic и актуальная schema reference для MCP указывают в одну сторону: ограниченная структура масштабируется лучше, чем рассказы инструмента о самом себе.

Если результат инструмента нельзя представить как валидированный признак, ограниченное свидетельство или явное состояние согласования, ему, скорее всего, не место в критичном поисковом пути.

Результаты инструментов должны входить в поиск как типизированные признаки, ограниченные свидетельства или состояние согласования.

Где вызывать инструменты в поисковой системе

Самый безопасный способ добавить инструменты в поисковую систему это заранее зафиксировать их место в контуре.

Три допустимые точки для вызовов инструментов в рабочем поисковом контуре.

До отбора кандидатов

Здесь инструменты нужны только для узких задач разбора:

• проверка прав доступа;
• выбор индекса или вертикали;
• извлечение фильтров по схеме;
• нормализация сущностей.

Этот этап нужен для структуры, а не для свободного исследования. Его результат должен оставаться машинно проверяемым и ограниченным.

После повторного ранжирования

Это самое естественное место для инструментов в поисковом контуре:

• проверка наличия;
• обновление цены или срока обслуживания;
• проверка прав доступа;
• поиск ограничений или политик;
• проверка актуальности верхних результатов.

В этой схеме отбор кандидатов и повторное ранжирование сначала решают, на что вообще стоит тратить бюджет инструментов. Инструменты обогащают верхнюю часть выдачи, а не меняют всю траекторию поиска.

После выбора ответа

Здесь поиск уже переходит в рабочий процесс:

• создать заявку на основе выбранного результата;
• забронировать товар после подтверждения пользователем;
• открыть обращение к продавцу;
• запустить ограниченный шаг по регламенту.

Это может быть полезно, но переводит систему в более рискованный класс эксплуатации. Как только система получает возможность действовать, ей нужны согласование, минимальные права, идемпотентность и трассируемость. Это уже заметно ближе к дисциплине релизов и политик, описанной в статье MLOps для RAG-агента поддержки в 2026 и к архитектурным компромиссам из статьи Агент или workflow: как выбрать архитектуру без хайпа.

Рабочее правило здесь простое:

• до отбора кандидатов для разбора запроса;
• после повторного ранжирования для обогащения;
• после выбора ответа для согласованного действия.

Если один и тот же запрос по умолчанию тянет инструменты во всех трех точках, значит системе не хватает более жестких бюджетов.

Где нужен мягкий отказ, а где жесткий

Правильная политика при отказе зависит от того, что инструмент вообще вправе менять.

Роль инструмента	Политика при отказе по умолчанию	Что недопустимо	Что увидит пользователь
Проверка прав доступа перед отбором кандидатов	Жесткий отказ на расширение области доступа, при необходимости мягкий откат на более узкий безопасный путь	Нельзя расширять доступ только потому, что проверка не сработала	Меньше результатов допустимо, несанкционированные результаты недопустимы
Разбор запроса перед отбором кандидатов	Откат на исходный запрос и базовый путь	Нельзя заменять здоровый базовый путь неподтвержденным переписыванием	Базовая выдача остается доступной
Обогащение верхних результатов после повторного ранжирования	Откат на базовую выдачу с подавлением неподтвержденных утверждений	Нельзя позволять отсутствующим признакам незаметно перетасовать выдачу	Ответ строится без живого утверждения, порядок базовой выдачи сохраняется
Действие после выбора ответа	Жесткий отказ за контуром согласования	Нельзя выполнять побочный эффект при таймауте, двусмысленности или отказе в согласовании	Путь ответа остается доступным, путь действия выключается

Политика при отказе зависит от того, что инструменту вообще разрешено менять.

Четыре рабочих паттерна для отбора кандидатов, повторного ранжирования и вызовов инструментов

Паттерн	Когда использовать	Основная польза	Главный риск	Влияние на задержку	Что нужно для управляемости	Стратегия отката
Структурированный разбор до отбора кандидатов	Шумные запросы, поиск с правами доступа, извлечение фильтров, маршрутизация между индексами	Улучшается структура запроса без смены поискового контракта	Переписывание запроса начинает уходить от исходного намерения	Низкое или среднее	Строгие схемы, ограниченный выходной контракт, логирование исходного и интерпретированного запроса	Возврат к исходному запросу и базовому поиску
Поиск первым, инструменты только по правилам	Базовый поиск закрывает большинство запросов, а части из них нужны уточнение или проверка актуальности	Главный поисковый путь сохраняется, бюджет инструментов тратится только на спорные случаи	Со временем эскалация в инструменты превращается в путь по умолчанию	Низкое для основной массы трафика, среднее для эскалаций	Явные правила эскалации, бюджеты инструментов на запрос, понятные пороги отката	Ответ из базовой выдачи с более узкими утверждениями или меньшей уверенностью
Обогащение верхней части выдачи после ранжирования	Качество выдачи зависит от динамических признаков: наличия, прав доступа, политик	Свежие сигналы повышают точность там, где это действительно важно	Частичные сбои инструментов искажают повторное ранжирование	Среднее	Таймауты на инструмент, значения по умолчанию для признаков, проверки устойчивости повторного ранжирования	Сохранить базовую выдачу и пометить обогащение недоступным
Действие после ответа через согласование	Пользователю нужно, чтобы система действовала после выбора результата	Выше завершение задачи без выхода из поискового сценария	Побочные эффекты, злоупотребление доступом, дубль действий	Среднее или высокое	Контур согласования, минимальные права, ключи идемпотентности, журнал действий	Путь ответа остается, путь действия выключается, дальше эстафета у детерминированного процесса

Самый частый провал здесь это скачок прямо от разбора запроса к действию. Именно так команды получают демонстрации, богатые на действия, но бедные на надежность поиска.

Если нужен пример от платформенной команды, где агентный сценарий остается retrieval-first и держится на контуре поиска, этот доклад Microsoft Build лучше всего дополняет архитектуру из статьи.

Доклад Microsoft Build про agentic retrieval в Azure AI Search и архитектуру, где поиск остается главным контуром.

Как держать вызовы инструментов под контролем

Вызовы инструментов нужно держать в такой же дисциплине, как и любой другой рабочий интерфейс.

1. Строгие схемы и ограниченный выходной контракт

И function calling guide от OpenAI, и рекомендации Anthropic по writing tools for agents, и актуальные разделы MCP про tools и schema reference подводят к одному рабочему правилу: если инструмент принимает произвольную форму входа и возвращает произвольный текст, он не готов к эксплуатации. В терминах OpenAI это и есть место, где становится важен режим strict.

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

Более сильный контракт выглядит так. inputSchema, outputSchema и annotations здесь соответствуют текущему набору возможностей MCP, а slo, execution и ownership добавляют уже собственно рабочую политику поверх него:

{
  "name": "inventory_lookup",
  "title": "Inventory Lookup",
  "description": "Return live availability for a bounded set of catalog items.",
  "inputSchema": {
    "type": "object",
    "required": ["skuIds", "region"],
    "properties": {
      "skuIds": {
        "type": "array",
        "items": { "type": "string" },
        "maxItems": 20
      },
      "region": { "type": "string" },
      "timeoutMs": { "type": ["integer", "null"] }
    },
    "additionalProperties": false
  },
  "outputSchema": {
    "type": "object",
    "required": ["items"],
    "properties": {
      "items": {
        "type": "array",
        "items": {
          "type": "object",
          "required": ["skuId", "availability", "updatedAt"],
          "properties": {
            "skuId": { "type": "string" },
            "availability": {
              "type": "string",
              "enum": ["in_stock", "low_stock", "out_of_stock"]
            },
            "updatedAt": { "type": "string" }
          },
          "additionalProperties": false
        }
      }
    },
    "additionalProperties": false
  },
  "annotations": {
    "readOnlyHint": true,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  },
  "execution": {
    "taskSupport": "forbidden"
  },
  "slo": {
    "p95Ms": 250,
    "failPolicy": "open_to_reranked_baseline"
  },
  "ownership": {
    "team": "catalog-platform",
    "approvalRequired": false
  }
}

Здесь важны две детали. Во-первых, outputSchema уменьшает дрейф контракта между владельцами инструмента и владельцами поиска. Во-вторых, подсказки про изменяемость, идемпотентность и замкнутость мира помогают понять, место ли такому инструменту на пути ответа, на пути действия или ему вообще нельзя попадать в критичный контур.

Подсказки не заменяют доверие. Если сервер не относится к доверенной зоне, клиент не должен слепо верить его самоописанию. Правило здесь простое: строгие схемы это не косметика. Это граница между вызовом инструмента и строковой автоматизацией без контракта.

2. Списки разрешенных инструментов и дисциплина вызовов

Модель не должна узнавать свою власть уже во время выполнения.

Нужны явные управляющие примитивы:

• tool_choice, если рабочий поток должен принудительно разрешать, запрещать или сужать поведение инструмента;
• allowed_tools или аналогичный белый список, если на конкретном этапе доступна только часть инструментов;
• запрет параллельных вызовов там, где детерминизм важнее голой пропускной способности, например parallel_tool_calls=false;
• отдельные каталоги инструментов по этапам вместо одного общего списка на все случаи.

Здесь же начинается дисциплина кэша и токенов. Описания инструментов и результаты вызовов конкурируют за место с поисковым контекстом. Большие каталоги и раздутые ответы - простой способ заплатить больше и получить меньше ясности.

В текущих интерфейсах function calling параметр allowed_tools работает еще и как примитив контроля стоимости. Он позволяет сузить список вызываемых инструментов без постоянной замены полного каталога и тем самым помогает сохранить выгоду от prompt caching.

3. Контур согласования и границы доверия в MCP

Если стек использует MCP, версию протокола нужно фиксировать, а транспорт и доверие считать отдельной частью архитектуры. На 21 марта 2026 года актуальная ревизия спецификации MCP это 2025-11-25, а самые важные детали для этой статьи лежат в разделах tools, authorization и transports.

Для рабочего контура из этого следуют практические правила:

• удаленные инструменты нужно считать границей доверия;
• для действий с высоким влиянием требуется согласование;
• права на чтение и запись должны быть разделены;
• доверенные коннекторы лучше случайных сторонних прокси;
• у каждого инструмента должен быть владелец и понятный путь ревью.

Актуальные материалы OWASP по MCP полезно включать в тот же цикл ревью: cheat sheet по сторонним MCP-серверам и руководство по безопасной разработке MCP-сервера отдельно подчеркивают проверку подлинности, разграничение прав, песочницы, безопасное обнаружение, изоляцию сессий и аудит. Для качества поиска это не посторонние темы. Именно они определяют, какой объем власти слой инструментов вообще может безопасно получить.

3.5 Права доступа, согласие и границы токенов входят в контроль ранжирования

Ошибки в правах доступа живут не рядом с качеством поиска. Они его искажают.

Если инструмент может расширить область доступа, переслать не тот токен или пройти мимо контура согласования, это не только проблема безопасности. Такая ошибка меняет, какие документы, сущности или действия вообще получают право попасть в пользовательский путь.

Для интеграций на базе MCP это означает четыре явных правила:

• для удаленных MCP-инструментов согласование по умолчанию включено;
• MCP-сервер проверяет, что токены выпущены именно для этого сервера;
• токены никогда не прокидываются дальше в upstream API;
• права на чтение, права на запись и контуры согласования разведены.

И MCP and connectors guide от OpenAI, и рекомендации OpenAI по безопасности агентных систем, и сама спецификация authorization в MCP подводят к одной и той же рабочей модели. Поэтому согласие и контур доверия должны проходить тот же архитектурный разбор, что и политика ранжирования. Если система может тихо пересечь границу доверия, она может так же тихо поменять и контракт выдачи.

4. Оценка по трассам и метрики времени работы

В рабочей системе качество управления важнее качества отдельной подсказки.

Нужна трасса, которая покрывает:

• исходный запрос;
• интерпретированный запрос;
• кандидатов после отбора;
• поверхность решения на этапе повторного ранжирования;
• число вызовов инструментов;
• задержку и частоту ошибок инструментов;
• выбранный путь отката;
• итоговый ответ или действие;
• бизнес-результат.

Именно здесь trace grading у OpenAI и трассировка в Agents SDK перестают быть приятным дополнением. На стороне телеметрии полезно опираться на семантические соглашения OpenTelemetry для GenAI, но с важной оговоркой: на текущий момент эти соглашения все еще имеют статус Development, поэтому фиксация версии и аккуратная миграция входят в сам объем работ.

Без этого слоя любой отказ начинает выглядеть одинаково: качество выдачи стало хуже.

4.5 Телеметрический контракт для второго контура управления

Трасса полезна только тогда, когда по ней можно быстро ответить на вопрос о регрессии.

Для каждой плохой сессии инженер на дежурстве должен понимать:

1. Изменила ли интерпретация исходный запрос.
2. Упал ли уровень отбора кандидатов.
3. Потеряло ли повторное ранжирование покрытие признаков.
4. Сработал ли таймаут инструмента, ошибка или отказ в согласовании.
5. Вернулась ли система на безопасный путь без лишней деградации.

Как минимум стоит логировать:

• исходный и интерпретированный запрос;
• число кандидатов и срез качества на этапе отбора;
• покрытие признаков повторного ранжирования;
• gen_ai.client.operation.duration;
• gen_ai.client.token.usage;
• mcp.client.operation.duration;
• mcp.server.operation.duration;
• mcp.method.name;
• mcp.session.id;
• mcp.protocol.version;
• error.type;
• итоговый путь отката и бизнес-результат.

Сигналы такого типа уже разведены в метриках OpenTelemetry для GenAI и семантических соглашениях OpenTelemetry для MCP, но оба набора продолжают развиваться, а текущие элементы по-прежнему помечены как Development. Версию семантических соглашений нужно фиксировать в явном виде и менять осознанно.

Если этих полей нет, разбор инцидента превращается в догадки, а регрессии ранжирования начинают ошибочно списываться на модель.

Поверхности управления и поля телеметрии, которые делают второй контур управляемым.

5. Аварийные выключатели, автоматические размыкатели и деградированный режим

Чистый поисковый путь должен переживать отказ инструмента.

Именно здесь разница между мягким и жестким отказом превращается из текста в реальное рабочее поведение.

Как минимум среде выполнения нужны:

• глобальный выключатель режима без инструментов для аварийного отката;
• флаги по отдельным инструментам, чтобы один плохой контур не выключал весь путь запроса;
• автоматические размыкатели для повторяющихся таймаутов и поврежденных ответов;
• прокидывание отмены, чтобы брошенные запросы не продолжали нагружать downstream;
• явные решения о мягком или жестком отказе для каждой роли инструмента;
• политика fallback-on-timeout, которая сохраняет базовую выдачу после повторного ранжирования.

Если система не умеет принудительно переходить в режим без инструментов, коротко замыкать деградировавший контур и сохранять базовый ответ при таймауте, ее рабочая модель еще не завершена.

Какие метрики и релизные гейты нужны агентному поиску

Поисковые системы первыми ломаются в метриках. Проблема в том, что агентный контур добавляет второй слой метрик, который может прятаться внутри первого.

Группа метрик	Примеры	Что показывают	Пример релизного гейта
Отбор кандидатов	Recall@K, nDCG@K, отличие между исходным и интерпретированным запросом	Насколько разбор запроса или переписывание меняют качество свидетельств	Блокировать вывод, если качество отбора падает ниже согласованного порога
Повторное ранжирование	Win rate, изменение релевантности, покрытие признаков	Продолжает ли повторное ранжирование улучшать набор кандидатов после обогащения инструментами	Блокировать вывод, если win rate падает или покрытие признаков становится нестабильным
Инструменты	Доля вызовов, доля лишних вызовов, доля некорректных параметров, доля таймаутов	Остается ли место инструментов ограниченным и надежным	Блокировать вывод, если доля вызовов или таймаутов выходит за бюджет
Задержка	p95, p99, добавка по задержке от инструментов, доля отмен	Ломает ли второй контур основное SLO	Блокировать вывод, если накладка по задержке выходит за лимит
Управляемость	Доля откатов, доля согласований, попытки небезопасных действий	Сохраняет ли система управляемость на реальном трафике	Блокировать вывод, если откаты или небезопасные попытки растут
Экономика	Стоимость успешной сессии, доля стоимости инструментов, рост токенов	Оправдана ли добавленная функциональность эксплуатационной ценой	Блокировать вывод, если экономика сессии ухудшается без выигрыша по качеству

Из этой таблицы следуют три практических правила. Логика здесь та же, что и в статье MLOps для production ML: 7 релизных гейтов для управляемой выкладки: система не выходит в трафик, пока измеримый контракт качества, задержек, наблюдаемости и отката не зафиксирован явно.

1. Нужно логировать и исходный, и интерпретированный запрос. Иначе дрейф отбора кандидатов трудно правильно объяснить.
2. Нужно следить за покрытием признаков после обогащения верхних результатов. Пропавшие признаки инструментов могут тихо увести повторное ранжирование в сторону.
3. Гейтить нужно по ценности на уровне сессии, а не по красоте отдельного запроса. Более агентный путь полезен только тогда, когда он улучшает результат без выхода за бюджет.

Разобранный пример: поиск по маркетплейсу с обогащением верхних результатов

Возьмем запрос вроде:

нужен чемодан для ручной клади на колесах до 200 долларов, подходит для Ryanair и может приехать к пятнице

Рабочий путь здесь должен выглядеть так:

запрос
  -> структурированный разбор
  -> отбор кандидатов
  -> повторное ранжирование
  -> обогащение верхних результатов
  -> ответ
  -> при необходимости действие после согласования

Шаг 1. Структурированный разбор

Модель пока ничего не ищет. Она извлекает типизированные признаки запроса:

• тип товара: чемодан для ручной клади на колесах;
• верхний предел цены: 200 USD;
• ограничение по авиакомпании: размеры ручной клади Ryanair;
• окно доставки: до пятницы.

Этот этап должен возвращать валидированный объект признаков, а не свободный текст про то, что именно хотел пользователь.

Шаг 2. Отбор кандидатов и повторное ранжирование

Контур отбора поднимает кандидатов из каталога. Затем повторное ранжирование упорядочивает их по обычному продуктовому контракту:

• текстовая релевантность;
• совпадение по атрибутам;
• ограничения каталога или маркетплейса;
• персонализация там, где она разрешена;
• бизнес-правила, уже зашитые в стек.

На этом этапе выдача уже должна быть достаточно хорошей, чтобы в деградированном режиме по ней можно было ответить.

Шаг 3. Обогащение верхней части выдачи

Свежие вызовы инструментов получают только верхние позиции:

• текущее наличие;
• актуальное обещание по доставке;
• проверка соответствия ручной клади;
• ограничения продавца, если они важны.

Именно здесь тратится бюджет инструментов. Не на весь каталог. Результат должен вернуться в виде поздних признаков результата или ограниченного свидетельства, привязанного к конкретным кандидатам, а не как проза, которая незаметно переопределит порядок после повторного ранжирования.

Шаг 4. Путь ответа

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

Шаг 5. Путь действия

Если нужно зарезервировать один из вариантов для самовывоза или положить его в защищенный контур корзины, это уже отдельный шаг. Он проходит через согласование или явное подтверждение и не должен возникать как побочный эффект самого ответа. Путь действия несет состояние согласования и контекст идемпотентности, а не автономное выполнение.

Поведение при откате

Если инструмент проверки размеров ручной клади или доставки уходит в таймаут:

• сохраняется базовая выдача после повторного ранжирования;
• пользователю показываются лучшие совпадающие товары;
• живое подтверждение по доставке или правилам ручной клади не отображается;
• таймаут обогащения фиксируется в трассе.

Это лучше, чем удерживать весь запрос до завершения каждого вызова обогащения.

За какими сигналами здесь следить

Для этого конкретного контура я бы смотрел на:

• различие между исходным и интерпретированным запросом с точки зрения качества отбора;
• долю таймаутов на обогащении верхних результатов;
• долю некорректных параметров у инструментов обогащения;
• покрытие признаков повторного ранжирования после обогащения;
• долю откатов при проверке доставки и размеров ручной клади;
• добавку по p95 между путем с обогащением и путем без инструментов;
• рост токенов и стоимость успешной сессии относительно базового пути;
• долю подавленных утверждений, если живые проверки недоступны.

Если эти сигналы двигаются вместе, обычно уже можно понять, началась ли деградация в интерпретации, в отборе кандидатов, на шаге повторного ранжирования или в самих инструментах.

Частый сбой из практики

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

Типовые режимы отказа, которые первыми ломают качество поиска

Режим отказа	Симптом	Почему возникает	Что делать
Спам инструментами	Растут доля вызовов, расход токенов и p95 без выигрыша по релевантности	Инструменты становятся путем по умолчанию вместо пути эскалации	Жестко ограничивать место инструментов, использовать tool_choice, белые списки и бюджеты вызовов на запрос через управляющие примитивы function calling у OpenAI
Взрыв задержек	Растет p99, увеличиваются отмены, давление расползается по downstream	Многошаговые цепочки инструментов умножают хвост задержек и повторные попытки	Прокидывать дедлайны, ограничивать ретраи и опираться на Google SRE: Addressing Cascading Failures и Handling Overload
Дрейф отбора кандидатов	После изменения интерпретации запроса офлайн-метрики отбора начинают вести себя иначе	Переписывание запроса меняет саму задачу, которую решает отбор	Логировать исходный и интерпретированный запрос, оценивать оба варианта и ставить гейты по их расхождению
Искажение повторного ранжирования	Элементы с успешным обогащением поднимаются выше более релевантных элементов с отсутствующими признаками	Частичный отказ инструментов просачивается в решения повторного ранжирования	Держать бюджеты таймаутов, задавать значения по умолчанию для признаков и иметь детерминированный путь отката для повторного ранжирования
Дрейф контракта инструмента	Растет доля некорректных параметров, структурированные ответы перестают совпадать с ожиданиями downstream, падает покрытие признаков	Описание инструмента, схема или форма ответа изменились без replay-тестов и обновления оценок	Версионировать контракты, валидировать выход, фиксировать схемы и прогонять replay-тесты по каждому инструменту до релиза
Дрейф прав доступа	Появляются пропавшие или несогласованные результаты, всплески отказов в согласовании и странные расхождения между средами	Меняются области доступа, ломается проверка token audience, регрессирует путь согласования или неправильно настроена граница доверия MCP	Разводить права на чтение и запись, валидировать token audience, логировать согласования и отказы и запускать auth regression tests по каждому инструменту
Разрастание бюджета рассуждения	p95, расход токенов и стоимость успешной сессии растут без заметного выигрыша по качеству	Шаг планирования или эскалация в инструменты тихо становятся путем по умолчанию	Ограничивать reasoning effort, бюджеты вызовов инструментов и сравнивать путь с обогащением с базовым путем на уровне сессии
Косвенная инъекция через найденный контент	Найденный текст начинает влиять на параметры инструмента или толкает систему к небезопасным действиям	Поисковые корпуса часто содержат недоверенный текст	Считать найденный текст недоверенным и применять меры из NIST Generative AI Profile и OpenAI Agent Safety Guidance

Инструменты должны оставаться путем эскалации, а не счастливым путем по умолчанию.

Дисциплина вывода в рабочий трафик: этапы 0-3

Этап 0. Сохраняется базовый путь без инструментов

Базовый контур отбора кандидатов и повторного ранжирования должен оставаться восстановимым в любой момент.

Правило приемки: команда умеет быстро принудительно включить путь без инструментов и вернуть стабильное поисковое поведение без перестройки системы.

Этап 1. Добавляется одна ограниченная роль инструмента

Стартовать стоит с одного из двух вариантов:

• структурированный разбор до отбора кандидатов;
• обогащение верхней части выдачи после ранжирования.

Правило приемки: система может показать, где именно начинается и заканчивается использование инструмента для этой роли, а режим отказа понятен заранее.

Этап 2. Добавляются оценки по трассам и релизные гейты

Перед более широким выводом нужны блокирующие гейты по:

• качеству отбора кандидатов;
• качеству повторного ранжирования;
• доле вызовов инструментов;
• доле таймаутов инструментов;
• доле откатов;
• накладке по задержке;
• стоимости успешной сессии.

Правило приемки: команда умеет отделять регрессии отбора кандидатов, повторного ранжирования и инструментов друг от друга.

Этап 3. Действия появляются только за контуром согласования

Только после стабилизации пути чтения система может выполнять действия. И даже тогда инструменты с высоким влиянием остаются за согласованием или эквивалентной политикой принуждения.

Правило приемки: у пути действия есть отдельные флаги по инструментам, трассируемость, контур согласования и дисциплина отката, не смешанная с путем ответа.

Этот порядок выглядит менее эффектно, чем полный запуск агента, и именно поэтому переживает рабочую эксплуатацию.

Практический список проверки

Прежде чем называть поисковую систему одновременно рабочей и агентной, я бы хотел видеть истинным весь список ниже.

Короткий список проверки для решения, готова ли поисковая система к ограниченным вызовам инструментов.

• Отбор кандидатов и повторное ранжирование остаются главным источником права на показ результата.
• Вызовы инструментов имеют документированную роль: разбор, обогащение или согласованное действие.
• Результаты инструментов входят в стек как типизированные признаки, ограниченные свидетельства или явное состояние согласования.
• У каждого инструмента есть строгая входная схема, строгая выходная схема, таймаут, владелец и путь ревью.
• Политика отказа зафиксирована явно: мягкий или жесткий отказ в зависимости от роли инструмента.
• Среда выполнения держит жесткие бюджеты на число вызовов инструментов, рост токенов и накладку по задержке.
• Найденный контент считается недоверенным на границе инструмента.
• Опасные инструменты требуют согласования или эквивалентной проверки политики.
• Базовый путь без инструментов восстанавливается мгновенно.
• Трассы связывают запросы, отбор кандидатов, повторное ранжирование, вызовы инструментов, состояние прав и итоговый результат.
• Релизные гейты используют и поисковые метрики, и метрики инструментов.
• Регрессии ранжирования и регрессии инструментов разделяются в разборе инцидентов.

Если выигрыш от инструментов меньше, чем потеря управляемости, система получила сложность вместо полезной возможности.

Финальный тезис

Вызовы инструментов приносят пользу в поиске только тогда, когда остаются подчинены поисковому контракту.

Отбор кандидатов задает пространство свидетельств.
Повторное ранжирование задает продуктовый контракт.
Инструменты могут разбирать, обогащать или выполнять действие, но не должны тихо переопределять поисковый контракт.

Главный вопрос для рабочей системы прост: улучшили ли инструменты покрытие или полезность ответа без потери качества, дисциплины задержек, безопасности и возможности отката.

Если ответ неочевиден, система стала труднее в эксплуатации, а не сильнее по возможностям.

В поиске неконтролируемое использование инструментов это не автономность. Это скрытая политика ранжирования.

Что посмотреть дальше

Если хочется открыть еще несколько материалов без превращения страницы в медиастену, вот самые полезные продолжения.

• Building Blocks for Tomorrow’s AI Agents: доклад Anthropic о практических паттернах построения ограниченных агентных систем.
• Model Context Protocol: how MCP went from blog post to the Linux Foundation: разбор от GitHub про стандартизацию MCP и границы управления экосистемой.
• How to secure your AI Agents: A Technical Deep-dive: технический разбор от Google про безопасность агентных систем, авторизацию и риски вокруг MCP.

Стандарты и источники

• OpenAI Function Calling Guide (получено 21 марта 2026)
• OpenAI Trace Grading Guide (получено 21 марта 2026)
• OpenAI Agents SDK Tracing (получено 21 марта 2026)
• OpenAI Safety in Building Agents (получено 21 марта 2026)
• OpenAI MCP and Connectors Guide (получено 21 марта 2026)
• Anthropic: Writing Tools for Agents (8 октября 2025)
• AWS OpenSearch: Agentic Search (получено 21 марта 2026)
• OpenSearch 3.2: Agentic Search (получено 21 марта 2026; экспериментальная возможность и без рекомендации для рабочих нагрузок в OSS 3.2)
• Azure AI Search: Agentic Retrieval Overview (получено 21 марта 2026)
• Azure AI Search: Create a Knowledge Base (получено 21 марта 2026; preview, без SLA и без рекомендации для рабочих нагрузок)
• Azure AI Search: Set Retrieval Reasoning Effort (получено 21 марта 2026)
• Model Context Protocol Specification 2025-11-25 (получено 21 марта 2026)
• Model Context Protocol Schema Reference 2025-11-25 (получено 21 марта 2026)
• OpenTelemetry GenAI Semantic Conventions (получено 21 марта 2026; текущий статус: Development)
• OpenTelemetry GenAI Metrics (получено 21 марта 2026; текущий статус: Development)
• OpenTelemetry MCP Semantic Conventions (получено 21 марта 2026; текущий статус: Development)
• NIST AI 600-1: Generative AI Profile (26 июля 2024)
• OWASP: Securely Using Third-Party MCP Servers (4 ноября 2025)
• OWASP: Secure MCP Server Development (16 февраля 2026)
• Google SRE: Addressing Cascading Failures (получено 21 марта 2026)
• Google SRE: Handling Overload (получено 21 марта 2026)
• SoK: Agentic RAG (7 марта 2026)
• Is Agentic RAG Worth It? (12 января 2026)