Comments 19
Попытался въехать, но своим недалёким умом так и не понял: как это можно использовать на практике в связке с LLM. Объясните, пожалуйста.
У меня при чтении этой статьи сложилось впечатление, что этот "Решатель" - что-то вроде "Корчевателя".
Если совсем просто: LLM — это "мягкий" интерфейс (Soft), а движок — "жесткое" ядро (Hard). LLM может сочинять, но не умеет гарантировать. Движок не умеет сочинять, но гарантирует результат.
Кроме того, в статье я больше по верхам прошелся (L3/L4), но сейчас ядро уже работает с более сложными логиками, например, в L7-режиме. Там алгоритмически выделяется до 108 вычислимых состояний. Если такую стейт-машину попробовать запихнуть в системный промпт LLM, она поплывет моментально, контекста не хватит удержать правила.
Поэтому архитектурно я сейчас двигаюсь к понятию роя микроядер. Идея в том, что вместо одной большой модели у вас работают тысячи/миллионы/миллиарды маленьких детерминированных решателей.
Каждое такое микроядро — это крошечный движок со своей таблицей и жестким контрактом. И общаются они между собой не текстом, а артефактами проверки. Один возвращает инвариант (типа, проверил структуру, тут цикл длины 2, все стабильно). Другой кидает witness — контрпример, почему одна гипотеза хуже другой. Третий предлагает атом ремонта — конкретное действие, как исправить стык в графе.
Получается такой полный аналог нейросети, только вывернутый наизнанку. В нейронке у вас миллиарды весов и вероятности, и вы не знаете, почему именно сработал конкретный нейрон. Это черный ящик. А здесь у вас может быть рой из миллионов микроядер, но каждое действие внутри — это проверяемая алгебраическая операция по таблице. Вход -> миллион строгих проверок и замыканий -> Выход с доказательством.
Так что цель не в том, чтобы научить LLM думать — это дорого и нестабильно. Цель в том, чтобы оставить LLM роль интерфейса и креатива, а функцию мышления и контроля отдать вот этому рою. Это, на мой взгляд, единственный путь получить прозрачную инженерную систему вместо стохастической.
Смотри, фишка тут в разделении ответственности. LLM круто работает как интерфейс (понимает естественный язык) и генератор идей, но она плывет, когда нужна строгая логика или гарантии. Табличное ядро эту строгость возвращает. На практике схем обычно три:
LLM как переводчик в канон. Пользователь пишет проблему текстом, LLM перегоняет это в JSON-структуру (эпизод). Движок этот JSON прогоняет через таблицу и выдает строгий результат (или ошибку). А LLM потом просто пересказывает этот технический отчет на человеческий язык. В итоге — пользователю удобно, а под капотом математика, которая не придумывает отсебятину.
Фильтрация галлюцинаций (самое полезное). Допустим, нужно построить план действий. LLM предлагает 5 вариантов. С виду все ок, но по факту два из них нарушают бизнес-логику (нельзя, например, перейти из статуса А в Б без визы). Движок проверяет каждый вариант. Те, что дали FAIL — выкидываем. Пользователю отдаем только верифицированные сценарии. Превращаем «похоже на правду» в «гарантированно работает».
Работа со сложными стейт-машинами. Этот движок сейчас у меня работает не только с L3, L4-логикой (см. таблицы конечной магмы), но и с L5, L6, L7-логиками. Так, в L7 выделяется 108 каналов — это, по сути, очень навороченный конечный автомат. Засунуть такую логику в системный промпт нереально, модель запутается и начнет галлюцинировать. Поэтому LLM тут только классифицирует вход (попали в такое-то состояние), а саму траекторию и переходы считает жесткое табличное ядро.
Короче, LLM используем для общения и креатива, а движок — там, где нужна железобетонная логика и регрессионные тесты.
Кстати, если углубиться в архитектуру (про что в статье только намеки), то сейчас я пришел к концепции роя микроядер. Это как раз к вопросу, чем это отличается от обычной нейросети.
Представьте, что вместо одного монолита LLM у вас работают тысячи мелких детерминированных решателей. Каждое такое микроядро — это крошечный движок с фиксированной таблицей и своим контрактом.
Они между собой общаются не текстом, а артефактами проверки: — Инварианты (проверил структуру, все стабильно). — Witnesses (свидетели) — когда одно ядро находит контрпример, почему одна гипотеза хуже другой. — Атомы ремонта — конкретные предложения, как исправить стык, если логика нарушена.
Получается полный аналог нейросети, только вывернутый наизнанку. В нейронке у вас миллиарды весов и вероятности, и вы не знаете, почему сработал конкретный нейрон (условно). Это черный ящик. А здесь — рой микроядер, где каждое действие — это проверяемая алгебраическая операция по таблице.
То есть вход -> миллион строгих проверок и замыканий -> выход с доказательством.
Поэтому я и не пытаюсь научить LLM "думать" сложные вещи (например, на 108 состояниях в L7 она моментально поплывет). Я оставляю ей интерфейс, а функцию контроля и удержания траектории отдаю вот этому рою.
Вообще, про архитектуру роя и взаимодействие ядер я могу написать отдельную статью, если тема интересна. Это тянет на принципиально новый подход к построению сетей.
Там идея в том, чтобы собрать аналог нейросети, но полностью детерминированный. Вместо нейронов с весами — микроядра с таблицами. Вместо backpropagation — обмен артефактами проверки (свидетелями и атомами ремонта).
Это дает систему, которая масштабируется как нейросеть, но не является «черным ящиком». Каждое решение в ней можно размотать до исходной логики. Особенно это критично на сложных режимах (L3 и выше), которые я упоминал — там LLM просто теряет контекст, а такая сеть держит структуру жестко.
Поясню про сложность. В настоящее время в индустрии даже про L4-логику практически ничего не знают. Академическая наука сейчас только подбирается к осознанию L3 (тернарных структур).
Вот цитата из моей статьи «Алгебраическое различение и тернарные структуры»:
«Один из ключевых переходов в истории алгебры — это отказ от анализа отдельных элементов в пользу анализа пар и троек, то есть конфигураций. Именно переход к орбитальной факторизации позволяет обнаружить глубинные инварианты структуры... В тернарной логике различение типов троек становится критически важным... Именно отсюда возникает возможность перехода от "арифметики" к алгебре различения».
То есть то, что я использую в движке — это прикладная реализация математики, которая сейчас находится на переднем крае (а уровни L5–L7 вообще пока terra incognita).
Для тех, кому интересно, на чем это базируется, привожу список публикаций, которые приближаются к пониманию моей логики L3 (но до L4+ там еще не дошли):
Burris, S., & Sankappanavar, H. P. A Course in Universal Algebra. Springer, 1981.
Linckelmann, M. The Block Theory of Finite Group Algebras. Cambridge University Press, 2018.
Sitharam, M., Wang, M., & Willoughby, J. Handbook of Geometric Constraint Systems Principles. Springer, 2018.
Goodman, R., & Wallach, N. Symmetry, Representations, and Invariants. Springer, 2009.
Fiore, T. M., & Noll, T. Commuting Groups and the Topos of Triads. In: Mathematics and Computation in Music. MCM 2011. Springer.
Halász, K. Colorings of Cayley Tables of Finite Groups. Simon Fraser University, MSc Thesis, 2017.
Babai, L. Automorphism Groups, Isomorphism, Reconstruction. In: Handbook of Combinatorics, Elsevier, 1995.
Я намеренно не перегружал основную статью этой теорией, чтобы не смещать фокус с инженерного применения на чистую алгебру, но база у проекта именно такая.
Выглядит как типичная "Экспертная система", где все знания пишутся руками. Кто-то пишет предикатами Пролога, у вас свой json-синтаксис, а по функциональности это одно и то же.
Справедливое замечание, корни действительно растут из одной грядки — дискретка, формализм, все дела. Но архитектурно это совсем другой зверь, и вот почему.
Во-первых, разница в самом движке. В классических экспертных системах или том же Прологе у тебя база знаний на иф-зенах. Ты хардкодишь правила, а движок занимается логическим выводом. У меня подход data-driven: ядром выступает не портянка правил, а табличный оператор PxP->P плюс механизм замыкания. То есть поведение системы — это не проход по дереву решений, а честная дискретная динамика, когда стейт летит к аттрактору, будь то фикс-точка или цикл.
Во-вторых, это вопрос продакшен-рэди обвязки. Экспертные системы часто работают корректно "по смыслу", но ложатся при поддержке без нормального пайплайна. У меня тут фокус на воспроизводимость: спецификации, валидаторы, регрессионные тесты — это first-class citizens. Если контракт нарушен, у тебя просто не соберется билд или упадет валидация, а не вылезет логическая ошибка в рантайме.
Третий момент — математика под капотом. Я явно юзаю группу автоморфизмов Aut(op) для факторизации пространства гипотез. Это позволяет кратно срезать перебор и контролировать инварианты, чего в дефолтных рул-энжинах обычно нет.
Ну и на выходе отличие принципиальное: я даю структурированный репорт с witnesses — конкретными кейсами, которые диффят гипотезы. Короче, формально это, может, и близко, но это не "набор знаний руками", а детерминированное вычислительное ядро, которое можно без страха встраивать в бэкенд.
Я не понимаю, как обучать вашу систему. LLM-ке надо просто скармливать горы текстов.
А тут знания пишутся вручную в json-ах?
Тут происходит подмена понятий, это принципиально разные классы систем. ЛЛМка — это статистическая модель, она оптимизирует правдоподобие, а не корректность. Можно сколько угодно обвешивать её RAG-ом и промптами, но архитектурно у вас нет гарантии, что ход легален. В промышленном контуре, особенно в финтехе или комплаенсе, критичны две вещи — детерминизм и проверяемость. Один и тот же вход обязан давать одинаковый выход, и должно быть четко видно, почему сработал гейт или ремонт. У нейросетей понятия «звучит убедительно» и «правильно по контракту» — это разные вселенные. Дообучение меняет веса и стиль, но не дает строгого понятия допустимого шага, который можно автоматически проверить.
JSON в моем случае — это не энциклопедия фактов, набитая вручную, а спецификация закона. Там лежат состояния, таблица операций и инварианты. Это работает как компилятор или сетевой протокол типа TCP. Никто же не обучает SQL на гигабайтах текстов, там задают жесткую логику исполнения. Здесь то же самое: спецификация поведения вместо вероятностного угадывания. ЛЛМ в этой схеме может быть разве что переводчиком, который парсит текст в структуру, но само решение и удержание контракта — не её работа.
И обучение тут выглядит иначе. Это не бэкпроп по корпусам, а калибровка спеки в конечном пространстве. Появился новый кейс — зафиксировали правило, добавили валидатор, чтобы при апдейтах ничего не отвалилось. Это процедурное знание: что считается легальным ходом, а где обязателен стоп. В задачах с рисками цена ошибки — это не неловкий ответ в чате, а нарушение регламента. Поэтому нужно ядро, которое гарантирует отсутствие нелегальных шагов, а не просто умеет красиво поддерживать диалог.
В далекой перспективе насчет спора «заменит ли это LLM» — я ставлю на то, что заменит. И тут дело не в амбициях, а в архитектурной целесообразности.
Чтобы не быть голословным, советую глянуть свежий препринт https://arxiv.org/abs/2601.06851. Там ребята раскопали интересный эффект: в больших моделях «интеллект» не размазан ровным слоем по всем миллиардам параметров. Он самопроизвольно собирается в довольно компактное «синергетическое ядро» — зону, где реально происходит связка данных. А всё остальное — это гигантский и дико прожорливый обвес: память фактов, лингвистические кодеки и просто статистический шум.
Отсюда чисто инженерный вопрос: если блок принятия решений реально компактен, зачем нам эмулировать его через стохастический «черный ящик» на 70 миллиардов параметров с конским ценником на инференс?
Мой движок — это попытка выдрать это ядро наружу. Сделать его явным, табличным и проверяемым, вместо неявного нейросетевого аттрактора. Мы просто делаем рокировку: логику выносим в детерминированные таблицы (L3–L7), а нейронку оставляем чисто как интерфейс. Пусть она парсит человеческий текст на входе и красиво заворачивает JSON в слова на выходе.
В такой схеме LLM теряет роль Decision Maker’а и становится просто умным кодеком. И это выгодно. Табличный автомат с замыканием работает мгновенно, стоит копейки и физически не умеет галлюцинировать — у него есть только легальные переходы, ремонт или блок. Поэтому в задачах реального управления, права или финтеха, где есть ответственность за ход, мы неизбежно придем к разделению: язык — нейросетям, а решения — выделенным детерминированным ядрам.
P.S. Ну а может и не в далекой, если найдутся спонсоры, но это не точно.
ответ дополнен здесь https://habr.com/ru/articles/988698/#comment_29465502
Дополнение (просьба не бить тапками, это пока еще не просчитано).
Если мы отказываемся от черного ящика LLM в пользу детерминированных микроядер, встает вопрос: как эти ядра общаются? В LLM мы гоняем тяжелые эмбеддинги (вектора на 4096 чисел), которые никто не может прочитать. Здесь архитектура строится на алгебре, и это дает три инженерных бонуса.
1. Обмен орбитами, а не текстами
Ключевая фишка — эквивариантность. Если у вас есть симметрия (автоморфизм сигма), то результат вычисления для одного состояния автоматически верен для всех его "повернутых" версий.
Step(sigma(state)) = sigma(Step(state))
Что это значит на практике:
Вместо того чтобы учить сеть обрабатывать 100 разных вариантов одной и той же ситуации, мы сводим их к одному каноническому представителю (факторизация по орбите).
Микроядро получает входящий эпизод.
"Поворачивает" его в канонический вид (стандартизирует).
Вычисляет решение (аттрактор, ремонт, риск).
Результат "разворачивается" обратно под конкретный кейс.
Выгода: Сеть не переучивается 6 или 42 раза для симметричных ситуаций. Всё, что вычислено для канонического представителя, мгновенно доступно всей системе.
2. Протокол сообщения: "Паспорт + Свидетель"
Вместо непрозрачных векторов микроядра обмениваются компактными JSON-структурами (сотни байт), которые удобочитаемы и проверяемы.
Типовое сообщение между узлами выглядит так:
op_id: Какой закон/уровень используется (L2 — L7).state_canon: Канонический вид задачи (очищенный от шума).sigma: Как именно мы "повернули" исходную задачу, чтобы получить канон.decision: Вердикт (PASS / REPAIR / BLOCK).witness: Самое важное. Короткий список шагов/клеток таблицы, которые привели к решению.
Инженерный смысл: Принимающему узлу не нужно "верить" отправителю. Он может взять state_canon, прогнать по трассе witness и математически подтвердить корректность решения за микросекунды. Это принцип Zero Trust внутри вычислительного ядра.
3. Эффективность "по железу"
Почему это быстрее и дешевле, чем инференс LLM:
Сжатие пространства поиска.
LLM видит "Вася не подписал письмо" и "Петя отправил без подписи" как разные тексты. Мое ядро видит их как один класс состояний (одна орбита). Если
|Aut| = 6, мы сокращаем пространство поиска в 6 раз. На уровне L7 сжатие еще сильнее.Дешевая коммуникация.
Мы не гоняем гигабайты активаций. Мы гоняем компактные "паспорта" задач. Сеть масштабируется по количеству событий, а не по длине контекста.
Кеширование логики.
Поскольку мы работаем с каноническими представителями, результаты можно (и нужно) кешировать. Если система один раз решила типовой конфликт "комплаенс vs скорость", она запомнила решение для всей орбиты. Следующий похожий кейс решится за O(1) — простым лукапом (lookup).
Итоговая архитектура: Гибрид
Чтобы не спорить о терминах "нейросеть", честная конструкция выглядит так:
Нейронный фронтенд: Обычные (небольшие) модели работают как парсеры. Они распознают эпизод из текста и выбирают нужный уровень абстракции.
Детерминированное ядро: Микроядра на таблицах Кэли принимают решения, гоняют орбиты и генерируют доказательства (witnesses).
Обучаемый контур: Reinforcement Learning настраивает не "знания о мире", а политику маршрутизации — какой уровень применить и какой риск считать допустимым.
"Ум" здесь локализован в проверяемой алгебраической машине, а не размазан тонким слоем по миллиардам параметров.
P.S. Это будет реальный разум, на уровне L7 со всем спектром эмоций (полагаю, живее человека).
Спойлер: в архиве уже есть алгоритм sym_scan_flow — по сути, это “сканер симметрий + гейты + ремонт”, то есть минимальное детерминированное когнитивное ядро; если называть вещи честно, это уже форма разума (в инженерном смысле: право на ход, проверяемость и самокоррекция по свидетелям).
И где именно в этой системе используется свойство σ быть автоморфизмом? В ваш питон код можно закинуть любую композицию перестановок (не обязательно автоморфизмов) на Pm и всё, что этот код сделает, - это перебором вычислит орбиту любого элемента "state". Алгебраической содержательности в этом процессе нет, вы не делаете никаких математических утверждений по поводу каких-либо классов σ на Pm. Композиции разных σ или каких-то взаимодействий разных σ между собой тоже не видно.
Если что, устройство Aut(Pm) весьма нехитро, она изоморфна группе кольца Zm по умножению, а если m простое, то группа циклическая. Всё.
"Движок решает инженерно корректную задачу: подобрать отображение σ (переименование меток), которое лучше всего согласует наблюдения" - не всякое переименование меток является автоморфизмом, так что не понятно какие σ вы рассматриваете, то ли Sym(Pm), то ли Aut(Pm).
Какое-то шарлатанство с заваливанием аудитории умными терминами.
Ответ 1. Про «обучение» и JSON
Вы сравниваете две разные парадигмы.
LLM обучается статистически: горы текстов перегоняются в веса. Это дает крутую языковую интуицию, но почти нулевой контроль и гарантии. Правила размазаны по миллиардам параметров.
У меня ядро — конечная вычислимая машина. Закон задан таблицами и спеками (да, в JSON), а дальше всё считается детерминированно и проверяется тестами.
JSON здесь — это не "ручной ввод знаний вместо обучения", а формат спецификации. Это как конфиг для Nginx или схема БД: мы фиксируем закон (таблицу), контракты, режимы и форматы отчетов.
Роль LLM в такой архитектуре — чисто интерфейсная: распарсить текст, извлечь эпизод, нормализовать вход. А вот само ядро работает как движок допуска: выдает PASS/REPAIR/BLOCK с указанием конкретной клетки и правила.
"Как обучать" в этой системе означает не "скармливать терабайты текста", а:
Настраивать маппинг (как кодировать реальность в эпизоды I/E/R (см. дополнение ниже)).
Настраивать профили допуска (какие переходы запрещены, какие требуют ремонта).
Собирать библиотеку процедур (типовые протоколы восстановления).
При этом сам закон композиции остается фиксированным и проверяемым. Это не "обучение весов", это "конфигурация автомата".
Ответ 2. Про «шарлатанство» и перестановки
Про структуру Aut(Z_m) я не спорю: для сложения по модулю это действительно группа обратимых элементов. Тут никакой магии, чистый канон.
Но вы упускаете ключевой момент: я не использую "любую перестановку" из Sym(Pm). Я рассматриваю только те sigma, которые сохраняют закон операции. То есть строго автоморфизмы таблицы Кэли.
В коде (см. TOOLS/...report_v1.py) стоит прямой фильтр: перестановка принимается только если для всех i,j выполняется условие: sigma( op(i,j) ) == op( sigma(i), sigma(j) ).
Это не риторика, это хардкорное ограничение. Все перестановки, которые ломают таблицу, отбрасываются и в группу Aut не попадают.
Алгебраическая содержательность тут не в том, чтобы "открыть" свойства циклической группы, а в построении инвариантов. Дальнейшие объекты (триады, каналы Q12, пространство Q108 в L7 (еще не писал о них здесь)) строятся так, чтобы не зависеть от переименования вершин. Aut тут работает как группа допустимых калибровок.
Как это работает, например, в L7:
Вычисляется Aut (порядок 6).
Берется подгруппа порядка 3.
Она режет пространство на орбиты (триады).
Из этого собирается Q12 и Q108.
Это не "перебор ради перебора", а строгая конструкция.
Разница между Sym и Aut здесь принципиальная. sigma из Aut — это смена координат при сохранении закона (легальная симметрия). sigma из Sym (не входящая в Aut) — это переименование, которое меняет саму таблицу (подмена закона).
Если разрешить любые перестановки из Sym, то да — можно перебором натянуть любую картинку на любые данные. Но это будет подгонка. В моем контуре sigma допускается только как автоморфизм таблицы Кэли. Это и есть граница между "координатной калибровкой" и "шаманством с переименованиями".
Дополнение
Разберём механику L4 на конкретном кейсе I–E–R, где абстрактная логика превращается в юридически значимый автомат. Здесь каждое состояние работает как режим шлюза в системе допуска. Солнце (PASS) означает, что транзакция чистая: цель легальна, риски очерчены, условие выполнено — можно комитить. Если выпадает R (REPAIR), система не падает, а требует стандартного патча: нужно приложить дополнительный лог, ограничить скоуп или добавить внешний источник данных. Состояние S (EXTRACT) сигнализирует о проблеме с семантикой: текущими определениями задачу не решить, нужно «снимать» уровень и переопределять, что мы вообще считаем доказательством или целью в этом контексте. А Минус (BLOCK) — это хард-стоп, полный запрет на выполнение операции, пока не изменится состав входного эпизода.
Сама триада I–E–R в этой оптике переходит из области философии в жесткую операционку. Интенция (I) перестаёт быть просто желанием или бизнес-нидом, она становится авторизованным правом на действие, обоснованным мандатом. Доказательства (E) превращаются в техническую предъявимость: это не набор фактов, а гарантия того, что любой аудитор сможет воспроизвести цепочку принятия решения. Риск (R) из абстрактного страха ошибки трансформируется в рабочий контур ограничений: это чёткие линии периметра, за которые выходить нельзя, и зоны, где действия разрешены протоколом.
Ключевой момент перехода на уровень L4 — это смена парадигмы с интуитивной на формальную. На уровнях L2–L3 решения часто принимаются на базе неявных соглашений, вкусовщины или привычек. Четвёрка выжигает этот субъективизм. Здесь понятие «правильно» становится синонимом юридической корректности: решение валидно только если оно обеспечено полномочиями, отсечено барьерами запретов и зафиксировано в неизменяемом аудит-следе. Направление вращения логического "вихря" здесь работает как вектор валидации, который прогоняет сырые данные через эту структуру, превращая входящий хаос в детерминированный и проверяемый результат, готовый к деплою в реальные процессы.
Ладно, немного забегу вперёд и приоткрою карты того, что лежит выше четвёрки. Потому что реальные производственные задачи редко укладываются в одну плоскую логику, даже очень строгую.
На уровне L5 появляется понятие кадра. Это ситуация, когда у вас есть две правды, и они не склеиваются. Классика: безопасники говорят «никакой автоматики в переписке без явной авторизации», а бизнес кричит «нужна скорость и эффективность». Конфликт здесь не в том, кто прав — в своих системах координат правы оба. Режимное ядро на L5 не ищет компромисс, оно ищет форму хода, которая легальна в обоих кадрах одновременно. Например, вместо скрытой автоматики система предлагает схему «черновик плюс подтверждение» или «автодействие с ключом отмены». Это уже согласование не мнений, а рамок легальности.
Следом идёт L6 — механика двух контуров. Любая живучая система крутится в двух циклах. Есть контур действия (релиз, фича, отправка писем) и контур переваривания (аудит, разбор инцидентов, ответственность). На этом уровне работает системный предохранитель: если вы включили автодействие (контур действия), но не обеспечили процедуру отката и логирования (контур переваривания), система обязана вернуть решение обратно в ремонт на L4. Нельзя жить только релизом, легальность — это способность системы переварить собственную ошибку.
И наконец, L7. Это не просто «накидывание новых состояний», это векторная проверка по 12 каналам. Один и тот же кейс прогоняется через фильтры импульса, уязвимости, права, порядка, стратегии и так далее. В нашем примере каналы порядка будут блокировать решение, требуя регламента, а каналы стратегии — предлагать конструктивные выходы. На этом уровне кейс превращается из плоского вердикта в объёмную карту напряжений.
Сейчас я даю это обзорно, чтобы сложилась картинка иерархии. А вот саму карту 108 состояний, полные таблицы фаз и то, как именно эти каналы математически собираются в единую структуру — это тема для следующих статей, где я раскрою карты детально.
Дополнение.
1) Автоморфизм — это не “любая перестановка”, а симметрия конкретной операции.
Пусть операция задана таблицей op: P x P -> P. Тогда
σ — автоморфизм (симметрия таблицы) тогда и только тогда, когда для любых a,b выполняется:
σ(op(a,b)) = op(σ(a), σ(b)).
Это не риторика и не “умный термин”, это определение.
2) Где именно это используется (и почему это не “просто перебор орбиты”)?
Если σ — автоморфизм операции, то он даёт эквивариантность шага динамики. Для стандартного шага вида
step(x1,...,xm) = (op(x1,x2), op(x2,x3), ..., op(xm,x1))
выполняется тождество:
step(σ^m(state)) = σ^m(step(state)),
где σ^m действует покомпонентно. Отсюда следуют уже содержательные вещи: сохранение типов аттракторов (фикс/цикл), перенос свидетелей между представителями орбиты, факторизация пространства поисков по классам эквивалентности. Это и есть причина, почему в проекте вообще появляется Aut(op).
За пределами LLM: детерминированный движок рассуждения на конечном алфавите