惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

J
Java Code Geeks
腾讯CDC
Jina AI
Jina AI
博客园 - 司徒正美
博客园 - 三生石上(FineUI控件)
Apple Machine Learning Research
Apple Machine Learning Research
GbyAI
GbyAI
WordPress大学
WordPress大学
Hugging Face - Blog
Hugging Face - Blog
T
The Blog of Author Tim Ferriss
小众软件
小众软件
M
MIT News - Artificial intelligence
MyScale Blog
MyScale Blog
D
Docker
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Google DeepMind News
Google DeepMind News
月光博客
月光博客
L
LangChain Blog
F
Fortinet All Blogs
Microsoft Azure Blog
Microsoft Azure Blog
博客园 - Franky
C
Check Point Blog
U
Unit 42
人人都是产品经理
人人都是产品经理

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
За пределами LLM, часть 2: якорная таблица Кэли, которая ...
Руслан · 2026-05-26 · via Все публикации подряд на Хабре

Средний

4 мин

12K

В первой статье я высказал простую идею: если вычисление можно свести к конечной таблице операции, его можно проверять, а не угадывать. То есть его можно свести не к "модель выдала вероятность 0,67", а просто открыть таблицу и сказать: вот ячейка, вот результат, rc=0.

Эта статья — прямое продолжение первой статьи. Сейчас у меня на руках значительно отличающаяся рабочая модель ИИ-движка. Но сразу честно: я не собираюсь раскрывать здесь внутреннюю кухню "GALO AI". Ни устройство нейрона, ни приватные маршруты мышления. Покажу только основополагающую математику: маленькую конечную структуру, которую можно взять руками, прогнать скриптом и попытаться сломать контрпримером.

Ключевая идея проста до невозможности: я взял обычное сложение по модулю и изменил в его таблице ровно одну строку.

Этого хватило, чтобы структура перестала быть полем, кольцом и моноидом.

1. Таблицы Кэли циклической группы

Когда говорят про математику для ИИ, на ум сразу приходят векторы, вероятности, градиенты и огромные обучаемые веса. Я пошел другим путем.

Я взял нетривиальную, но понятную конечную конструкцию — таблицу Кэли циклической группы — и спросил себя: что будет, если в ней испортить ровно одну строку?

Не наколдовать. Не ввести стохастику. Не спрятать поведение в вещественных весах.

Просто переписать одну строку.

Получилась операция, которую я называю якорной таблицей STAR.

2. PLUS и STAR

Носитель простой:

Q_n = {P0, P1, ..., P(n-1)}

Первая операция — PLUS — обычное сложение по модулю n:

PLUS(P_i, P_j) = P((i + j) mod n)

Вторая операция — STAR — почти копия PLUS, но с якорем P0.

Первое правило: если P0 стоит слева, он всё поглощает:

STAR(P0, x) = P0

Второе правило: если P0 стоит справа, он ничего не меняет:

STAR(x, P0) = x

Третье правило: если оба индекса ненулевые, STAR совпадает с PLUS:

STAR(P_i, P_j) = PLUS(P_i, P_j), если i != 0 и j != 0

То есть:

  • P0 слева работает как поглотитель;

  • P0 справа работает как нейтральный элемент;

  • все ненулевые пары работают так же, как PLUS.

Этого достаточно, чтобы обычная симметричная картина сломалась.

3. Пример на L3

Возьмем нетривиальный пример:

n = 3

Q_3 = {P0, P1, P2}

Таблица PLUS:

PLUS_L3

P0

P1

P2

P0

P0

P1

P2

P1

P1

P2

P0

P2

P2

P0

P1

Теперь таблица STAR:

STAR_L3

P0

P1

P2

P0

P0

P0

P0

P1

P1

P2

P0

P2

P2

P0

P1

Строки P1 и P2 остались прежними. Они совпадают с PLUS. Изменилась только строка P0.

Именно эта строка все меняет.

4. Почему STAR — не умножение поля

Типовая ошибка — думать, что STAR это «какое-то хитрое умножение».

Нет.

В поле умножение на ноль всегда дает ноль:

P1 * P0 = P0

У меня:

STAR(P1, P0) = P1

Одна ячейка — и claim "это поле" падает.

Это не мелочь и не технический нюанс. Это разделитель. STAR не пытается быть полевым умножением. У него другая роль: он сохраняет профиль PLUS почти везде, но вводит якорную асимметрию через P0.

