re!think it: Как я уместил корпоративный бэкенд в один промпт (История сборки)

Введение

Всё началось с утреннего обсуждения того, как языковые модели вообще воспринимают вводный запрос. Насколько на самом деле важно качество описания промпта? Есть ли разница между большим объемом «популярных» слов (водой) и лаконичным запросом, состоящим из малого количества, но редких и “тяжелых” по смыслу терминов?

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

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

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

Мы пошли рассуждать. Как модель в целом решает задачу? Как она выполняет сложные рассуждения? Есть ли у неё какие-то внутренние механики, которые диктуют ей, как именно рассуждать, кроме банального «рассуждай последовательно и понятно»?

Задачи на точность и корректность (re!think it protocol | PROT_A)

Отталкиваясь от этого, мы стали обсуждать процесс формирования ответа. И так как для моделей общение на языке “векторов” – это не только норма, а еще и их какое-то внутреннее “интуитивное” желание, то мы в этих терминах и вели диалог. В этой логике финальный результат — это, по сути, сложение вектора контекста с вектором инструментов. Получив этот вектор результата, мы сравниваем его с изначальным вектором цели и проверяем: тот ли результат мы получили или нет?

И вот на языке векторной геометрии эти два шага выглядят следующим образом:

1. Этап рассуждения (Синтез): (Вектор Результата получается из сложения вектора Контекста и вектора Инструментов , пропущенных через призму вектора Роли , который задает нужный угол анализа).

2. Этап верификации (Проверка): (Полученный Результат сравнивается с вектором Цели $G$ на предмет полного соответствия, проходя через жесткий фильтр вектора ограничений ).

Так родились первые формулы, которые заменили гуманитарные инструкции (в духе «подумай шаг за шагом») на строгую алгебру.

Предвижу скепсис ML-инженеров: «LLM не умеет считать векторы по команде из промпта, она просто угадывает токены!». Безусловно, я понимаю, что не получаю прямого доступа к её векторному калькулятору. Но здесь работает тот же принцип, по которому человек интуитивно складывает «2+2». У нас в голове тоже нет отдельного процессора для чистых математических вычислений — мы делаем это эмулируя процесс на уровне нейронных слоев и преобразования смыслов. Тут так же, когда мы задаем жесткую формулу , модель эмулирует ту же векторную геометрию. Итоговый эмбеддинг (токен результата ) по сути оказывается равен сумме вводных векторов Контекста и Инструментов с наложением фильтра Роли. Как именно модель проворачивает это под капотом — меня, как архитектора, не сильно интересует. Главное, что это работает: формула позволяет донести логику с минимальным количеством шума, и модель отлично это считывает и выполняет.

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

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

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

Базовые переменные задачи:

• (Goal) — конечная цель или намерение пользователя. Что именно нужно получить на выходе?

• (Context) — весь предоставленный пользователем контекст, исходные данные и ограничения самой задачи.

• (Tools) — инструменты, фреймворки или методики, которые требуются для решения.

Скрытые переменные профиля:

• (Компетенция) — уровень экспертизы субъекта.

• (Доверие) — принятые/отвергнутые методы.

• (Mission constraints) — жёсткие этические и бизнес-ограничения, глобальные цели пользователя.

• (Формат) — требуемая плотность и формат ответа.

Важное примечание: я не настаиваю на том, что хранение профиля пользователя в оперативной памяти механизма Attention — это единственно верный путь. Для энтерпрайз-решений это идеальное место для интеграции с внешней векторной базой знаний (RAG). Любой разработчик может подменить этап “вычисления параметров в уме” на получение этих параметров извне. Рассматривайте этот подход скорее как идею, в каком разрезе следует накапливать данные о пользователе и о разумности связки этих разрезов с формулами размышления.

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

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

Подход я взял опять-таки исключительно математический. Если есть переменная цели и есть переменные вводных данных, почему бы не написать формулу дельты? Так мы получили математическое описание того, как проверить дефицит информации:

После расчета дельты (), нет никакой проблемы спроецировать её на три плоскости (плоскость Цели, плоскость Контекста и плоскость Инструментов) и мгновенно понять, в какой из них у нас идет нехватка и дефицит токенов от пользователя.

