Практика
Распространённое описание работы с LLM-агентами таково: одни люди «просто прощупывают модель», а другие принимают первый ответ. Такая формулировка трактует допрос как склад характера. Это не так. Допрос — это метод ревью: определённый набор вопросов, задаваемых выводу, прежде чем этот вывод может считаться результатом. Различие важно, потому что методы можно записать, назначить, выборочно проверять, аудировать и улучшать. Склады характера — нельзя.
Метод прост. Вместо того чтобы прочитать сгенерированный ответ и судить, звучит ли он правильно, ревьюер запрашивает у агента доказательства, лежащие в основе ответа, рассмотренные альтернативы, основание для заявленной уверенности и то, что могло бы её опровергнуть. Это не риторические вопросы. У каждого есть правильная форма ответа, и агент, не способный выдать эту форму, обнаружил пробел в своём пайплайне, а не в своей прозе.
Это тот же ход, который делает хорошее код-ревью. Пул-реквест не сливается потому, что дифф выглядит правдоподобно; он сливается потому, что автор может объяснить, почему это изменение, а не другое, от чего оно зависит и как будет протестировано. Вывод агента заслуживает такого же обращения, и недавние материалы о командах, допрашивающих вывод модели, а не доверяющих первым ответам, — это описание распространения такой дисциплины, а не появления нового типа личности.
Что на самом деле спрашивает допрос
Полезный допрос содержит четыре вопроса, и они обобщаются на разные классы задач:
- Доказательства: на каких источниках, результатах инструментов или данных основывался этот ответ?
- Альтернативы: какие другие ветви рассматривались и почему были отвергнуты?
- Основание уверенности: что конкретно делает этот ответ более или менее определённым — охват источников, согласие между инструментами, неоднозначность запроса?
- Опровержение: какое наблюдение сделало бы этот ответ неверным, и доступно ли это наблюдение?
Четвёртый вопрос — тот, что отделяет ревью от успокоения. Ответ, который не может быть опровергнут никаким доступным наблюдением, — не утверждение; это заявление о намерении. Ревьюеры должны относиться к нему соответственно.
Метод работает только если агент может выдать промежуточные артефакты. Если retrieval, использование инструментов и выбор ветвей происходят внутри чёрного ящика и выдаётся только финальный текст, допросу не за что зацепиться. Ревьюер вынужден просить модель заняться самоанализом, что порождает правдоподобное повествование, а не доказательства. Инженерное требование, таким образом, находится выше по потоку от ревью: запуск должен быть инструментирован так, чтобы артефакты существовали и могли быть показаны.
Что нужно фиксировать, чтобы это стало возможным
Три категории записей делают допрос возможным. Ни одна из них не опциональна, если метод должен быть чем-то большим, чем театр.
Происхождение retrieval. Для каждого извлечённого фрагмента: идентификатор документа, версия или хеш документа, смещения спанов, запрос, который его выявил, и ранг, на котором он пришёл. Версия важна, потому что документ может измениться между запуском и ревью, и ревьюер, сравнивающий ответ с текущим текстом, может сравнивать его не с тем текстом. Смещения спанов важны, потому что ссылка на целый документ — не доказательство; ссылка на абзац — да.
Записи вызовов инструментов. Для каждого вызова инструмента: имя инструмента, точный вход, точный выход, временная метка и состояние ошибки, если она была. Флаг успеха — не запись. Ревьюерам нужно видеть, что было запрошено у инструмента и что он вернул, потому что значительная доля отказов агента — это отказы конструирования входа: инструмент был вызван правильно, но у него спросили не то.
Отвергнутые ветви и их причины. Когда агент исследует план и отбрасывает его, отброшенный план и причина отбрасывания должны сохраняться. Именно это позволяет ревьюеру увидеть пространство поиска, а не только выживший путь. Без этого ревьюер не может сказать, рассмотрел ли агент очевидную альтернативу и отверг её на основании доказательств или вообще не рассматривал. Эти две ситуации выглядят одинаково в финальном выводе и совершенно различны по своим последствиям.
Конкретный механизм: выдавать структурированную запись запуска вместе с выводом, с одним разделом на каждую категорию выше, и заставить интерфейс ревью отображать эту запись рядом с ответом. Задача ревьюера становится чтением двух артефактов вместе, а не угадыванием по одному.
Превращение в шлюз ревью
Метод становится институци
ента.
Во-первых, определите небольшой набор вопросов допроса для каждого класса задач. Задача вопросно-ответного типа с интенсивным retrieval нуждается в вопросах о происхождении и версии. Задача планирования нуждается в вопросах об альтернативах и опровержении. Задача с интенсивным использованием инструментов нуждается в вопросах о конструировании входа и обработке ошибок. Держите набор небольшим — три-пять на класс, — чтобы ответы на них были рутинным шагом, а не проектом.
Во-вторых, требуйте ответов до того, как запуск будет помечен завершённым. Это переход состояния, а не предложение. Запуск, который не может ответить на вопросы своего класса, не завершён; он в ожидании и эскалируется. Эскалация — это сигнал: агент, не способный ответить на вопрос, на который должен быть способен, сообщил вам нечто конкретное о своём retrieval или инструментарии.
В-третьих, выбирайте запуски для человеческого допроса с фиксированной частотой. Автоматические шлюзы ловят структурные отказы; люди ловят семантические. Фиксированная частота выборки — каждый запуск в классе с высокими последствиями, доля в более низких — делает нагрузку на человеческое ревью предсказуемой, а охват честным.
Самый ценный результат этого шлюза — не отдельный вердикт. Это повторяющийся вопрос без ответа. Когда один и тот же вопрос проваливается во многих запусках, исправление принадлежит retrieval или инструментарию, а не патчу промпта. Патч промпта, который заставляет агента рассказывать ответ, которого у него нет, хуже отказа, потому что он устраняет сигнал.
Ограничения и компромиссы
Самооценка уверенности не является доказательством. Когда агент говорит, что уверен, это сгенерированная последовательность токенов, а не измерение. Метод зависит от внешних артефактов — извлечённых спанов, выходов инструментов, записей ветвей — и там, где их нет, допрос вырождается в просьбу к модели охарактеризовать себя. Эту характеристику следует логировать как утверждение, а не трактовать как находку.
Допрос также добавляет задержку и стоимость. Создание структурированных записей запуска, сохранение отвергнутых ветвей и ответы на вопросы шлюза потребляют вычисления и хранилище, а человеческая выборка потребляет время ревьюеров. Вот почему метод в первую очередь принадлежит путям с высокими последствиями: решениям, которые дорого отменить, выводам, достигающим клиентов, или действиям, затрагивающим продакшн-системы. Пути с более низкими последствиями могут работать с более лёгкой инструментацией, пока практика не устоялась и инструментарий не стал достаточно дешёвым для расширения.
Честное резюме таково: допрос — это дисциплина ревью с реальной стоимостью и реальной отдачей. Она меняет то, что логируется, потому что шлюз не может функционировать без записей о происхождении и инструментах. Она меняет то, что ревьюируется, потому что ревьюеры читают записи запуска, а не только финальный текст. И она меняет то, что выпускается, потому что запуск, не способный ответить на вопросы своего класса, не проходит. Команды, которые её принимают, не становятся более скептичными по темпераменту. Они просто перенесли скептицизм в пайплайн, где его можно измерять и поддерживать.
Что это значит для процесса ревью
Формулировку, которую пора отправить в отставку: одни инженеры допрашивают модели, а другие нет. Формулировка, которую стоит принять: допрос — это шлюз с определёнными вопросами, определёнными артефактами и определённой эскалацией. Этот шлюз — разница между практикой оценки и мнением. Это также единственная версия практики, которая выживает при смене персонала, смене модели или смене класса задач — то есть единственная версия, которую стоит строить.