Факапы Элис: закулисье, о котором молчат
О победах рассказывать всегда приятно. Как и об элегантной архитектуре, правильной с точки зрения инженерии. Как всё должно быть, понятно и видно по эталонам: бери эталон, делай как там и показывай победный результат рукоплещущей аудитории.
На практике всё не так радужно. До победы ещё нужно дойти. Где-то эталонная инфраструктура не подходит именно под твой случай. Часто приходится пилить костыли и наращивать техдолг.
Поэтому я собрал серию постов о закулисье разработки Элис AI, о факапах, про которые редко где прочитаешь: как НЕ нужно делать и где были провалы. И самые громкие, феерические провалы случились на самых тривиальных вещах, которые лежат на поверхности.
Картина была такая. Я сижу с ИИ-агентом над Элис: поднимаем стенд, гоняем тесты, учим ассистента ходить в браузер и публиковать посты. План на сессию выглядел скромно — «довести до рабочего состояния». К концу в журнале было шестнадцать инцидентов. Ноутбук, который намертво повис от локальной модели. Письмо, ушедшее на адрес-заглушку. Окна подтверждения, которые сыпались на каждый шаг. Боты, размножившие одну задачу. Бот, который выдавал ошибку 404 из-за трёх пропущенных символов в адресе.
Каждый раз хотелось просто починить и бежать дальше. Но я заставил себя на каждом факапе остановиться и спросить: а почему это вообще стало возможно? Не «что сломалось», а что в устройстве системы позволило этому сломаться. Именно этот вопрос и превращал заплатку в нормальную доработку.
И вот что неожиданно: чаще всего виновата не «глупая нейросеть». Виновата обвязка вокруг неё — правила доступа, подтверждения, блокировки, настройки стенда. Модель делает ровно то, что ей позволяет и подсказывает окружение. Если окружение врёт или мешает, умная модель выглядит глупо.
В серии шесть историй. Пять — про конкретные факапы, шестая — большой разбор о том, как обвязка может задушить даже самую сильную модель. В каждой — что мы хотели сделать, как всё развалилось, как докапывались до причины и какую доработку в итоге сделали. И почему именно такую.
А у вас был факап, после которого пришлось переделывать не баг, а саму схему? Расскажите в комментариях.
· вчера
Полезно ещё отделять инциденты модели от инцидентов оркестрации прямо в журнале: вход, принятое решение, выданные права, внешний эффект и точка подтверждения. Тогда после сбоя видно не только «агент сделал не то», а какой guardrail отсутствовал или сработал слишком поздно.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён