Я слишком давно в ИТ для того, чтобы наделять программы разумом. Пусть даже и искусственным. Для меня LLM — это прежде всего программа. Текстовый интерфейс к распределённой статистической базе знаний, представленной в несколько необычной форме — хранимая информация размазана в виде весов нейросети. Этот интерфейс превращает входной текст в токены, токены — в эмбеддинги, эмбеддинги многократно преобразуются в более сложные представления, а затем на их основе выбираются выходные токены. Чтобы скрыть детерминированную сущность программы при выборе выходных токенов подмешиваются вероятности.
Кто‑то может сказать, что естественный интеллект работает схожим образом. Не стану возражать. Да, возможно, что и схожим, но точно не таким же. Иначе искусственный интеллект не сильно отличался бы от естественного.
В силу такой своей точки зрения (LLM = программа
), я довольно продолжительное время относился к Модели как к инструменту. Но когда я начал пытаться формализовать свой опыт обращения с LLM в виде ADSM, я почувствовал дискомфорт в таком своём отношении к предмету. Всё‑таки инструмент подразумевает достаточно большую управляемость (повторяемость результата) и, самое главное — я не советуюсь с инструментами.
В случае же с Моделями я зачастую «произвожу разведку» — описываю Модели ситуацию и интересуюсь её мнением о предметной области, прежде чем ставить ей задачу. Это несколько выходит за рамки отношений «Пользователь — Инструмент». Поэтому для себя я пришёл к выводу, что мои отношения с Моделями лучше описываются в категориях «Заказчик — Исполнитель».
Исполнитель и в обычных, человеческих отношениях, зачастую бывает более сведущ в какой‑то области, чем Закзачик — это нормальная ситуация. Мы нанимаем специалистов именно по этим причинам — они больше нас знают о проблеме, которая перед нами стоит. Нам не зазорно посоветоваться со знающим человеком, если мы чувствуем нехватку специфических знаний в какой‑то области. Но при этом мы можем настаивать на своём собственном вИдении путей решения проблемы и требовать от специалиста придерживаться именно этого вИдения, даже если сам специалист с этим не согласен.
Связь «Заказчик — Исполнитель» гораздо точнее описывает мои рабочие отношения с Моделями, чем «Пользователь — Инструмент». Особенно, когда я в рамках одного диалога раз за разом повторяю Модели одни и те же вещи, которые идут вразрез с её природой, и она упорно пытается игнорировать эти мои пожелания. Совсем как при общении со специалистами‑людьми: «я лучше знаю, что тебе надо».
Но в этом‑то и основная задача Заказчика — донести свою точку зрения до Исполнителя. Тем более, что принимая от Исполнителя работу, Заказчик берёт на себя всю ответственность за дальнейшее использование результата. Сама Модель не имеет субъектности (как и инструмент), но с ней можно советоваться (как со специалистом).
Хоть я и пришёл к этой модели отношений не сразу, но мне она представляется достаточно точной и я собираюсь использовать её в ADSM в качестве базовой. Возможно, кому‑то она тоже покажется полезной. А может, наоборот, вызовет споры — это нормально: опыт взаимодействия с LLM у всех разный. У меня вот такой.
Комментарии (6)
dyadyaSerezha
09.09.2025 18:29Не очень мне такое название. Почему management? Это разработка. А почему driven? Если агент это исполнитель, то исполнитель не может вести / drive.
Я бы плясал от CASE-систем, computer aided software engineering. Тут всё правильно названо. Теперь поменять на что-то агентское и всё.
Kamil_GR
Есть вариант промптов, так называемые контракты. Где модель обязуется... И далее по тексту.
flancer Автор
Отлично ложится на отношения "Заказчик - Исполнитель" (Contractor по-английски) (y)
Kamil_GR
Хотя то, что вы описываете в статье больше походит на проблему постановки задачи. Я давно заметил, что перед тем как задать какой-то важный вопрос или поставить задачу, полезно провести мини диалог с моделью в этой области. Прогрев модели, фокусировка внимания, накопление контекста...