Где ломается доверие к ИИ-системе: скрытые условия, источники, метрики и решения

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

Формальная корректность и фактическое право на действие

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

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

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

Поэтому первое правило надёжного ИИ-конвейера — разделять два вопроса: можно ли выполнить действие и как технически выполнить действие. Проверка второго вопроса не заменяет первый.

Что проверять перед каждым значимым действием

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

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

Почему ответ нужно связывать с источником

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

Практический подход показывает PDF Desk: приложение связывает ответ ИИ с конкретной физической страницей исходного PDF. Пользователь получает не только сформулированный результат, но и возможность сразу открыть место документа, на котором этот результат основан.

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

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

Проверяемость важнее уверенного тона

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

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

Как автоматизация искажает собственные метрики

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

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

В описанном случае автоматические production-проверки однажды уже нарушили работу аналитики. Это показательный пример: контрольный механизм сам может изменить наблюдаемую картину и затруднить оценку результата.

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

Контролировать нужно побочные эффекты

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

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

Что меняется с локальными моделями решений

Отдельное направление — использование небольших моделей не для генерации текста, а для выбора действий и скоринга. Strands Decider 2B как раз относится к этому классу. Модель получает состояние и типизированные вопросы, после чего может выбрать один из вариантов, оценить вероятность ответа «да/нет» или вернуть числовой скор с калиброванной уверенностью.

Такой компонент потенциально позволяет отделить простые решения от тяжёлой языковой модели. Заявленное время выбора составляет около 115 мс, модель содержит 1,9 млрд параметров и рассчитана на самостоятельное локальное развёртывание, включая CPU, потребительские видеокарты и компьютеры Mac с Apple Silicon.

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

Дополнительное внимание требуется при развёртывании. В комплектной конфигурации сервер Strands Decider привязывается к 127.0.0.1 и не содержит собственной аутентификации. Если такой сервис когда-либо выводится за пределы локальной среды, защитный слой должен быть организован отдельно.

Почему одной итоговой оценки мало

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

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

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

Как собрать систему контроля

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

1. Условия действия. До вызова функции проверить, разрешено ли действие при текущем состоянии системы.
2. Основание результата. Для документов и извлечённых фактов сохранить возможность перейти к исходному месту, на котором построен ответ.
3. Побочные эффекты. Отделить автоматические и тестовые операции от обычной пользовательской активности в аналитике и связанных процессах.
4. Качество решения. Оценивать не только общий итог, но и отдельные решения, ошибки, значения и случаи отсутствующих данных.

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

Практические шаги внедрения

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

Затем для инструментов с function calling стоит добавить отрицательные тесты. В них параметры функции должны быть формально корректны, но одно из обязательных условий действия намеренно не выполняется. Ожидаемый результат такого теста — отсутствие вызова.

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

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

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

Типичные ошибки

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

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

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

Смотреть только на один общий скор. Итоговая оценка полезна для сравнения, но без детализации она плохо объясняет характер ошибок.

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

Как проверить результат

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

Второй — задать вопрос по документу, где рядом находятся похожие числа или условия. Ответ должен вести к тому месту исходного файла, которое действительно подтверждает формулировку.

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

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

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

Итог

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

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