ADSM: путь от вероятности к детерминизму

Вероятностный вычислитель

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

С этой, сугубо утилитарной точки зрения ^[1] Модель является всего лишь вычислителем (компьютером), который использует некоторую вероятностную матрицу отношений между данными (обучение ^[2]) и преобразовывает при помощи этой матрицы входные данные в какой-то результат.

При таком подходе “интеллект ^[3]” в Моделях отсутствует в принципе. Его место занимает привычная математика ^[4]. “Сознание Модели” превращается в функцию генерации следующего токена на основании предыдущих. Да, из-за вероятностной природы этого вычислителя мы для одних и тех же входных данных при различных вычислениях получаем различные результаты. Но всё равно эти вычисления не выходят за рамки математики – Теории вероятностей.

Для меня LLM – это просто вероятностный компьютер.

Контекст – это программа

В отличие от обычного компьютера, где программа и входные/выходные данные разделены, языковая Модель работает внутри единого смыслового поля – контекста. Она читает его, дополняет новым токеном и тут же использует обновлённое состояние для следующего шага. Контекст становится и кодом, и памятью ^[5], и результатом одновременно. Процесс продолжается, пока не выполнено условие завершения генерации – момент, когда Модель прекращает вычисление, а результирующая последовательность токенов считается выходными данными.

Как и положено компьютеру, Модель без “программы” не подаёт признаков жизни. Чтобы Модель начала что-то делать, ей в контекст нужно подать хоть какие-то входные данные. При этом Модель не пытается “понять” входные данные (например, построить AST ^[6] и оптимизировать вычисления), она сразу начинает работать “по программе” – вычислять токен за токеном (инференс), пока не сработает условие завершения.

Оперативная память Модели

В диалоге Человека и Модели реплики каждой стороны поочерёдно подгружаются в контекст до тех пор, пока в нём имеется свободное место. Общий объём текста диалога может значительно превышать объём контекста и в этом случае в контекст физически может попасть только часть всех данных. Но именно эта часть и является “исполняемой программой” для Модели. Остальное не участвует в вычислениях результирующих токенов (эффект “забывания ^[7]“).

В отличие от классических компьютеров, где программы загружаются в процессор фрагментами и могут быть сколь угодно большими, Модель оперирует сразу всем контекстом – вот что в него поместилось, то и программа, и входные данные. Различные алгоритмы могут обрезать и ужимать контекст при угрозе его переполнения, но суть от этого не изменяется – Модель учитывает в вычислениях только то, что находится в контексте.

Если проводить аналогию с обычным компьютером, то это равносильно тому, что компьютер выполнял бы только ту программу, которая полностью помещается в оперативную память и ни битом больше.

Итерационность вычислений

Довольно часто взаимодействие с Моделями не укладывается в схему “запрос – ответ“, а происходит в рамках какого-то протокола и представляет из себя последовательность запросов и ответов, где ответы предыдущего шага становятся частью запроса шага следующего. Например, в таком ключе ведутся диалоги через веб-интерфейс с такими популярными Моделями, как ChatGPT, Gemini, Grok.

Агенты для генерации кода (Copilot, Codex, Cursor, …), использующие “под капотом” языковые Модели, так же выполняют свою работу итерационно. У разных Агентов могут быть разные протоколы, но база использования Модели идентична во всех вариантах:

• готовится запрос (входные данные == программа)

• запрос обрабатывается Моделью (инференс – выполняется “программа” и генерируются выходные данные)

• фиксируется результат (выходные данные)

• результат анализируется (принимается решение о выполнении следующей итерации или завершении работы)

Итерационность вызвана ограниченностью размеров контекста (“оперативной памяти“). Если бы можно было загружать в контекст весь проект и ещё инструкции для выполнения текущего задания, то можно было бы всё обсчитывать за одну итерацию. Но обычно нельзя.

Проектная база

Когда объём кодовой базы и документации проекта выходят за рамки “оперативной памяти” (размера контекстного окна), тогда вся информация по проекту так или иначе разбивается на файлы/каталоги. Часть этой информации является кодом проекта (python, JS, go, …), часть – документацией проекта.

