Agent Retrieval Policy

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

Суть

Четыре требования, которые отличают извлечение в агентной системе от поиска в справочной:

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

Второе требование — ключевое: если нельзя сказать, почему конкретная запись оказалась в подсказке, разбор плохого ответа упирается в «модель что-то не то увидела».

Фильтры сверх похожести

Рабочий конвейер учитывает не только векторную близость, но и: изоляцию арендаторов, класс памяти, свежесть, уверенность, происхождение, фильтры политики (Memory Boundaries).

Порядок здесь имеет значение: фильтры по арендатору и политике применяются до ранжирования по релевантности, а не после. Фильтрация после отбора означает, что в топ уже попали чужие записи и их оттуда убрали — то есть релевантные свои документы вытеснены и не вернулись (Vector Databases).

Плотность сигнала против полноты

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

Практические ориентиры:

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

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

Плотность и полнота меняются в противофазе, и мерить надо обе

Правило «лучше три релевантные, чем двадцать похожих» одностороннее: оно давит прямо на метрики полноты, которые база требует держать — Context Recall ≥ 0,80 и Hit Rate ≥ 0,85 (RAG Metrics). Там же есть парная метрика с другой стороны — Noise Robustness ≥ 0,90, устойчивость ответа к нерелевантным данным в контексте.

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

Приём, частично снимающий дилемму — Parent Document Retrieval (Chunking): искать по мелким чанкам, а в подсказку отдавать содержащий их крупный фрагмент. Точность отбора остаётся высокой, но в контекст попадает связный кусок, а не обрывок. Это ровно тот случай, когда выбирать между плотностью и полнотой не приходится, потому что они разнесены на разные этапы.

Семантический разрыв между запросом и корпусом

Дефект, почти невидимый на демонстрации: пользователь формулирует запрос разговорно, а документы написаны формально, технически или в терминах внутренних систем. Слабый результат тогда возникает не из-за отсутствия данных, а из-за разрыва языков.

Приёмы, которые его закрывают: нормализация названий сущностей и внутренних статусов, переписывание запроса в «документный» стиль, управляемое расширение запроса, в отдельных случаях генерация гипотетического ответа для поиска по нему (Hybrid Search).

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

Диагностический сигнал: сначала подозревай корпус

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

Причина в асимметрии: подсказка и маршрутизация меняются релизом и потому видны в истории изменений, а корпус меняется сам по себе (Embedding Version Skew).

Извлечение раньше обучения

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

При этом две задачи полезно различать: продолженное предобучение адаптирует распределение знаний, а дообучение на инструкциях — поведение, стиль и шаблон решений (LLM Training Stages).

Связано с

  • Memory Write Policy — правила на другой стороне того же контура
  • RAG — общая механика извлечения и генерации
  • Context Layers — куда попадает извлечённое в подсказке
  • Memory Boundaries — классы памяти как измерение фильтра
  • Hybrid Search — приёмы против семантического разрыва
  • Reranking — ранжирование перед сборкой подсказки
  • Context Compaction — что делать с тем, что не прошло отбор
  • Embedding Version Skew — типичная причина тихой просадки поиска