Модель ответила быстро. Но права ли она?

Модель ответила быстро. Но права ли она? — Изображение AI

Внедрение ИИ-агентов требует постоянной оценки точности их работы. Ошибки в документах, устаревшие данные и неверная классификация заявок могут дорого обходиться бизнесу. Как организовать проверку результатов, определить критерии качества и распределить ответственность за решения ИИ?

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

Сотни страниц и привычка перекрестной проверки

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

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

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

Технически работает, но…

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

В одном из проектов я поставил агента, который разбирает поток входящих заявок в лизинговой компании: он читает заявку, определяет тип имущества, раскладывает по категориям — эту рутину агент берет на себя целиком, а решение по каждой заявке принимает сотрудник. Точность агента здесь растет со временем: чем дольше он работает под контролем человека и дообучается, тем выше результат. В начале работы точность держится на уровне 95–96%, ко второму-третьему месяцу поднимается почти до 99,5%. Человек все это время остается в процессе: наблюдает за решениями агента и модерирует их. Размер контрольной выборки закрыт заказчиком.

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

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

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

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

Проверка держится на регламенте

Из всех этих случаев я вынес одно практическое правило: контроль качества держится на регламенте. Регламент действует, пока система работает вообще; разовая приемка на старте закрывает вопрос только на день запуска. Регламент отвечает на четыре простых вопроса. Первый — что именно замеряем: конкретный показатель для конкретной системы вместо общего ощущения «работает хорошо». Второй вопрос — про выборку: построчная проверка годится для текстов и документов, а контрольная размеченная подборка — для агентов, которые сортируют или классифицируют. Третий — кто смотрит результат: человек, который отвечает за итог перед бизнесом, и эта роль отдельная от того, кто настраивал систему технически. Четвертый — что делать при обновлении модели: тот же выходной результат проходит проверку по тому же SLA, прежде чем новая версия получает доступ к реальным заявкам, документам или текстам.

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

Адаптироваться или уйти

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

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

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