«Не работает» — это четыре разные проблемы: система отвечает неверно; отвечает верно, но ею не пользуются; работает нестабильно; обходится дороже приносимой пользы. Лечение одной бесполезно при другой, поэтому начинать нужно с диагноза, а не с попыток что-нибудь подкрутить. Чаще всего оказывается, что перед вами второй случай, а чинят при этом первый.
Сначала диагноз
Диагностика занимает немного времени и требует всего двух действий.
Возьмите выборку реальных результатов за последний период — 20–30 случаев подряд, а не отобранных. Оцените каждый: ответ правильный или нет.
Посмотрите, что происходило дальше. Воспользовались результатом, переделали вручную, проигнорировали систему вовсе.
Пересечение этих двух срезов и даёт диагноз. Если ответы неверные — случай первый. Если ответы верные, но люди всё равно делают вручную — случай второй, и он самый частый. Если качество скачет — третий. Если всё хорошо, но счёт превышает выгоду — четвёртый.
Случай 1: система отвечает неверно
Причина почти никогда не в «плохой модели». Проверять стоит в таком порядке.
Ответа нет в данных. Самая частая причина. Система не может сообщить то, чего в корпусе не существует: документ устарел, отсутствует или противоречит другому. Проверяется просто — попробуйте сами найти правильный ответ в материалах. Если не находите вы, не найдёт и система. Решение лежит в области данных, а не технологий, — см. «Готовность данных к внедрению ИИ».
Ответ есть, но фрагмент оторван от контекста. Условие осталось в одном куске, исключение из него — в другом. Система отвечает формально по документу и фактически неверно. Лечится пересмотром нарезки корпуса — «Подготовка базы знаний для ИИ».
Найдено не то. Ответ в корпусе есть, но поиск приносит другие фрагменты. Настраивается на стороне решения.
Система угадывает вместо отказа. Не найдя ответа, она выдаёт правдоподобный вымысел. Это не поломка, а незаданное поведение: правило «при неуверенности передавать человеку» должно быть определено явно — механика описана в статье «Почему нейросеть выдумывает ответы».
Случай 2: отвечает верно, но не пользуются
Самая распространённая и самая недооценённая ситуация. Технически всё исправно, эффекта нет.
Причины лежат вне технологии:
- Проверка занимает столько же, сколько ручная работа. Если сотрудник вынужден перепроверять каждый ответ по первоисточнику, экономии нет. Часто лечится добавлением ссылки на источник в ответ — проверка становится взглядом, а не расследованием.
- Решение живёт отдельно от рабочего места. Отдельное окно, отдельный вход, отдельный пароль. Инструмент, требующий выйти из привычного интерфейса, проигрывает привычке.
- Никто не менял регламент. Старый порядок работы никто не отменял, и люди действуют по нему — они правы.
- Нет доверия после первой ошибки. Одна заметная ошибка в начале эксплуатации перечёркивает статистику: сотрудник запоминает её и перепроверяет всё.
- Непонятно, что делать в спорном случае. Инструкция описывает нормальный сценарий и молчит об исключениях.
- Сотрудники видят в решении угрозу. Мотивации пользоваться нет, а способов не пользоваться много.
Общее у всех причин: чинится не система, а процесс вокруг неё. Ключевая роль здесь у владельца процесса — см. «Кто ведёт ИИ-проект внутри компании».
Случай 3: работает нестабильно
Качество скачет: вчера отвечало верно, сегодня нет. Обычные причины — изменившийся состав обращений (пришёл новый тип запросов, которого не было в проверке), обновление модели на стороне поставщика, разросшийся корпус, куда попали противоречивые документы, или отсутствие контроля после запуска.
Нестабильность почти всегда указывает на отсутствие регулярного контроля качества: проблема существовала и раньше, просто её никто не измерял. Первое действие — не настройка, а введение регулярной проверки выборки, иначе следующее ухудшение снова обнаружится случайно.
Случай 4: работает, но дороже пользы
Решение исправно, люди пользуются, а счёт за эксплуатацию съедает экономию. Это не поломка, а ошибка расчёта, допущенная до разработки: у ИИ-решения переменная стоимость, и она растёт вместе с объёмом.
Хорошая новость в том, что резерв для оптимизации обычно есть: сокращение объёма передаваемого контекста, направление простых запросов на дешёвую модель, кэширование повторяющегося, ограничение длины ответа. Часто расходы удаётся снизить существенно без потери качества. Рычаги подробно разобраны в статье «Сколько стоит эксплуатация ИИ-решения».
Диагностика одной таблицей
| Симптом | Вероятная причина | Что делать |
|---|---|---|
| Ответы неверные по конкретной теме | В корпусе нет или устарело | Обновить документы по этой теме |
| Ответы формально верны, но без исключений | Плохая нарезка фрагментов | Пересмотреть границы фрагментов |
| Система уверенно выдумывает | Не задано поведение при неуверенности | Ввести отказ и передачу человеку |
| Ответы верные, работают вручную | Проверка дороже пользы | Добавить ссылки на источник, встроить в рабочее место |
| Пользуются единицы | Не изменён регламент | Зафиксировать новый порядок работы |
| Качество скачет | Изменился поток или модель | Ввести регулярный контроль выборки |
| Счёт превышает экономию | Не считали эксплуатацию | Оптимизировать контекст и маршрутизацию |
Когда правильное решение — остановиться
Не каждую ситуацию нужно чинить. Остановка оправдана, когда:
- в данных отсутствует то, на чём можно строить ответы, и привести их в порядок сейчас невозможно;
- задача требует того, чего вероятностная система дать не может, — например, юридически значимого решения без проверки;
- стоимость эксплуатации даже после оптимизации превышает пользу;
- процесс изменился настолько, что автоматизировали уже не то, что происходит.
Остановка с сохранением наработок — нормальный исход, а не поражение. Подготовленная база знаний, зафиксированные критерии и понимание процесса остаются активом и пригодятся в следующем проекте. Хуже другое — годами поддерживать решение, которым никто не пользуется, потому что неудобно признать ошибку.
Как не доводить до этого
Все четыре случая предотвращаются на этапах до запуска:
- проверка достижимости на реальных данных — от случая 1;
- пилот с участием тех, кто будет пользоваться, — от случая 2;
- регулярный контроль качества с первого дня — от случая 3;
- расчёт стоимости эксплуатации до разработки — от случая 4.
Порядок работ, в котором эти проверки стоят на своих местах, — в статье «Этапы внедрения ИИ в компании».
Частые вопросы
ИИ отвечает неправильно — нужно менять модель?
Почти никогда. В подавляющем большинстве случаев причина в данных: ответа нет в корпусе, он устарел или противоречит другому документу. Простая проверка — попробуйте сами найти правильный ответ в имеющихся материалах; если не находите вы, не найдёт и модель. Смена модели при проблеме с данными меняет формулировки ошибок, но не их количество.
Решение работает, но сотрудники им не пользуются. Что делать?
Выяснить, что именно мешает, — обычно причина конкретна и не связана с качеством ответов. Чаще всего это дорогая проверка результата, отдельный интерфейс вне рабочего места или неотменённый старый регламент. Первое лечится ссылками на источник в ответе, второе — встраиванием в привычный инструмент, третье — решением владельца процесса.
Как понять, что проект пора закрывать?
Когда исчерпаны две проверки: данные приведены в порядок настолько, насколько возможно, а расходы оптимизированы — и результат всё равно не окупает эксплуатацию либо качество остаётся недостаточным по сути задачи. Затягивание в такой ситуации обходится дороже закрытия. Наработки при этом сохраняются: база знаний и понимание процесса пригодятся в следующем проекте.
Через сколько после запуска можно судить, работает решение или нет?
После выхода на устойчивый режим, когда сотрудники перестали перепроверять всё подряд, а система отработала на реальном потоке достаточно, чтобы накопилась статистика. В первые недели показатели искажены в обе стороны. Судить по первым дням — обычная причина как преждевременного разочарования, так и преждевременного оптимизма.
Кто должен разбираться, почему решение не работает?
Диагноз ставит владелец процесса — именно он видит, пользуются решением или нет, и может оценить правильность ответов с помощью эксперта. Технические причины устраняет подрядчик, но только после того, как определено, какая из четырёх проблем перед вами. Отдавать подрядчику неразобранное «оно не работает» — верный способ получить настройку того, что не сломано.
Что дальше
Как поддерживать качество, чтобы проблемы не накапливались, — «Сопровождение ИИ-решений». Какие ошибки приводят к каждому из четырёх случаев — «12 ошибок при внедрении ИИ». Как измерить, стало ли лучше после исправлений, — «Как измерить эффект от внедрения ИИ». Полная картина — в опорной статье «Внедрение ИИ в бизнес».
Разбор работающего решения и поиск причин — отдельная задача в рамках разработки и внедрения ИИ; диагностику процесса можно начать с аудита.