Это привело к внедрению очень гибкой механики — HARD STOP. Для каждого типа задач это условие, по которому модель может принять решение: «Я не хочу генерировать неправильный ответ. Я пойду и уточню». Это прямое формульное разрешение заблокировать генерацию до начала синтеза ответа и задать уточняющий вопрос.

Отсылка к индустрии: Крупные компании решают проблему галлюцинаций через пост-генерационную валидацию или через второй проход модели-критика ��ледом. Наш HARD STOP — это барьер, который модель может “посчитать” до начала выдачи неверного ответа. Мы запрещаем модели строить плохой черновик в принципе или заставляем ее написать явно использованное “допущение”.

Но прелесть формулы еще и в том, что она дает гибкость. Высчитав дельту, мы понимаем не просто факт нехватки, мы знаем а где именно она произошла (в контексте / инструментах / цели). Имея три разных дельты, мы можем управлять «свободой» модели по каждой из них:

• Дефицит Инструментов (): Если инструменты не указаны, модель вполне может додумать их сама (подобрать подходящий фреймворк или метод).

• Дефицит Контекста (): Модель имеет право добавлять только фундаментальный, гарантированно подтвержденный контекст, либо брать информацию из профиля пользователя. В противном случае ей следует остановиться и спросить.

• Дефицит Цели (): Здесь жесткий запрет. Особенно если речь идет о задачах на дедуктивное рассуждение. Если цель не ясна, модель не имеет права её дофантазировать. Она обязана остановиться и переспросить.

И самое главное: объяснить это модели на языке формул и переменных оказалось в десятки раз проще и надежнее, чем пытаться написать это обычным русским языком. Когда вы пытаетесь описать такие сложные условные зависимости текстом, промпт превращается в запутанный юридический протокол. Модель неизбежно в нем путается, начинает искать лазейки, обходить правила или галлюцинировать. Математика же не оставляет пространства для интерпретаций.

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

Задачи на генерацию вариантов и расширение (re!think it protocol | PROT_B)

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

Эти генеративные задачи относятся к категории, где контекста и цели толком и нет. Есть лишь какая-то отправная точка (она может быть абсолютно любой: не обязательно в инструменте, не обязательно в контексте, она может быть в чем угодно) и есть направление, в котором нужно посмотреть и выдать варианты. Такой универсальной формулой можно «схлопнуть» почти все запросы подобного толка. Эти задачи мы выделили в отдельную ветку — PROT_B.

Если для поиска точного ответа мы использовали сложение контекста и инструментов, то для креативных задач логика и формулы выглядят иначе:

Вводные переменные для генерации (экстракция):

• (Seed/Исходный материал) — стартовые данные или отправная точка идеи.

• (Direction/Направление) — желаемый тип выхода или вектор, куда развивать мысль.

На эти переменные также накладываются жесткие границы вектора ограничений .

Математика принятия решений (расширение):

1. Генерация пространства вариантов: (Модель создает множество возможных решений , отталкиваясь от зерна в направлении . При этом заложено строгое правило: сгенерировать минимум 3 ортогональных (независимых друг от друга) пути и минимум 1 контринтуитивный).

2. Анти-центроидный фильтр: (Из полученного множества принудительно вычитается — самый усредненный, банальный и очевидный ответ, который LLM выдала бы по умолчанию. Для режима генерации типичный ответ ИИ считается ошибкой, мы математически принуждаем модель к нестандартному мышлению).

После этого формируется выборка: либо выводится всё сгенерированное пространство вариантов, либо один наиболее сильный черновик (Draft), если так указано в запросе.

Задачи без необходимости размышлять (re!think it protocol | PROT_С)

Ну и, конечно, нельзя забывать, что далеко не все задачи в целом требуют использования сложной цепочки рассуждений. Есть огромный пласт запросов, требующих просто ответа «здесь и сейчас». Это диалоговые задачи, для которых не нужно ничего дополнительно записывать в технический лог рассуждения, не нужно ничего придумывать. Нужно сделать элементарное действие: трансформацию текста, смену призмы, простой перевод или разъяснение. В общем, это те задачи, которые модель не нужно учить, как делать.