Нужно помнить, что вся эта (текстовая) информация (и код, и документация) для Модели может являться “программой“. Самое главное, чтобы она была разбита на фрагменты, которые позволяют уложить их в контекстное окно Модели (с учётом резервирования места на генерацию результата).

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

Роль Человека

Роль человека в отношениях с Агентами такая же, как и в отношениях с компьютерами – человек пишет “программы” и запускает их на выполнение. Как пользователь инструмента, человек не может сам задавать матрицу весов (предобученную модель) или протоколы (сценарии поведения ^[8] агента) – это делают производители “инструмента“. Конечный пользователь может лишь выбрать “марку компьютера“.

Но вот что доступно пользователю в полной мере, так это постановка задачи и написание “программ” для такого “вычислителя“. Человек наполняет проектную базу документами (инструкции, спецификации, шаблоны, примеры и т.п.), ставит цель (описывает проект в терминах бизнеса) и запускает “вычислитель” (формулирует задачу для Агента).

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

Разные люди по-разному оформят проектную документацию для приложения “To-Do List” и один и тот же Агент преобразует различные варианты документации в код по-разному.

Сходимость “вычислений”

Понятно, что от навыков “пользователя” зависит то, как будет работать “инструмент“. Если Человек не задаст язык программирования, то Модель может выбирать на своё усмотрение. А что если Человек задаст не только ЯП, но и архитектурные принципы построения приложения и даже названия отдельных функций? В каких рамках Модель сможет быть “свободной для творчества ^[9]“?

Плотность и согласованность контекста уменьшает “свободу выбора” Модели. Сравните запросы:

• Сколько будет два в пятой степени?

• Сколько будет два в пятой степени? Ответ дай одним числом.

• Сколько будет два в пятой степени? Ответ дай одним числом. Только число и ничего более, это важно.

“Свобода выбора” уменьшается от запроса к запросу. При определённой семантической плотности и однородности запроса у Модели остаётся лишь один вариант ответа. И самое примечательное, что разные Модели от разных производителей с разными матрицами весов (с разным обучением) дадут одинаковые ответы на подобные запросы.

Таким образом, “свобода творчества” Агента регулируется плотностью и однородностью проектной базы. – кода и документации. Регулируется Человеком.

Инженерия контекста

Попробуйте представить, можно ли создать такую проектную базу, которая бы “заставляла” большинство Агентов в подавляющем большинстве случаев выдавать идентичный код, например, для расчёта последовательности чисел Фибоначчи?

Мой ответ – да, это возможно. Можно просто привести полностью готовый код и прописать в инструкциях требование строго придерживаться эталонного кода. Я не рассматриваю сейчас варианты “взлома” проектной базы – я исследую границы управляемости своего собственного проекта. Это несколько “топорный” метод управления, но он даёт принципиальное понимание возможностей управления действиями Агента через проектную базу.

Человек является источником смысла проекта и его архитектором. И “программирует” “вероятностный вычислитель” через “проектную базу“. Человек не может напрямую контролировать, что именно и на какой итерации будет загружаться в качестве “программы” в “оперативную память” “вычислителя“, но за счёт создания плотности и определённости смыслов в проектной базе он может ограничить “свободу выбора” Модели и использующего её Агента.

Заключение

Детерминизм в работе языковых Моделей возникает как следствие согласованной структуры взаимодействия между Человеком, Агентом и Контекстом. Ключевое значение здесь имеет проектная база: её плотность, определённость и внутренняя согласованность задают пределы вероятности и направляют вычисление модели к устойчивому результату. Человек формирует смысловую архитектуру проекта, Агент выполняет итерации в рамках заданных связей, Модель вычисляет новые состояния Контекста. Когда проектная база достаточно насыщена и структурирована, случайность ^[10] уменьшает своё влияние – контекст задаёт устойчивую траекторию вычислений.

Так и формируется устойчивость вычислений в вероятностной по своей природе среде .