ИИ-фабрика - это правовое общество, а не инженерная система (1/2)
 
Прочитал статью Стива Йегги "Заборы, а не песочницы" (https://yegge.ai/essays/fences-not-sandboxes/). Для разработки своей игры автор выстроил фабрику из 50+ ИИ-агентов, из которых 20+ Fable. Затем он долго их дрессировал для получения качественного результата, а потом посмотрел "под капот" и обнаружил, что в результате дрессировки его ИИ-фабрика выработала целую правовую систему для организации собственной работы. Не инженерную, а "юридическую".
 
Практические советы по мотивам (как я понял прочитанное):
 
1. Планируйте не один продукт, а два
 
Первый - то, что вы собираетесь сделать: игру, информационную систему, исследование, методику.
 
Второй - фабрика, которая будет это производить: роли, правила, процессы согласования, журналы решений, проверки, мониторинг, откат, управление знаниями.
 
Обычно второй продукт возникает стихийно - в чатах, головах старожилов и фразах "мы всегда делаем так". При появлении десятков ИИ-агентов такая система либо становится явной, либо проект начинает очень быстро производить хаос.
 
2. Не путайте компетентность с полномочиями
 
Агент может быть гениальным программистом и одновременно принять идиотское решение о выпуске новой версии. Потому что умение выполнить действие не означает понимание всех его последствий.
 
Поэтому отдельно определяйте:
 
- кто может предложить изменение;
- кто может его утвердить;
- кто может выполнить;
- кто проверяет результат;
- кто имеет право общаться с внешним миром;
- кто может разрешить исключение.
 
Особенно важно последнее. ИИ должен не только знать, как что-то сделать, но и понимать, имеет ли он право делать это сейчас.
 
3. Ставьте заборы там, где начинаются последствия
 
"Забор" в статье - это не тюрьма для ИИ и не попытка сделать действие технически невозможным. Это механизм, который говорит: "Ты не можешь сделать это, пока не выполнены условия".
 
Например:
 
- нельзя выпускать релиз без тестов и плана отката;
- нельзя писать клиенту вне специально назначенной роли;
- нельзя менять архитектурный контракт без анализа зависимостей;
- нельзя удалять данные без резервной копии;
- нельзя принимать финансовое обязательство без лимита и согласования.
 
Не надо контролировать каждое движение агента. Контролируйте границы, после пересечения которых ошибка становится дорогой.
 
4. Не пишите конституцию заранее
 
Большую часть правил невозможно придумать в переговорной комнате до начала работы. Они обнаруживаются в инцидентах.
 
Хороший цикл выглядит так:
 
ошибка - разбор - контекстное решение - повторение ситуации - устойчивое правило - автоматическая проверка.
 
У Йегги правило постепенно проходит стадии: обычай, рекомендация, предупреждение, закон, механическое ограничение.
 
Это разумнее, чем после каждой ошибки немедленно запрещать всё, что на неё похоже. Иначе ИИ-фабрика очень быстро превратится в министерство запретов.
 
5. Храните не только решение, но и причину
 
Фраза "решили делать так" почти бесполезна через три месяца. Нужно сохранять:
 
- какую проблему решали;
- какие варианты рассматривали;
- почему выбрали этот;
- в каких условиях решение действует;
- когда его нужно пересмотреть;
- какое новое решение его заменило.
 
Для сменяемых ИИ-агентов это критично. Агент не обязан помнить инцидент, но должен уметь восстановить прецедент и понять область его применимости.
 
Роли переживают исполнителей. Прецеденты переживают инциденты.
 
6. Наблюдаемость должна появляться раньше автономности
 
Нельзя сначала разрешить агентам всё, а потом начинать думать, как понять, что они натворили.
 
До передачи автономии должны существовать:
 
- журнал действий;
- идентификация агента и его роли;
- версия использованных правил и данных;
- критерии успешного выполнения;
- предупреждения об отклонениях;
- механизм остановки;
- возможность отката;
- понятный путь эскалации человеку.
 
Автономность без наблюдаемости - это просто ускоренное производство неизвестных проблем.