Interpretable Context Methodology (Методология интерпретируемого контекста): структура директорий как архитектура агента

[VVolk83]

Если честно, не совсем понимаю практическую ценность городить целый оркестр агентов для большинства повседневных задач. Сейчас один нормально составленный промпт к сильной модели спокойно закрывает 90% вопросов с отличной точностью.Понятно, когда сложная оркестрация и изоляция нужны в специфических сферах — у безопасников, хакеров или на огромных предприятиях, где крутятся сотни промышленных ИИ под разные процессы. Но для обычной автоматизации не проще ли обойтись одним-двумя запросами? В каких реальных кейсах, кроме совсем уж масштабных систем, этот оверхед с кучей папок и слоев себя вообще окупает?

[artem_dobrovinskiy]

В любой пайплайн, где требуется проверка человеком результатов работы на нескольких шагах (генерация кода, производство видео, перевод) ICM влетает с двух ног.

[VVolk83]

Вопрос окупаемости оверхеда остается открытым: не проще ли сразу адресовать сильной модели точечный, жестко отфильтрованный промпт, чем строить иллюзию автоматизации, где человек все равно вручную перепроверяет каждый шаг?

[DeadAtreides]

Тут вопрос не в автоматизации, а в том, кто решает структуру работы. Я как-то дал модели самой решать, как разбить задачу на части, - справлялась в 22% случаев. Когда разбивку делал скрипт по заранее заданной схеме, а модели только заполняли свои куски, самая слабая из них выросла с 0,175 до 0,700.

Папки в ICM - по сути та же схема, только руками. Для сильной модели с одним промптом выигрыш будет меньше, но сам принцип мне кажется верным.

[VVolk83]

я могу предположить, что в масштабных многоуровневых базах оркестр агентов еще пригодится. И им нужен грамотный человек-дирежер, который знает где что лежит и куда направить вектора работы агентов, как и на что настроить сеть оповещений и за чем следить. Но не переписывать каждый этаж вручную и строить блок в блоке и над ними контролирующий блок, а еще блок, который проверяет, что первый блок соответствует контролирующий, и не дай бог что там что-то нужно изменить, чтобы работал контролирующий.

[VALLS]

Поразительно: мы с моим ИИ-агентом за несколько месяцев пет-проекта стихийно пришли почти к этому же набору, только называли по-домашнему: пронумерованный журнал решений (память вне контекста), «дежурный файл» со снапшотом состояния для переезда между чатами, карта «какое знание в каком файле живёт». Принцип «текст как интерфейс» подтверждаю с неожиданной стороны: я вообще не программист, код агента читать не могу — а markdown-артефакты читаю и правлю свободно, на этом вся система и держится.

Вопрос из больного опыта: как ICM борется с протуханием слоёв? У нас главной бедой оказались устаревшие статусы в контекстных файлах — агент уверенно читает вчерашнюю правду. Пришлось вводить ритуал «при каждом обновлении перечитывать шапки на свежесть». Есть ли в методологии штатный механизм ревизии контекста?

[artem_dobrovinskiy]

ICM на практике можно посмотреть здесь. Сравните со своим подходом.