Таким образом у нас появился PROT_C BYPASS — прямой коридор в обход тяжелой аналитики.

Заключение

И вот, когда мы разобрали все три варианта, можно сказать, что на этом этапе я постарался объяснить, каким образом у меня собрался итоговый системный промпт версии 1.0.

Его можно посмотреть в открытом доступе на GitHub. Я сделал его в нескольких вариантах:

• Он есть на русском, английском и китайском языках в полном виде.

• Он есть на тех же языках в сокращенном виде — специально для маленьких моделей.

• И он есть отдельно на языке псевдокода, который оказался наиболее устойчивым к дрейфу внимания и размытию смысла.

В опубликованном промпте, помимо всего прочего, заложено еще несколько механик (например, архивариус), которые я здесь не буду объяснять, чтобы не перегружать статью. Если будут вопросы о том, почему те или иные части промпта составлены именно так, можете задавать их в комментариях или писать в ветки дискуссий на GitHub.

Еще одно интересное наблюдение: Работая с системным промптом вот в таком виде — на языке математики, векторной геометрии и с очень маленьким количеством обычных русских или английских слов, — мы получаем достаточно устойчивый системный каркас.

Его не так-то просто испортить или «размыть» длинным диалогом. А ведь именно это неизбежно происходит в случаях, когда промпт написан исключительно на чистом естественном языке (русском или английском). Гуманитарные инструкции со временем вымываются из внимания, а математические операторы продолжают держать модель в жестких рамках.

Послесловие

А в этой статье я бы хотел поднять два главных вопроса.

1. Может начнем поощрять алгоритмическое мышление вместо «потока сознания»

Первый вопрос: сейчас все вокруг пытаются научить LLM рассуждать, просто показывая им цепочку размышлений (Chain-of-Thought). Разработчики пишут длинные текстовые промпты, рассказывая, как они думают и на что обращают внимание. Однако, когда всё это идет сплошным текстом, мы получаем модели, которые просто пытаются подобным же образом предсказать следующий шаг на основе ранее увиденного огромного количества таких вот рассуждений.

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

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

Немного о планах: В разрабатываемой версии 1.1 своего протокола я уже выделяю больше атомарных типов задач. Для каждой из них я прихожу к более вариативному способу экстракции данных, к более точечному способу контроля результата, и под каждую конкретную задачу уже настраиваю свои различные степени свободы.

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

2. Поощрение халатности или каким я вижу путь гигантов

А второй вопрос звучит так: точно ли ИИ-гиганты идут по самому эффективному пути?

Ведь если мы хотим сделать модели вдумчивыми, нам неизбежно нужно идти в сторону раскладывания процесса мышления на атомарные шаги. Нам нужно определять правила для каждого шага в отдельности: правила переходов, правила проверок, правила принятия решений и тому подобное — причем в той нотации, в которой модели привыкли думать сами.

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

Кроме того, без структурирования цепочки размышлений изнутри, её практически невозможно контролировать извне. То есть: как модели будут сбоить при принятии решений в неструктурированном потоке текста, точно так же и внешние контроллеры будут сбоить при попытке за этим потоком уследить.

—

В заключение отвечу на возможный упрек по поводу избыточности: «Пихать 1100 токенов системного промпта в каждый запрос — это дорого и долго».

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

Однако, как только вся эта механика и логика уйдет в стандартные дата-сеты, промпт сократится до 100-200 символов. Достаточно будет просто указать принципы приоритизации и формулу синтеза ответа, а остальные правила и логику модель будет применять автоматически. Произойдет то же самое, что и с человеком: то, что мы сейчас тренируем как сознательную «Систему 2» в контексте, со временем уйдет в обучающие веса модели и станет её интуитивной «Системой 1». И тогда промпт-инжиниринг окончательно превратится в архитектуру когнитивных алгоритмов.

Для тех, кто хочет пойти и потестировать системный промпт: github.com/RealEgor/re-think_protocol