5. Почему STAR — не моноид

Моноид требует ассоциативности. Но уже на L3 она ломается без длинного доказательства.

Считаем левую расстановку скобок:

(STAR(P1, P0)) STAR P1

Сначала:

STAR(P1, P0) = P1

Затем:

STAR(P1, P1) = P2

Итого:

(STAR(P1, P0)) STAR P1 = P2

Теперь правая расстановка:

P1 STAR (STAR(P0, P1))

Сначала:

STAR(P0, P1) = P0

Затем:

STAR(P1, P0) = P1

Итого:

P1 STAR (STAR(P0, P1)) = P1

Получили:

P2 != P1

Ассоциативность нарушена.

(STAR(P1, P0)) STAR P1 != P1 STAR (STAR(P0, P1))

Поэтому я сознательно не называю это "STAR-моноидом". Звучит красиво, но математически неверно.

По той же причине эта структура не становится кольцом в обычном смысле: для кольца вторая операция должна вести себя как ассоциативное умножение. Здесь этого нет.

6. Почему одна строка так важна

Изменение минимальное, эффект сильный.

Почти вся таблица наследует PLUS. Новое поведение сосредоточено в одной якорной строке.

Это даёт три инженерных плюса:

  • проверка локальна: можно указать конкретную ячейку;

  • контрпример точен: можно назвать конкретные элементы;

  • поведение полностью воспроизводимо: rc=0 или rc=1, без "в среднем".

Здесь нет "модель решила". Есть только:

expected = … got = … where = … counterexample = … rc = …

Для меня это важная часть всей идеи: вычисление должно быть не впечатлением, а проверяемым объектом.

7. Связь с GALO AI

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

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

Это математический фундамент. Его можно проверить независимо от моих слов, моей мотивации и моих дальнейших планов.

8. Что лежит в архиве

К статье прилагаю архив GALO_HABR_1.zip.

В нём:

  • таблицы PLUS/STAR для L1...L7;

  • ручные примеры и контрпримеры;

  • скрипт самопроверки;

  • короткие задания для тех, кто хочет проверить конструкцию.

Запуск:

python3 -B galo_habr.py selfcheck
python3 -B galo_habr.py route article
python3 -B galo_habr.py route math`

Ожидаемый результат:

status = PASS

rc = 0

Если что-то не проходит, нужен конкретный контрпример.

9. Минимальный набор формул

Весь математический фундамент помещается в несколько строк:

Q_n = {P0, P1, ..., P(n-1)}
PLUS_n(P_i, P_j) = P((i+j) mod n)
STAR_n(P0, x) = P0
STAR_n(x, P0) = x
STAR_n(P_i, P_j) = PLUS_n(P_i, P_j), если i != 0 и j != 0

В табличном виде:

Объект

Правило

Носитель

Q_n = {P0, P1, ..., P(n-1)}

PLUS

PLUS_n(P_i, P_j) = P((i+j) mod n)

STAR, якорь слева

STAR_n(P0, x) = P0

STAR, якорь справа

STAR_n(x, P0) = x

STAR вне якоря

STAR_n(P_i, P_j) = PLUS_n(P_i, P_j), если i != 0 и j != 0

Дальше эти строки разворачиваются в полные таблицы. А таблицы уже можно проверить исчерпывающе.

10. Кого я ищу

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

Если вы:

  • искренне любите алгебру и формальную верификацию;

  • цените предельно строгую логику;

  • по-настоящему интересуетесь не очередной статистической моделью, а системой, где все проверяемо.

Тогда этот архив для вас.

Первая задача простая:

  1. Возьмите L3 и вручную проверьте нарушение ассоциативности.

  2. Возьмите L5 и найдите разделитель, показывающий, что STAR не является полевым умножением.

  3. Запустите selfcheck.

  4. Сравните ручной результат со скриптом.

Если найдёте ошибку — пишите не "мне кажется", а в таком формате:

check_id =

expected =

got =

where =

counterexample =

minimal_fix =

Вот такой разговор мне действительно интересен.

11. Заключение

Это не заявление о готовом ИИ.

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

Архитектура архива простая:

  • таблицы;

  • формулы;

  • контрпримеры;

  • selfcheck;

  • rc = 0.

Хотите проверить — архив открыт.

Хотите спорить — буду рад любой критике!

P.S.

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

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