Это чистого хвастовства пост: хвастаюсь апдейтом паттерна A.6.P по повышению семантической точности текста и работой его специализаций в кластере “рассуждений на границе” A.6. Последним штрихом было то, что я воткнул в A.6.P кроме анафоры ещё и метонимию. По идее, нормальные инженерные рассуждения начинаются с “метафор”, полных всякими приёмами усиления литературного воздействия текста, которыми обычно пользуются поэты: вот эти все анафоры, метонимии, гиперболы и так далее. Напомню: анафора - это когда вы вместо текста подставляете местоимение. “Мама мыла раму. Она её мыла мылом” - надо распаковать, что там “она” и что “её”, не перепутав при этом маму и раму. Синтаксически этого сделать нельзя, надо понимать, что там за ситуация в реальной жизни. Метонимия - это когда “за столом” вдруг означает “за столом переговоров Эфиопия и Непал” (почему бы и нет), а в реальности никакого физического стола, а Эфиопия и Непал как “страны” вообще не живые существа, которые могут “переговариваться”, это тоже для точного рассуждения надо распаковывать, что там хотели сказать, как это будет в реальном мире.
Гипотезы сначала формулируются именно таким художественным языком, который заведомо крайне неточен. Проблема: в таком языке легко выдвигать гипотезы, но невозможно добиться точной коммуникации и формального инженерного рассуждения. То есть такие гипотезы нельзя проверить, насколько они соответствуют реальности. Художественный язык надо “распаковать” на богатую онтологию выбранной предметной области, ибо в художественном языке одно слово выражает целую ситуацию, он очень компактен: “ночевала тучка золотая на груди утёса-великана” можно довольно долго распаковывать в какое-то более-менее точное для дальнейших рассуждений описание (скажем, понятие “ночь” из “ночевала” надо вывести, в “утёсе-великане” заподозрить “гору” и т.д.). До этой распаковки поэтический мозг радостно плодит галлюцинации под каждым словом – каждый мозг свои галлюцинации. Понимание затруднено, надо как-то перевести художественную речь момента выдвижения гипотезы в более-менее инженерную, пригодную для коллективного обсуждения, мышления и действия.
Вот это повышение точности языка требует
– по каким-то ключевым словам-триггерам раскрыть/распаковать онтику (обрывок онтологии) ситуации, затем
– подложить под эту онтику какую-то математику (мат. объекты с понятным поведением, чтобы потом рассуждение не рассыпалось – по факту потом вы сможете рассуждать с математической точностью, “формализация” как раз этот шаг, хотя поэтический язык назовёт через метонимию весь этот процесс в целом “формализацией” по имени вот этого одного внутреннего шага, но мы будем говорить о процессе в целом как “повышении семантической точности”), затем
– поправить онтологию под эту математику
– затем точно назвать понятия этой онтологии какими-то специфичными для этой онтологии лексемами.
Паттерн A.6.P как раз и предписывает этот процесс, а паттерны его специализаций дают подсказки, что там с онтикой, математикой и лексикой для некоторых типовых случаев:
– A.6.5 - всяческие “связывания”, которые оказываются подстановкой объекта на место/слот в каком-то отношении, сигнатуре, интерфейсе, наборе параметров. Типовое слово binding, это red flag для необходимости применить A.6.5.
– A.6.6 - ситуация зависимости от какой-то базы/полюса/основания. Ключевая метафора - “якорь”, красный флаг тут выставляется на всяческие anchoring.
– A.6.C - распаковка понятия contract
– A.6.8 - распаковка понятия service
– … и такого будет много, но если вы заподозрили художественность, то неплохой идеей будет использовать общий паттерн A.6.P и создать его специализацию “на лету”, под вашу ситуацию.
В качестве тестирования работы паттерна я выбрал свеженький текст “The Missing Layer of AGI: From Pattern Alchemy to Coordination Physics” ([2512.05765] The Missing Layer of AGI: From Pattern Alchemy to Coordination Physics), написанный сам вполне алхимическим художественным языком (вот вам прямо из абстракта: “theory of semantic anchoring that models reasoning as a phase transition governed by effective support”). Так что этот текст весь “краснофлажный”, сплошь состоит из этих binding, anchoring, support и прочих иносказаний с плохо понимаемым смыслом.
Превращаем эту статью в инженерный паттерн ML.3 при помощи First Principles Framework (FPF берём в GitHub - ailev/FPF: First Principle Framework), я такое уже делал пару раз (ML.2 - Evolvability нейросети: как решить конфликт интересов нейросети как саморазработчика-самоархитектора: ailev — ЖЖ, ML.1 - FPF и gonzo-обзоры архитектуры нейросетей: ailev — ЖЖ) на примере статей из gonzo-обзоров, но тут уж я сам (понимаю Григория, он такую художественную литературу в свои обзоры не пускает). В принципе, в статье ничего нового нет, она просто пытается формализовать всем известные вещи (что хорошо), делая это плохим языком. FPF доделывает работу за авторов, промпт в этот раз на пару строчек длинней предыдущих (а всё вместе можно посмотреть в https://chatgpt.com/share/695cbee6-e7bc-8013-af36-492133c1dbe5):
В файле у тебя спецификация FPF. Прочти полный текст статьи [2512.05765] The Missing Layer of AGI: From Pattern Alchemy to Coordination Physics, где вводятся понятия semantic anchoring, support, binding и другие понятия описания границы, требующие обязательной “распаковки” по кластеру A.6 в целом и паттерну A.6.P и его подпаттернам A.6.5 (binding) и A.6.6 (anchoring, support) в частности.Дальше ждём 32 минуты 54 секунды (ChatGPT 5.2 Pro на extended thinking) и получаем текст, в котором хотя бы понятно, в чём там вообще дело:
Пиши на основе статьи паттерн ML.3 по шаблону из E.8. Не используй при этом терминологию FPF, не объясняй FPF и распаковку, пиши по-русски, добавь дидактичности, текст итогового паттерна будут читать инженеры-менеджеры. В паттерне используй не оригинальные понятия из статьи, а только “распакованные” (восстановленная semantic precision) понятия. Следи, чтобы в тексте не проскакивали нераспакованные понятия, которые в A.6.P и его специализациях заявлены как red-flag. Проверь, чтобы вместо одного невнятного перегруженного понятия ты не выбрал в качестве замены другое, столь же перегруженное (скажем, вместо “якоря” использовать “основу” или “базу” - это слишком общие понятия, они не отражают онтологию предметной области, это метафоры, а не точные объекты, с этим и имеет дело A.6.P и его специализации. Если нужной специализации не найдётся, используй A.6.P напрямую).
ML.3 - Измеримый порог надёжного вывода для LLM‑систем
Тип: Архитектурный
Статус: Черновик
Нормативность: Нормативный
ML.3:1 - Рамка
В системах на базе больших языковых моделей часто наблюдается нелинейность: добавили пару примеров, один документ из поиска или результат инструментального вызова — и ответы из «похоже на правду, но мимо» превращаются в устойчиво правильные. И наоборот: небольшой шум во входе может полностью сломать решение.
Для инженера‑менеджера это выглядит как отсутствие управляемости. Команда не может уверенно сказать, где проходит граница между «модель воспроизводит наиболее вероятные шаблоны обучения» и «модель следует поставленным ограничениям и проверяемым данным».
ML.3:2 - Проблема
Обычно команда делает два шага: добавляет больше внешних материалов во вход и вводит пост‑проверку ответов. Но без явной модели причинности это превращается в эмпирическое тюнингование без объяснимых причин: почему стало лучше, а где стало хуже — непонятно.
В результате надёжность не воспроизводится между версиями модели и окружениями. Стоимость растёт быстрее качества, потому что вход «раздувается» и приносит шум. Символы и термины начинают означать разное в разных участках цепочки. А дискуссии между агентами или людьми сходятся к «красивой» формулировке, а не к проверяемому выводу.
ML.3:3 - Силы и напряжения
| Сила | Напряжение |
|---|---|
| Надёжность vs стоимость | Больше внешних материалов и проверок повышают вероятность правильного вывода, но увеличивают задержку и бюджет вычислений. |
| Богатство входа vs шум | Чем больше документов и примеров, тем выше шанс содержать нужный факт; но тем выше шанс принести противоречие или отвлекающий материал. |
| Гибкость vs воспроизводимость | Адаптация под каждый кейс улучшает локально; стандартизация нужна для контроля качества и аудита. |
| Скорость доставки vs проверяемость | «Сразу ответить» выгодно продукту; «сначала собрать свидетельства и проверить устойчивость» выгодно рискам. |
| Жёсткая форма ответа vs удобство пользователя | Обязательные ссылки на источники и строгий формат повышают качество, но ухудшают UX и увеличивают число отказов. |
ML.3:4 - Решение
Универсальное правило. Для каждого запуска системы фиксируйте три измеримые величины и используйте их как «панель приборов» для управления качеством:
Концентрация решения (ρ) — насколько сильно множество независимых прогонов сходится к одному и тому же финальному ответу при текущем наборе внешних материалов.
Чувствительность к возмущениям (d) — насколько меняется ответ при контролируемых малых изменениях входа (перефраз, перестановка ограничений, добавление отвлекающего документа, переименование символа).
Суммарный вес внешних материалов (k) — сколько именно внешних элементов вы допустили во вход и с каким весом (например, 1 за элемент или пропорционально длине/доверенности).
Затем вычисляйте скалярную оценку управляемости вывода S, которая возрастает при высокой ρ и убывает при высокой d и чрезмерном k. Практичная форма, предложенная в статье:
S = ρ − d − γ·log(k), где γ задаёт штраф за разрастание входа в шумной или ресурсно‑ограниченной среде. (arXiv)
Далее задайте порог S_crit для конкретного класса задач. Если S выше порога, система допускает ответ как достаточно надёжный. Если S ниже порога, система не «дожимает» ответ стилем, а меняет управляющие воздействия: уточняет внешние материалы, снижает чувствительность, пересматривает интерпретации символов.
ML.3:4.1 - Решение — Как измерять ρ, d, k
Шаг 1 — зафиксируйте вход как пакет. Входом считается не только текст запроса пользователя, но и весь добавленный материал: документы из поиска, примеры, результаты инструментов, промежуточные вычисления.
Шаг 2 — измерьте k.
Определите множество внешних элементов E и веса w_e. Тогда:k = Σ_{e∈E} w_e, где w_e = 1 по умолчанию или масштабируется длиной/доверенностью элемента. (arXiv)
Шаг 3 — измерьте d.
Сгенерируйте m возмущённых вариантов входа {x̃_j}, получите ответы y(x) и y(x̃_j) и посчитайте:d = (1/m) Σ_{j=1..m} D(y(x), y(x̃_j)), где D — метрика расстояния, подходящая задаче: точное совпадение, нормализованная редакционная дистанция, семантическая дистанция или проверка следования/противоречия. (arXiv)
Шаг 4 — измерьте ρ.
Для классификации используйте маржу вероятностей между лучшим и вторым вариантом.
Для задач рассуждения берите N независимых прогонов и кластеризуйте по финальному ответу; тогда
ρ ≈ |C_major| / N, гдеC_major— доминирующий кластер. (arXiv)
ML.3:4.1.1 - Решение — Минимальный псевдокод
E = select_external_items(query) # документы, примеры, ответы инструментов k = sum(w_e(e) for e in E)Y = [run_model(query, E, seed=i) for i in 1..N]
rho = size(dominant_cluster(Y)) / NX_pert = perturb_inputs(query, E, m)
d = avg(distance(run_model(xp), representative(Y)) for xp in X_pert)S = rho - d - gamma * log(k)
if S < S_crit:
return refine_E_or_request_missing_facts()
else:
return representative(Y)
Практическая подсказка для инженера: начинайте с маленьких N и m (например, 5–10), а затем увеличивайте их только для рискованных классов задач или когда мониторинг показывает рост d.
ML.3:4.2 - Решение — Что делать, когда S ниже порога
Когда S ниже порога, у вас есть три рычага — ровно по трём величинам:
Поднять ρ.
Добавьте дискриминирующие внешние элементы: не «ещё один общий документ», а такой, который различает две конкурирующие гипотезы.
Для специальных символов и операторов задайте интерпретацию через несколько коротких примеров и исключите альтернативные трактовки в текущей сессии.
Снизить d.
Уберите противоречивые или нерелевантные документы из входа.
Сведите формат задачи к канону: одинаковый порядок ограничений, одинаковые имена параметров, одинаковые единицы измерения.
Добавьте проверяющий компонент, который отклоняет размытые или непроверяемые утверждения и возвращает уточняющие вопросы. (arXiv)
Если вы используете несколько агентов, задайте правило поведения от S: при низком S роли должны быть осторожными и ориентированными на сбор недостающих фактов; при высоком S роли могут быть более критичными к конкурирующим гипотезам. (arXiv)
Ограничить k.
Замените «широкий поиск» на «точный поиск» и храните краткие выдержки вместо целых документов.
Введите квоту на число документов и правило замены: новый элемент входит только если вытесняет менее полезный.
ML.3:4.3 - Решение — Переопределение символов и терминов
Статья показывает, что два примера могут заставить модель интерпретировать «−» как «+» и дать 11 вместо 5. (arXiv) Это полезно как механизм, но опасно как источник скрытой неоднозначности.
Поэтому вводите таблицу интерпретаций: что именно означает каждый специальный символ или термин в данной задаче. Затем тестируйте таблицу теми же возмущениями: переименование символа, перефраз инструкции, перестановка примеров.
Если при таких изменениях смысл «плывёт», то d растёт, а S падает. В этом случае система должна перейти в режим уточнения или добавления дискриминирующих внешних элементов.
Запоминающаяся формула: качество растёт не от объёма входа, а от концентрации решения и устойчивости к мелким изменениям.
ML.3:5 - Примеры
Скажи. Система становится управляемой, когда команда измеряет ρ, d, k и принимает решения по порогу S_crit: либо фиксирует результат как достаточно надёжный, либо меняет управляющие воздействия, а не «выдавливает» ответ.
ML.3:5.1 - Примеры — Система
Сценарий. Во время инцидента нужно быстро ответить: почему выросли 5xx и что откатить. Источники: логи, метрики, runbook, последние деплои, статус зависимостей.
Применение паттерна.
Внешние элементы
E: выдержки из runbook, ссылки на конкретные графики, diff деплоя, последние алерты. Весw_eповышается для артефактов с явным указанием интервала времени и версии (например, commit hash, deployment id).d: прогоняем набор возмущений — перестановка ограничений, перефраз запроса, добавление одного отвлекающего алерта, переименование сервиса‑синонима.
ρ: делаем N прогонов с разными seed/temperature и проверяем, сходится ли финальная рекомендация (например, «откатить релиз R123»).
Если S ниже порога: ассистент не предлагает финальное действие, а формирует список недостающих фактов и точные запросы на извлечение.
Управленческий эффект. Инциденты можно вести по SLA: есть измеримые «признаки готовности ответа» и понятная политика эскалации. (arXiv)
ML.3:5.2 - Примеры — Знание
Сценарий. Нужно подготовить обзор исследований по теме (например, оценка RAG или тестирование LLM‑агентов) и сформулировать выводы для дорожной карты.
Применение паттерна.
E: список статей/стандартов, каждая с идентификатором (DOI/arXiv), плюс краткие выдержки, а не полный PDF.ρ: N независимых прогонов формируют тезисы и ссылки; ρ — доля прогонов, которые приходят к одному набору выводов и совпадающим цитатам.
d: возмущения включают перестановку списка источников, добавление спорной статьи, переформулировку вопроса с тем же смыслом.
Если S низкий: система формирует запросы на дополнительные источники, которые различают конкурирующие позиции, и отмечает утверждения, требующие проверки на ваших данных.
Управленческий эффект. Обзор становится воспроизводимым артефактом: при смене модели или обновлении корпуса источников видно, что именно изменилось — ρ, d или k. (arXiv)
ML.3:6 - Предвзятости и ограничения
Уклон в измеримость. Паттерн предпочитает численные индикаторы качественным впечатлениям. Это хорошо для управляемости, но требует дисциплины измерений и выбора метрики D. (arXiv)
Уклон в проверяемость. Предполагается доступ к внешним артефактам и возможность управлять ими как входными элементами.
Уклон в устойчивость, а не в среднюю точность. Мы измеряем дрейф при малых изменениях, потому что именно он ломает эксплуатацию.
Уклон в управленческий контроль. Порог S_crit и политика действий при низком S — решение команды, а не «физическая константа» модели.
Уклон в обучаемость. Паттерн намеренно дидактичен: он даёт язык для обсуждения качества без магического мышления.
ML.3:7 - Чек-лист соответствия
| ID | Requirement | Purpose |
|---|---|---|
| CC-ML3.1 | Для каждого запуска фиксируется список внешних элементов E с идентификаторами источников и весами w_e. | Воспроизводимость и аудит входа. |
| CC-ML3.2 | Задокументирован набор возмущений входа: минимум перефраз, перестановка ограничений, отвлекающий документ, переименование символа. | Измерение d. |
| CC-ML3.3 | Выбрана метрика расстояния D и объяснено, почему она адекватна задаче. | Чтобы d не было «магическим числом». |
| CC-ML3.4 | Для задач рассуждения применяется многократный прогон и оценка ρ через доминирующий кластер ответов. | Отличать «случайно угадал» от «стабильно сходится». |
| CC-ML3.5 | Определены формула S, параметр γ и порог S_crit; описана калибровка. | Чтобы граница надёжного режима была явной. |
| CC-ML3.6 | Описана политика действий при S < S_crit: что меняем и в каком порядке. | Управляемая деградация вместо выдумывания. |
| CC-ML3.7 | Для специальных символов и терминов задана таблица интерпретаций и тест на её устойчивость. | Контроль скрытых переопределений. |
ML.3:8 - Типовые ошибки и как их избежать
| Ошибка | Симптом | Почему не работает | Как предотвратить или исправить |
|---|---|---|---|
| «Добавим ещё входных материалов» | Ответы становятся длиннее, но не стабильнее; иногда хуже. | k растёт, ρ не обязательно растёт, d может вырасти из-за противоречий. (arXiv) | Ограничьте k квотой; добавляйте только дискриминирующие элементы; меряйте S. |
| Смешивание источников без идентификаторов | Нельзя воспроизвести результат после обновления корпуса. | Потеря контроля над E. | Введите список E с версиями/ID и храните выдержки. |
| Скрытые переопределения символов | В разных шагах цепочки один и тот же знак трактуется по-разному. | Растёт d; команда спорит о смыслах вместо фактов. (arXiv) | Таблица интерпретаций + тесты переименования/перефраза. |
| Проверка «по вкусу» | Одни принимают ответы, другие отвергают. | Нет порога и общего языка качества. | Определите S_crit и минимальные тесты устойчивости. |
| Дискуссия без арбитра качества формулировок | «Красиво звучит» побеждает «проверяемо». | В цепочку попадают размытые и нефальсифицируемые утверждения. (arXiv) | Введите роль проверяющего, который требует явных предпосылок, источников и критериев опровержения. |
ML.3:9 - Последствия
| Плюсы | Минусы и компенсации |
|---|---|
| Предсказуемость качества. Понятно, почему ответ принят или отклонён: по ρ, d, k и порогу. | Накладные расходы. N прогонов и m возмущений увеличивают стоимость; уменьшайте N и m для низкого риска, кэшируйте. |
| Управляемая деградация. При низком S система запрашивает данные или уточнения вместо выдумывания. | Нужны метрики D. Начните с простых критериев и улучшайте итеративно. |
| Стабильность при изменениях. Обновление модели или корпуса видно как сдвиг показателей. | Порог требует владельца. S_crit — управленческое решение; фиксируйте риск‑классы и ответственность. |
| Лучшая инженерная коммуникация. Споры переходят от вкусов к экспериментам. | Риск оптимизации под метрику. Защититесь контрольными наборами кейсов и пересмотром набора возмущений. |
ML.3:10 - Почему это работает
Статья предлагает рассматривать поведение LLM под внешними ограничениями как пороговый эффект. Пока внешнего материала мало или он противоречив, модель следует наиболее вероятным шаблонам обучения. Когда внешнего материала достаточно и он устойчив, условное распределение ответов резко смещается к целевому решению. (arXiv)
Три величины из решения покрывают три причины эксплуатационных провалов:
ρ отвечает за наличие доминирующего решения среди независимых прогонов. (arXiv)
d отвечает за устойчивость к малым изменениям формулировок и входных материалов. (arXiv)
k отвечает за стоимость и риск внесения шума во вход. (arXiv)
В статье те же величины иллюстрируются на few‑shot категоризации: для распознавания «cat» ρ соответствует «зазору» между лучшей и второй гипотезой, d отражает чувствительность к малым изменениям входа, а k — число и вес примеров в подсказке. (arXiv)
Эта тройка даёт управляемость: качество можно повышать не только «обучением модели», но и инженерными решениями вокруг неё — выбором источников, структурой входа, процедурами проверки и хранением состояния выполнения. (arXiv)
ML.3:11 - Соотнесение с современными практиками
| Тезис | Практика | Источник | Как это отражено в паттерне | Статус внедрения |
|---|---|---|---|---|
| Концентрацию решения нужно оценивать по множеству прогонов. | Самосогласование: выбор ответа по кластеру наиболее частого результата среди разных траекторий. | Wang et al., 2022 (arXiv) | ρ в паттерне — операционализация этой идеи. | Берём как есть. |
| Устойчивость важна для эксплуатации. | Поведенческое тестирование и тесты инвариантности к возмущениям. | Ribeiro et al., 2020 | d строится как средняя дистанция между ответами при возмущениях. | Берём и адаптируем. |
| Внешние источники нужны для фактов и трассируемости. | Retrieval‑augmented generation: генерация с доступом к внешнему корпусу. | Lewis et al., 2020 (arXiv) | E и k формализуют внешний материал как управляемый ресурс. | Берём как есть. |
| Для сложных задач нужны действия и проверки. | Чередование рассуждения и действий, чтобы снизить галлюцинации. | Yao et al., 2022 (arXiv) | При низком S управляющее действие — запросить данные или вызвать инструмент. | Берём и адаптируем. |
| Многоагентные схемы полезны при программируемых ролях. | Многоагентный диалог и программируемое взаимодействие агентов. | Wu et al., 2023 | Паттерн добавляет критерий принятия сообщений через ρ/d/k. | Адаптируем. |
| Самокритика и ревизия снижают риск неверных ответов. | Самокритика и ревизия по набору принципов. | Bai et al., 2022 | Проверяющий компонент задаёт обязательные критические вопросы при низком S. | Адаптируем. |
Паттерн отличается от многих практик тем, что не сводит качество к одной средней метрике. Он управляет эксплуатационным переходом между режимами через измеримые диагностические показатели и явную политику действий.
ML.3:12 - Связи
Хорошо сочетается с: RAG, инструментальными вызовами, многоагентными ролями, внешними проверяющими и журналированием артефактов. (arXiv)
Порождает артефакты: протокол запуска (список
E, веса, параметры N и m), отчёт по ρ/d/k/S, набор возмущений как регрессионный тест, политика порогов по риск‑классам. (arXiv)Ограничивает: «чистые» цепочки рассуждений без источников и без тестов устойчивости в продуктиве, особенно в задачах с последствиями. (arXiv)
ML.3:End
