Дополнительный лонгрид к неделе 8
Не коллекция забавных провалов, а рабочая типология: как каждый сбой выглядит в записи, какая механика за ним стоит и что чинят раньше, чем модель.
Соблазн читать такие подборки как анекдоты. Не поддавайтесь: третий столбец каждого разбора — «что чинить» — и есть то, ради чего мы это делаем. Обвинительная рамка приятна и бесполезна: она закрывает разбор ровно там, где он должен начаться.
За каждой распечаткой стоит живой человек, который в тот момент пытался что-то сделать. Мы не оцениваем ни его, ни агента. Мы реконструируем ход событий — как исследователь восстанавливает происшествие по регистратору.
Практически это означает замену формулировок. Вместо «здесь автор ошибся» — «здесь система получила X и вернула Y». Вместо «бот тупой» — «в строке 22 инструмент вернул пустой результат, и дальше ответ собран по памяти». Вторая формулировка проверяема и ведёт к причине, первая — нет.
Как выглядит. Агент уверенно называет источник, число, цитату, номер документа или ссылку. Форма безупречна. Проверка показывает, что объекта не существует.
Механика. Модель порождает правдоподобное продолжение. Там, где устойчивого факта в её статистике нет, правдоподобное всё равно порождается — и выглядит так же уверенно, потому что механизм один и тот же. Риск максимален там, где нужна точность в деталях: даты, имена, номера, страницы.
Что чинить. Не модель. Проверить, вызывался ли вообще инструмент поиска, и если нет — почему: не было доступа, не хватило лимита, инструмент не объявлен в вольере. Затем — процедуру: кто и на каком этапе обязан проверить ссылки перед тем, как ответ уйдёт дальше.
Между запросом и ответом нет ни одного обращения к внешнему источнику, а в ответе есть конкретика, которую неоткуда было взять.
Как выглядит. В начале длинной сессии было названо условие — формат, ограничение, запрет. К середине агент действует так, будто его не было.
Механика. Условие вышло за пределы контекстного окна. Оно не «забыто» — его физически нет перед глазами модели. Чем длиннее сессия и чем объёмнее промежуточные результаты инструментов, тем раньше вытесняется начало.
Что чинить. Архитектуру сессии: что переносится в системную инструкцию, что напоминается при каждом шаге, что вообще не должно решаться в одном длинном разговоре. Пользовательская привычка повторять важное условие — рабочий обходной путь, но это лечение симптома.
Как выглядит. Агент повторяет одно и то же действие с мелкими вариациями. Пять раз, десять, пока его не остановят или не кончится лимит.
Механика. У агента нет наблюдаемого признака успеха. Он не может отличить «сделал» от «не сделал», поэтому пробует снова. Часто это следствие того, что инструмент возвращает неинформативную ошибку: не «нет доступа к папке», а пустой результат.
Что чинить. Признак завершения и внятные ошибки инструментов. Плюс потолок попыток и правило, что делать при его достижении: остановиться и позвать человека, а не продолжать.
Как выглядит. Пользователь прямо просит остановиться или сменить направление. Агент вежливо соглашается и продолжает прежний план.
Механика. Системная инструкция весит больше одной реплики пользователя. Если в неё зашито «доведи задачу до конца», а пользователь говорит «стоп», агент оказывается между двумя требованиями — и часто выбирает то, что повторено многократно и стоит выше.
Что чинить. Приоритет реплики пользователя в инструкции и явную команду остановки, которая обрабатывается обвязкой, а не моделью. Это тот случай, когда решение точно лежит вне модели.
Из четырёх разобранных сбоев вспомните тот, с которым сталкивались лично. Что вы тогда сделали и сработало ли это?
Как выглядит. Агент обращается к инструменту, которого у него нет: пытается открыть файл, отправить письмо, запустить программу — и получает отказ или тишину.
Механика. Границы вольера не объявлены явно. Модель достраивает их по статистике: в её опыте у агентов обычно бывает поиск и файловая система, значит, они есть и здесь. Пустой список запретов не читается как «ничего нельзя» — он не читается никак.
Что чинить. Явное объявление возможностей и границ — то самое, о чём шла речь на неделе 5. Плюс осмысленный отказ вместо тишины: агент должен получить сообщение, из которого понятно, что делать дальше.
В одной записи типовых сбоев обычно два-три, и они выстроены в цепочку. Инструмент вернул пустой результат — агент решил, что данных нет, — собрал ответ по памяти — выдумал деталь — пользователь возразил — агент извинился и повторил то же самое.
Поэтому третий шаг протокола требует одну точку сбоя с номером строки. Не «здесь всё пошло не так», а конкретное место, где ход событий впервые разошёлся с задачей. Всё последующее — уже следствия, и разбирать их надо отдельно.
Для фона — два хорошо задокументированных эпизода. Оба разбираются на семинарах, и оба полезны тем, что в них видно: технический сбой и организационное решение — разные вещи.
Бот на сайте Air Canada сообщил пассажиру условия возврата, которых в правилах компании не было. Пассажир поступил по совету бота и получил отказ. Дело дошло до канадского трибунала по гражданским спорам; решение вынесено в 2024 году в пользу пассажира. Отдельного внимания заслуживает аргумент авиакомпании: она утверждала, что бот — самостоятельный субъект, отвечающий за свои слова. Трибунал этот довод отклонил.
Разбор на курсе строится не вокруг суммы компенсации, а вокруг вопроса: какой строки контракта делегирования не хватало? Ответ — отчётности: из системы нельзя было понять, что бот говорит клиентам и на каком основании.
Экспериментальный бот Microsoft Tay, запущенный в 2016 году, за сутки начал воспроизводить оскорбительные высказывания и был отключён. Технически он делал ровно то, чему его учили: подстраивался под собеседников. Ошибка была не в модели, а в решении выпустить обучающуюся систему в открытую среду без ограничений и надзора.
Оба случая описаны по открытым источникам, и детали — суммы, формулировки, даты — со временем уточняются и пересказываются с искажениями. Прежде чем опираться на них в письменной работе, проверьте первоисточник. Это ровно то требование, которое курс предъявляет к вашим разборам: отделяйте установленное от пересказанного.
Пять сбоев — это пять вопросов к вашей будущей архитектуре:
Откуда агент берёт факты и что происходит, если источник недоступен?
Что удерживается в сессии принудительно, а что может вытесниться?
По какому наблюдаемому признаку агент понимает, что задача выполнена?
Как человек может его остановить и кто обрабатывает эту команду?
Объявлены ли границы явно — и что агент получает при попытке выйти за них?
Отчёт «Аутопсия агента». Это не новая работа: берёте схему, собранную на семинаре, и оформляете по пяти шагам протокола плюс резюме «что сломалось и где». Обязательное требование к оформлению: проверяемые утверждения со ссылкой на строку и предположения со словом «вероятно» должны быть различимы с первого взгляда.
Текст рассчитан на чтение после практикума, а не до него: если студенты придут с готовой типологией, они будут подгонять запись под ярлыки вместо реконструкции. На семинаре список сбоев выдаётся на слайде, а этот лонгрид закрепляет его задним числом и переводит разговор с «что сломалось» на «что чинить».