Обновить

За пределами LLM: детерминированный движок рассуждения на конечном алфавите

Уровень сложностиСредний
Время на прочтение13 мин
Охват и читатели7.1K
Всего голосов 3: ↑1 и ↓2-1
Комментарии7

Комментарии 7

Попытался въехать, но своим недалёким умом так и не понял: как это можно использовать на практике в связке с LLM. Объясните, пожалуйста.

У меня при чтении этой статьи сложилось впечатление, что этот "Решатель" - что-то вроде "Корчевателя".

Если совсем просто: LLM — это "мягкий" интерфейс (Soft), а движок — "жесткое" ядро (Hard). LLM может сочинять, но не умеет гарантировать. Движок не умеет сочинять, но гарантирует результат.

Кроме того, в статье я больше по верхам прошелся (L3/L4), но сейчас ядро уже работает с более сложными логиками, например, в L7-режиме. Там алгоритмически выделяется до 108 вычислимых состояний. Если такую стейт-машину попробовать запихнуть в системный промпт LLM, она поплывет моментально, контекста не хватит удержать правила.

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

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

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

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

Смотри, фишка тут в разделении ответственности. LLM круто работает как интерфейс (понимает естественный язык) и генератор идей, но она плывет, когда нужна строгая логика или гарантии. Табличное ядро эту строгость возвращает. На практике схем обычно три:

  1. LLM как переводчик в канон. Пользователь пишет проблему текстом, LLM перегоняет это в JSON-структуру (эпизод). Движок этот JSON прогоняет через таблицу и выдает строгий результат (или ошибку). А LLM потом просто пересказывает этот технический отчет на человеческий язык. В итоге — пользователю удобно, а под капотом математика, которая не придумывает отсебятину.

  2. Фильтрация галлюцинаций (самое полезное). Допустим, нужно построить план действий. LLM предлагает 5 вариантов. С виду все ок, но по факту два из них нарушают бизнес-логику (нельзя, например, перейти из статуса А в Б без визы). Движок проверяет каждый вариант. Те, что дали FAIL — выкидываем. Пользователю отдаем только верифицированные сценарии. Превращаем «похоже на правду» в «гарантированно работает».

  3. Работа со сложными стейт-машинами. Этот движок сейчас у меня работает не только с 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.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации