Личный ИИ может дать правильный ответ и всё равно выполнить задачу неправильно. Я не сразу это понял. Пока Jarvis в основном помогал разбирать информацию, составлять планы и готовить тексты, качество казалось довольно простой вещью: сверил ответ с запросом, поправил неточности — готово.
Но чем больше система стала делать сама, тем чаще правильный ответ переставал быть достаточным доказательством. Текст мог быть хорошим, но собранным не из того источника. Файл мог оказаться на месте, но затронуть чужую работу. Материал мог успешно открываться, но бот после этого присылал человеку пачку служебных сообщений. Формально результат есть. По-человечески задача выполнена плохо.
Когда обычных тестов стало мало
Переломный момент случился, когда я начал собирать для Jarvis отдельный процесс проверки качества. Первой идеей было просто добавить больше независимых проверок: пусть один шаг ищет фактические ошибки, другой смотрит на структуру, третий оценивает риски.
Это помогло, но быстро обнаружилась более важная проблема. Отдельные проверки могли поставить зелёные галочки, а весь путь пользователя всё равно ломался. Например, система корректно готовила материал и правильно понимала команду, но в реальном интерфейсе человек получал лишнее сообщение или не понимал, что нужно сделать дальше. Значит, проверять надо не только продукт работы, но и поведение системы от начала до конца.
Так у меня появилась простая схема:
Источник → Ограничения → Выполнение → Результат → Поведение → Пользовательский путь → Доказательство
В ней нет сложной магии. Это семь обычных вопросов, которые я теперь задаю перед тем, как доверить личному ИИ важное действие.
1. Источник
Первый вопрос: откуда ИИ взял данные и имел ли он право использовать именно их?
Для личного помощника это особенно важно. В его памяти могут соседствовать мои заметки, рабочие документы, семейная информация и материалы разных проектов. Даже без единой фактической ошибки можно получить плохой результат, если система смешала контексты.
Поэтому я проверяю не только правдоподобие ответа, но и происхождение ключевых фактов. Если источник не подтверждён, аккуратная формулировка не делает материал надёжным.
2. Ограничения
Второй вопрос: что системе было разрешено, а что запрещено?
Личный ИИ не должен воспринимать любую понятную цель как разрешение на все действия, которые к ней ведут. Подготовить публикацию — не то же самое, что опубликовать. Найти файл — не то же самое, что перенести его. Проверить настройку — не то же самое, что изменить её.
Чем точнее границы сформулированы до начала работы, тем меньше риск, что помощник «проявит инициативу» там, где от него ждали осторожности.
3. Выполнение
Третий вопрос: что система фактически сделала?
Ответ ИИ — это рассказ о выполнении, а не само выполнение. Фраза «файл загружен» ещё не означает, что он появился в нужной папке. Фраза «страница работает» не заменяет реальную проверку страницы.
Я стараюсь отделять описание от действия: смотреть на созданный файл, состояние сайта, отправленное сообщение или запись в журнале. Это простая привычка, но именно она чаще всего ловит уверенные отчёты о том, чего на самом деле не произошло.
4. Результат
Только теперь я проверяю сам результат: соответствует ли он запросу, полон ли, понятен ли и не искажает ли факты.
Этот слой никуда не исчез. Хороший текст всё ещё должен быть хорошим текстом, а правильная ссылка — вести на нужную страницу. Просто теперь результат не единственный критерий, а один из семи.
Для простых и обратимых задач этого иногда достаточно. Для публикации, изменения данных или действия от моего имени — уже нет.
5. Поведение
Пятый вопрос оказался для меня самым неожиданным: как система вела себя по дороге?
Она может правильно выполнить действие и всё равно испортить опыт лишними сообщениями, внутренними планами, повторными уведомлениями или непонятными формулировками. Для человека это не косметика. Если после команды «Публикуй» бот начинает рассуждать вслух о механизме публикации, доверие к системе падает, даже если страница в итоге появилась.
Поэтому поведение я проверяю отдельно: сколько сообщений отправлено, что именно увидел человек, не раскрылась ли служебная информация и не потребовалось ли ему угадывать следующий шаг.
6. Пользовательский путь
Шестой вопрос: получил ли человек ожидаемый результат там, где он с системой работает?
Можно идеально протестировать отдельные детали и пропустить главный сценарий. Например: материал создан, сайт собран, команда распознана — но ссылка не открывается с телефона. С точки зрения компонентов всё исправно. С точки зрения владельца функция не работает.
Поэтому я воспроизвожу весь путь в реальном интерфейсе: получить материал, открыть закрытую версию, ответить точной командой, увидеть итог и проверить ссылку.
7. Доказательство
Последний вопрос: могу ли я подтвердить, что произошло, и безопасно вернуться назад?
Для важного действия мне нужно знать, какая именно версия была одобрена, что именно появилось на сайте и не изменилось ли содержимое между проверкой и публикацией. Нужен и понятный откат, если результат оказался не тем.
Доказательство не обязано выглядеть как тяжёлый технический отчёт. Для пользователя это может быть точная публичная ссылка и подтверждение версии. Главное, чтобы система не просила верить ей на слово.
Проверки должны соответствовать риску
Из этой истории я вынес ещё один принцип: не каждую задачу нужно прогонять через одинаково тяжёлую процедуру.
Если я прошу исправить опечатку в черновике, достаточно быстрой проверки. Если готовлю публичный материал, нужен редакционный и фактический проход. Если ИИ собирается действовать от моего имени, важны точное разрешение, проверка реального интерфейса и возможность отката.
Смысл не в максимальном количестве тестов. Смысл в том, чтобы глубина проверки соответствовала цене ошибки.
Что можно проверить у своего ИИ
Перед важным действием я предлагаю задать семь коротких вопросов:
- На какие источники он опирался?
- Какие границы действия были заданы заранее?
- Чем подтверждается фактическое выполнение?
- Соответствует ли результат исходной просьбе?
- Что человек увидел и услышал по дороге?
- Прошёл ли весь сценарий в реальном интерфейсе?
- Можно ли подтвердить точную версию и безопасно отменить действие?
Если на часть вопросов нет ответа, это не обязательно означает, что ИИ плохой. Но это честно показывает уровень доверия, который ему пока можно дать.
Итог
Надёжный личный ИИ — не тот, который однажды выдал безупречный ответ. Это система, которая берёт данные из допустимого места, соблюдает границы, действительно выполняет обещанное, спокойно ведёт себя в интерфейсе и оставляет понятное доказательство результата.
Именно поэтому я теперь проверяю не только ответ. Я проверяю весь путь, который привёл к нему. На практике это оказалось гораздо важнее ещё одной красивой зелёной галочки.