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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это привело к внедрению очень гибкой механики — 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). Разработчики пишут длинные текстовые промпты, рассказывая, как они думают и на что обращают внимание. Однако, когда всё это идет сплошным текстом, мы получаем модели, которые просто пытаются подобным же образом предсказать следующий шаг на основе ранее увиденного огромного количества таких вот рассуждений.

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

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

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

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

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

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

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

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

---

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