Архитектура против усугубления галлюцинаций в графах агентов

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

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

Плоскость управления, а не запрос

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

1. Типизированный шинный интерфейс инструментов

Каждый инструмент имеет версионированную схему JSON для входных и выходных данных, хранящуюся в реестре, к которому модель не имеет права вносить изменения. Модель может предложить вызов, но детерминистичный валидатор должен принять или отклонить его *до* того, как произойдет какое-либо действие. Никакого принудительного преобразования типов, никакой «достаточно хорошей» связи между значением из перечисления и тем, что выдала модель. Если вызов недействителен, он возвращается планировщику в виде структурированной ошибки — никогда в виде упреков в формате диалога.

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

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

2. Журнал цитирований с возможностью только добавления данных

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

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

Здесь также важна функция хеширования. Модель может цитировать doc:matter-4421#p3, но при этом ошибочно цитировать то, что на самом деле написано на странице 3. Учетная книга должна хранить точный текст этого фрагмента — или, по крайней мере, указатель на незменяемый объектный хранилище — чтобы проверяющий мог сравнивать именно эти байты, а не то, что модель о них запомнила.

3. Шлюз схемы (не для LLM)

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

• массив claims[], каждый элемент которого содержит поля type, text, ledger_ids[] и значение confidence, которое калибруется позже, а не просто считается моделью «высоким»
• массив open_questions[], который планировщик должен либо решить, либо явно передать на более высокий уровень
• массив action_intents[], в котором указывается конкретный инструмент, а не расплывчатый параграф вроде «нам, вероятно, стоит...»

Этот модуль должен представлять собой обычный код — Pydantic, JSON Schema, политика CEL или Rego, какой угодно. Это не должен быть LLM. Если разместить здесь языковую модель, это просто повторение той же структуры critic-agent на более низком уровне.

4. Проверщик утверждений с иным набором информации

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

Затем проведите проверку на логическое следование: подтверждают ли полученные данные утверждение, противоречат ли им или совсем ничего о них не говорят? Это можно реализовать с помощью небольшой модели NLI, ограниченного декодера, способного копировать данные только из указанного фрагмента, или с помощью человека-рецензента. Нельзя поручать эту задачу той же большой чат-модели, использующей тот же системный промпт, и спрашивать ее, кажется ли утверждение «правильным».

Когда заявка отклоняется, никто тихо не изменяет её формулировку, чтобы она прошла при следующей попытке. Она возвращается как Unsupported{proposition, missing_evidence}, и задача специалиста заключается в поиске дополнительных доказательств, а не в перефразировании проблемы.

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

5. Оценивайте на основе конкретных данных, а не интуиции

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

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

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

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

6. HITL на непрерывной границе

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

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

Описание структуры контракта, а не его реализации

Вот пример того, как должен выглядеть объект, передаваемый между агентами. Логика оркестрации, стек проверки NLI, слой хранения данных и компонент, выдающий разрешения, намеренно не показаны — это аспекты, связанные с конкретной реализацией, и они должны находиться в производственном коде, а не в блог-посте.

{
  "run_id": "run_7f3c",
  "from_agent": "analyst",
  "claims": [
    {
      "id": "c_19",
      "type": "Assertion",
      "text": "Line item 14 exceeds the engagement-letter hourly cap.",
      "propositions": [
        {
          "id": "p_19a",
          "pred": "exceeds_cap",
          "args": {"line_id": "14", "cap_source": "engagement_letter"},
          "ledger_ids": ["led_aa12", "led_bb90"],
          "entailment": null
        }
      ]
    }
  ],
  "open_questions": [],
  "action_intents": [
    {
      "tool": "flag_invoice_line",
      "args": {"invoice_id": "INV-4421", "line_id": "14"},
      "requires_grant": true,
      "depends_on": ["c_19"]
    }
  ]
}

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

Также обратите внимание, что значение поля entailment установлено в null. Агент, сделавший утверждение, не имеет права сам заполнять это поле — только проверяющий может это сделать. Позволять агенту оценивать собственные утверждения — это всё равно что позволять компании проводить собственную аудиторскую проверку и называть её независимым контролем.

Почему решение «просто добавить цитаты» всё равно не работает

Самым распространённым поддельным средством защиты является вывод, который лишь кажется цитированным. Модель добавляет [1] или [2], иногда даже указывая на реальный полученный фрагмент. Затем вы открываете этот фрагмент и обнаруживаете, что он на самом деле не подтверждает сделанное утверждение.

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

Вторым поддельным средством защиты является установка параметра температуры на 0. Это не делает вывод более правдивым — оно лишь делает неверный ответ последовательным. Стабильная галлюцинация всегда пройдёт тесты на снимки состояния. Она не выдержит проверку с использованием должным образом ведомой записной книги.

Какова на самом деле стоимость?

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

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

Первый вопрос, который стоит задать, — это не о том, на какой фреймворк строить решение, а о том, где в этом спектре находится ваш собственный рабочий процесс.

Если это действительно ваша проблема

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

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

Связанные материалы

• Проектирование устойчивых графов ИИ-агентов: повторные попытки, альтернативные решения и GraphRAG — Узнайте, как создавать работающие в условиях сбоев рабочие процессы ИИ-агентов с использованием явных веток обработки ошибок, логики повторных попыток, LangGraph, а также когда GraphRAG превосходит обычный RAG или циклы агентов.
• Что показывает создание агента за 10 минут о реальной архитектуре — Рассматривается, почему инструменты быстрого создания агентов, такие как TrueForge, могут скрывать архитектурные решения, с которыми вынуждены сталкиваться при использовании ручных фреймворков, таких как Deep Agents.