ADSM: ролевые игры

Я слишком давно в ИТ для того, чтобы наделять программы разумом. Пусть даже и искусственным. Для меня LLM — это прежде всего программа. Текстовый интерфейс к распределённой статистической базе знаний, представленной в несколько необычной форме — хранимая информация размазана в виде весов нейросети. Этот интерфейс превращает входной текст в токены, токены — в эмбеддинги, эмбеддинги многократно преобразуются в более сложные представления, а затем на их основе выбираются выходные токены. Чтобы скрыть детерминированную сущность программы при выборе выходных токенов подмешиваются вероятности.

Кто‑то может сказать, что естественный интеллект работает схожим образом. Не стану возражать. Да, возможно, что и схожим, но точно не таким же. Иначе искусственный интеллект не сильно отличался бы от естественного.

В силу такой своей точки зрения (LLM = программа), я довольно продолжительное время относился к Модели как к инструменту. Но когда я начал пытаться формализовать свой опыт обращения с LLM в виде ADSM, я почувствовал дискомфорт в таком своём отношении к предмету. Всё‑таки инструмент подразумевает достаточно большую управляемость (повторяемость результата) и, самое главное — я не советуюсь с инструментами.

В случае же с Моделями я зачастую «произвожу разведку» — описываю Модели ситуацию и интересуюсь её мнением о предметной области, прежде чем ставить ей задачу. Это несколько выходит за рамки отношений «Пользователь — Инструмент». Поэтому для себя я пришёл к выводу, что мои отношения с Моделями лучше описываются в категориях «Заказчик — Исполнитель».

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

Связь «Заказчик — Исполнитель» гораздо точнее описывает мои рабочие отношения с Моделями, чем «Пользователь — Инструмент». Особенно, когда я в рамках одного диалога раз за разом повторяю Модели одни и те же вещи, которые идут вразрез с её природой, и она упорно пытается игнорировать эти мои пожелания. Совсем как при общении со специалистами‑людьми: «я лучше знаю, что тебе надо».

Но в этом‑то и основная задача Заказчика — донести свою точку зрения до Исполнителя. Тем более, что принимая от Исполнителя работу, Заказчик берёт на себя всю ответственность за дальнейшее использование результата. Сама Модель не имеет субъектности (как и инструмент), но с ней можно советоваться (как со специалистом).

Хоть я и пришёл к этой модели отношений не сразу, но мне она представляется достаточно точной и я собираюсь использовать её в ADSM в качестве базовой. Возможно, кому‑то она тоже покажется полезной. А может, наоборот, вызовет споры — это нормально: опыт взаимодействия с LLM у всех разный. У меня вот такой.

P.S.

Материалы этой публикации в процессе развития были собраны и систематизированы в моей книге "Управляемая разработка с AI-агентами".

@flancer
09.09.2025 23:25 UTC
Первоисточник

Комментарии

@Kamil_GR
09.09.2025 18:29 UTC
+2

Есть вариант промптов, так называемые контракты. Где модель обязуется... И далее по тексту.

@flancer
09.09.2025 18:34 UTC
0

Отлично ложится на отношения "Заказчик - Исполнитель" (Contractor по-английски) (y)

09.09.2025 18:52 UTC
0

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

@Kerman
10.09.2025 08:43 UTC
+1

В любом контракте есть пункт о последствиях (штрафах) за невыполнение обязательств. А вот что сделаешь с моделью, которая не делает, что обещала? Какой же это тогда контракт и что это за обещание такое, которое можно не выполнять и тебе ничего не будет?

10.09.2025 08:44 UTC
-1

Модель редко об этом задумывается

10.09.2025 08:45 UTC
+2

От слова - никогда

@dyadyaSerezha
09.09.2025 19:37 UTC
0

Не очень мне такое название. Почему management? Это разработка. А почему driven? Если агент это исполнитель, то исполнитель не может вести / drive.

Я бы плясал от CASE-систем, computer aided software engineering. Тут всё правильно названо. Теперь поменять на что-то агентское и всё.

@flancer
10.09.2025 04:01 UTC
-1

BASE - Bot Aided Software Engineering? Ну, то же вариант.

@NeriaLab
09.09.2025 19:52 UTC
+4
"Настоящий" BDSM! Только хардкор и никакой ванили
@kompilainenn2
10.09.2025 01:38 UTC
0

База Данных Системной Модуляции

@avetissian
10.09.2025 03:18 UTC
+1

Интересная метафора с «Заказчиком и Исполнителем». 👍
Думаю, она хорошо подчёркивает отличие LLM от привычного инструмента: результат не всегда предсказуем, а взаимодействие требует «договариваться».

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

Кажется, именно из-за этой двойственности вокруг LLM и возникает столько разных моделей взаимодействия.

@flancer
10.09.2025 03:56 UTC
0

Ха, а вот и альтернативщики - "Toolkit to help you get started with Spec-Driven Development"

SDD - тоже неплохо. У меня была попытка называть инструкции для агента "спецификациями". Но чатик меня переубедил - мол, слишком узкий background у этого термина. Спецификации редко пишутся на человеческом языке, они для специалистов, что в теме. А вот инструкции - это как раз для людей со стороны.

В целом наблюдается тенденция к появлению дополнительной категории ЯП: машкоды <= ассемблер <= высокого уровня <= спецификации / инструкции.

@Krios0
10.09.2025 05:40 UTC
+1

Вы плотно подобрались к модели субъект - субъект, практически почувствовали её. Удачи в экспериментах