Вероятностный вычислитель
Мои знания об устройстве LLM базируются на общедоступной популярной информации (в том числе и на статьях Хабра) и в какой-то мере подтверждаются практикой общения с ними. Можно смотреть на LLM как на некую разумную сущность, чья природа ортогональна человеческому разуму и поэтому плохо нами понимается, но я предпочитаю смотреть на LLM как на инструмент, созданный людьми для решения собственных, человеческих проблем.
С этой, сугубо утилитарной точки зрения Модель является всего лишь вычислителем (компьютером), который использует некоторую вероятностную матрицу отношений между данными (обучение) и преобразовывает при помощи этой матрицы входные данные в какой-то результат.
При таком подходе «интеллект» в Моделях отсутствует в принципе. Его место занимает привычная математика. «Сознание Модели» превращается в функцию генерации следующего токена на основании предыдущих. Да, из-за вероятностной природы этого вычислителя мы для одних и тех же входных данных при различных вычислениях получаем различные результаты. Но всё равно эти вычисления не выходят за рамки математики — Теории вероятностей.
Для меня LLM — это просто вероятностный компьютер.
Контекст — это программа
В отличие от обычного компьютера, где программа и входные/выходные данные разделены, языковая Модель работает внутри единого смыслового поля — контекста. Она читает его, дополняет новым токеном и тут же использует обновлённое состояние для следующего шага. Контекст становится и кодом, и памятью, и результатом одновременно. Процесс продолжается, пока не выполнено условие завершения генерации — момент, когда Модель прекращает вычисление, а результирующая последовательность токенов считается выходными данными.
Как и положено компьютеру, Модель без «программы» не подаёт признаков жизни. Чтобы Модель начала что-то делать, ей в контекст нужно подать хоть какие-то входные данные. При этом Модель не пытается «понять» входные данные (например, построить AST и оптимизировать вычисления), она сразу начинает работать «по программе» — вычислять токен за токеном (инференс), пока не сработает условие завершения.
Оперативная память Модели
В диалоге Человека и Модели реплики каждой стороны поочерёдно подгружаются в контекст до тех пор, пока в нём имеется свободное место. Общий объём текста диалога может значительно превышать объём контекста и в этом случае в контекст физически может попасть только часть всех данных. Но именно эта часть и является «исполняемой программой» для Модели. Остальное не участвует в вычислениях результирующих токенов (эффект «забывания»).
В отличие от классических компьютеров, где программы загружаются в процессор фрагментами и могут быть сколь угодно большими, Модель оперирует сразу всем контекстом — вот что в него поместилось, то и программа, и входные данные. Различные алгоритмы могут обрезать и ужимать контекст при угрозе его переполнения, но суть от этого не изменяется — Модель учитывает в вычислениях только то, что находится в контексте.
Если проводить аналогию с обычным компьютером, то это равносильно тому, что компьютер выполнял бы только ту программу, которая полностью помещается в оперативную память и ни битом больше.
Итерационность вычислений
Довольно часто взаимодействие с Моделями не укладывается в схему «запрос — ответ», а происходит в рамках какого-то протокола и представляет из себя последовательность запросов и ответов, где ответы предыдущего шага становятся частью запроса шага следующего. Например, в таком ключе ведутся диалоги через веб-интерфейс с такими популярными Моделями, как ChatGPT, Gemini, Grok.
Агенты для генерации кода (Copilot, Codex, Cursor, …), использующие «под капотом» языковые Модели, так же выполняют свою работу итерационно. У разных Агентов могут быть разные протоколы, но база использования Модели идентична во всех вариантах:
готовится запрос (входные данные == программа)
запрос обрабатывается Моделью (инференс — выполняется «программа» и генерируются выходные данные)
фиксируется результат (выходные данные)
результат анализируется (принимается решение о выполнении следующей итерации или завершении работы)
Итерационность вызвана ограниченностью размеров контекста («оперативной памяти»). Если бы можно было загружать в контекст весь проект и ещё инструкции для выполнения текущего задания, то можно было бы всё обсчитывать за одну итерацию. Но обычно нельзя.
Проектная база
Когда объём кодовой базы и документации проекта выходят за рамки «оперативной памяти» (размера контекстного окна), тогда вся информация по проекту так или иначе разбивается на файлы/каталоги. Часть этой информации является кодом проекта (python, JS, go, …), часть — документацией проекта.
Нужно помнить, что вся эта (текстовая) информация (и код, и документация) для Модели может являться «программой». Самое главное, чтобы она была разбита на фрагменты, которые позволяют уложить их в контекстное окно Модели (с учётом резервирования места на генерацию результата).
Весь объём таких файлов я называю проектной базой — это та информация, к которой имеет доступ Агент (например, Codex) во время выполнения задания. Я исхожу из предпосылки, что Агенту на момент выполнения задания запрещён выход в Сеть. Всё, что у него есть для работы — это проектная база и вероятностная матрица отношений, полученная при обучении.
Роль Человека
Роль человека в отношениях с Агентами такая же, как и в отношениях с компьютерами — человек пишет «программы» и запускает их на выполнение. Как пользователь инструмента, человек не может сам задавать матрицу весов (предобученную модель) или протоколы (сценарии поведения агента) — это делают производители «инструмента». Конечный пользователь может лишь выбрать «марку компьютера».
Но вот что доступно пользователю в полной мере, так это постановка задачи и написание «программ» для такого «вычислителя». Человек наполняет проектную базу документами (инструкции, спецификации, шаблоны, примеры и т.п.), ставит цель (описывает проект в терминах бизнеса) и запускает «вычислитель» (формулирует задачу для Агента).
Именно Человек принимает основные проектные решения и фиксирует их в проектной базе. Агенту всё равно, на каком языке программирования реализовать бизнес-логику и какую архитектуру заложить в результирующий программный код. Все ограничения и направления прописывает человек в проектной базе.
Разные люди по-разному оформят проектную документацию для приложения «To-Do List» и один и тот же Агент преобразует различные варианты документации в код по-разному.
Сходимость «вычислений»
Понятно, что от навыков «пользователя» зависит то, как будет работать «инструмент». Если Человек не задаст язык программирования, то Модель может выбирать на своё усмотрение. А что если Человек задаст не только ЯП, но и архитектурные принципы построения приложения и даже названия отдельных функций? В каких рамках Модель сможет быть «свободной для творчества»?
Плотность и согласованность контекста уменьшает «свободу выбора» Модели. Сравните запросы:
Сколько будет два в пятой степени?
Сколько будет два в пятой степени? Ответ дай одним числом.
Сколько будет два в пятой степени? Ответ дай одним числом. Только число и ничего более, это важно.
«Свобода выбора» уменьшается от запроса к запросу. При определённой семантической плотности и однородности запроса у Модели остаётся лишь один вариант ответа. И самое примечательное, что разные Модели от разных производителей с разными матрицами весов (с разным обучением) дадут одинаковые ответы на подобные запросы.
Таким образом, «свобода творчества» Агента регулируется плотностью и однородностью проектной базы. — кода и документации. Регулируется Человеком.
Инженерия контекста
Попробуйте представить, можно ли создать такую проектную базу, которая бы «заставляла» большинство Агентов в подавляющем большинстве случаев выдавать идентичный код, например, для расчёта последовательности чисел Фибоначчи?
Мой ответ — да, это возможно. Можно просто привести полностью готовый код и прописать в инструкциях требование строго придерживаться эталонного кода. Я не рассматриваю сейчас варианты «взлома» проектной базы — я исследую границы управляемости своего собственного проекта. Это несколько «топорный» метод управления, но он даёт принципиальное понимание возможностей управления действиями Агента через проектную базу.
Человек является источником смысла проекта и его архитектором. И «программирует» «вероятностный вычислитель» через «проектную базу». Человек не может напрямую контролировать, что именно и на какой итерации будет загружаться в качестве «программы» в «оперативную память» «вычислителя», но за счёт создания плотности и определённости смыслов в проектной базе он может ограничить «свободу выбора» Модели и использующего её Агента.
Заключение
Детерминизм в работе языковых Моделей возникает как следствие согласованной структуры взаимодействия между Человеком, Агентом и Контекстом. Ключевое значение здесь имеет проектная база: её плотность, определённость и внутренняя согласованность задают пределы вероятности и направляют вычисление модели к устойчивому результату. Человек формирует смысловую архитектуру проекта, Агент выполняет итерации в рамках заданных связей, Модель вычисляет новые состояния Контекста. Когда проектная база достаточно насыщена и структурирована, случайность уменьшает своё влияние — контекст задаёт устойчивую траекторию вычислений.
Так и формируется устойчивость вычислений в вероятностной по своей природе среде .
Источник: habr.com
