Комментарии 24
Какая llm у него внутри (или вы обучаете с нуля?)
Ваша система будет иметь бесплатный вариант?
LLM в этой архитектуре — это сменный языковой фронтенд, а не само ядро системы. Она может помогать разобрать естественный язык, сформулировать ответ или предложить candidate-parse, но защищённая часть HTCE живёт отдельно: Core, AIR, evidence memory, replay, risk-tiered режимы, witness boundary, DiscrepancyRecord, запрет на прямую L2/L3 truth и т.д.
То есть схема такая:
LLM proposes HTCE verifies / rejects / quarantines / answers
Сейчас архитектура специально сделана так, чтобы можно было подключать разные модели: локальные через LM Studio/Ollama-подобный слой, OpenAI-compatible API или вообще работать в ограниченном deterministic-режиме без LLM для простых сценариев. Ядро не должно зависеть от конкретной LLM, иначе вся идея доказательного runtime ломается.
С нуля обучать большую языковую модель сейчас не является главной целью. Главная цель — построить когнитивное ядро, которое умеет управлять знанием: отличать факт от гипотезы, видеть конфликт, проверять внешние solver-вердикты, не принимать SMT/PDDL/VAL как истину напрямую и сохранять проверяемый trace.
По бесплатному варианту: да, я хочу оставить исследовательский/Community-вариант, чтобы систему можно было запускать, изучать и проверять. Коммерческая часть, если она появится, скорее будет вокруг интеграций, поддержки, enterprise-развёртывания, интерфейсов и специализированных модулей. Сам базовый исследовательский контур я бы хотел сохранить доступным.
Есть ли чтонибудь что помешает llm сгаллюцинировать или наврать, когда оно отвечает, само себе, на вопросы - откуда взялся факт, есть ли конфликт итд
P.S. "это не текст на экране, а смысл заданный интеллектом..".. ну ё маё, сколько можно подобные обороты от нейронки в тексте оставлять, мне глаза режет, а вам нет?
LLM может сгаллюцинировать не только сам факт, но и “обоснование” факта. Она может красиво придумать источник, уверенно сказать “конфликта нет”, неправильно интерпретировать внешний контекст или сгладить противоречие. Поэтому в HTCE принцип совершенно другой, да и строилась она для других целей.
А что в htce выступает арбитррм который "понимает" что обоснование фактов настоящее правдивое?
Хороший вопрос! Спасибо) Здесь важно не ввести в заблуждение, что в HTCE есть некий модуль, который “понимает настоящую правду” в человеческом смысле - такого арбитра нет и не должно быть! Идея HTCE не в том, что одна LLM проверяет другую LLM, а потом “понимает”, что обоснование правдивое, это было бы слабым местом. LLM может придумать факт, придумать источник, придумать объяснение и уверенно сказать, что всё сходится. Но в HTCE арбитром должен быть не “понимающий голос”, а процедура допуска, то есть система не спрашивает: “похоже ли это на правду?” Она спрашивает другое:
есть ли источник;
зафиксирован ли он;
есть ли хэш или след содержимого;
какое именно утверждение из него извлечено;
в каком контексте оно действует;
совпадает ли область применения;
есть ли уже принятое противоречащее утверждение;
какой вес у источника;
прошло ли утверждение replay;
не пытается ли пользователь, LLM или solver выдать свидетельство за истину.
Это не философский судья истины. Это инженерный арбитр допуска. Например, если приходит утверждение “объект находится в комнате А”, оно не становится знанием только потому, что LLM сказала “источник выглядит правдоподобным”. Оно должно стать записью: источник такой-то, содержимое такое-то, утверждение такое-то, область такая-то, след такой-то, статус такой-то. Если потом приходит “тот же объект находится в комнате Б” в той же области времени и контекста, система не должна выбирать красивый ответ. Она должна увидеть конфликт и отправить его в уточнение, карантин или replay. То же самое с внешним solver-ом. Если SMT-солвер сказал sat, это не значит “истина доказана”. Это значит: “в данной формальной кодировке найдена модель”. Если PDDL-валидатор сказал PASS, это не значит “план истинный”. Это значит: “данный план прошёл данную проверку на данной формальной постановке”. Поэтому внешний solver тоже не арбитр истины - он свидетель! В текущей логике HTCE роли примерно такие:
LLM помогает с языком и кандидатным разбором;
Evidence-записи фиксируют происхождение и содержимое;
Claim-записи хранят утверждения, поддержку, противоречия и статус;
Replay проверяет, выдерживает ли кандидат внутреннюю процедуру;
Discrepancy-записи фиксируют расхождение между внутренним состоянием и внешним witness;
Quarantine не даёт сомнительному утверждению попасть в активную память;
Core не принимает прямую запись истины от LLM, пользователя или solver-а.
То есть “арбитр” — это не один разумный модуль, а связка правил допуска, журналов, хэшей, replay и границ безопасности. Важно: такая система не доказывает абсолютную правду о мире. Она делает более скромную, но инженерно полезную вещь: не даёт утверждению стать защищённым знанием без проверяемого пути допуска. Если evidence нет — статус должен быть “источник отсутствует” или “нужна проверка”. Если evidence есть, но конфликтует — карантин или уточнение. Если solver подтвердил — это внешнее свидетельство, а не истина. Если LLM уверена — это вообще не аргумент для ядра. Вот как-то так)
Ну вообще я и не думал, что это философский судья истины.
Как я понял ваш ответ, то добавлена куча перепроверок данных в контексте, и в процессе "размышления" одной нейронки, самой собой или другими нейронками
P.S. я заувалированно попросил вас не добавлять откровенно нейросетевые текста, но вы опять это сделали
Опубликовал после того как протестировал систему.
.
Уважаемый!
В академической среде ИИ (Deep Learning) HTCE — Hierarchical Temporal Convolutions for Eye Movement Analysis.
Расшифруй, пожалуйста, своё сокращение HTCE.
Отсутствие ссылок удивляет.
Спасибо за замечание, оно справедливое.
Да, HTCE не является общепринятым академическим сокращением в AI/Deep Learning. Более того, в литературе действительно встречается HTCE как Hierarchical Temporal Convolutions for Eye Movement Analysis — это отдельная CNN-архитектура для анализа eye movement / gaze time series. Моя статья не про эту работу и не использует это сокращение в том значении.
В моём случае HTCE — авторское название проекта:
Hierarchical Toroidal Cognitive Engine или по-русски: Иерархический тороидальный когнитивный движок.
Расшифровка такая:
Hierarchical — потому что система разделяет уровни наблюдений, evidence-memory, candidate cognition, replay, skill-chain и macro-skill.
Toroidal — потому что математическое ядро строится вокруг дискретного модульного / тороидального состояния.
Cognitive Engine — потому что это не одна LLM-модель, а runtime-архитектура для работы с памятью, доказательствами, внешними witness-инструментами, risk-tier режимами и safety-инвариантами.
То есть это не попытка сказать, что в академической среде уже есть общепринятый термин HTCE именно в таком смысле. Это рабочее имя моей архитектуры.
По ссылкам — замечание тоже принимаю. В статье нужно добавить отдельный блок “Источники и близкие направления”, чтобы было понятно, на какие существующие области я опираюсь:
PDDL — как язык спецификации planning-задач.
VAL / planning validators — как внешний planning witness.
SMT-LIB — как стандартный язык и benchmark-библиотека для SMT-солверов.
Z3 / cvc5 — как примеры SMT-солверов.
NIST AI RMF — как рамка trustworthy AI.
MDL / Minimum Description Length — как близкая идея для рассуждения о сжатии опыта.
Runtime shielding / safety envelopes — как близкая область для safety-boundary.
Спасибо, поправлю формулировку в статье: явно укажу, что HTCE в моём тексте — авторское сокращение, а не устоявшийся академический термин.
Есть возможность протестировать систему? В последние месяцы ронял qwen в системный отказ продолжать диалог (edge case), близко подходил к этому у claude - да и просто интересно протестировать из образа красной команды алгоритм.
Спасибо, это как раз очень правильный вопрос.
Публичного стенда для свободного red-team тестирования пока нет. Я не хочу делать вид, что система уже готова к открытому “ломайте как хотите” режиму: для этого нужен отдельный sandbox, логирование, ограничение прав, воспроизводимые сценарии, политика disclosure и понятные метрики, что именно считается успехом атаки. Так что ответ: сейчас публично протестировать пока нельзя, не совсем готов к этому, но red-team режим нужен и будет очень полезен, надеюсь в скором времени реализую и это. Как раз хочу подготовить отдельный adversarial test pack, где проверяется не “красота ответа”, а прочность границ системы.
Спасибо!
Прочитал с интересом несмотря на шаблонные обороты ИИ-писателя, которые сразу снижают уровень доверия к публикации.
Интересно было бы видеть, какие части системы используют LLM, а какие работают чисто алгоритмически.
Это дало бы хотя бы примерное понимание ресурсоемкости и тормознутости такого ядра.
Например, солверы как работают?
языковая модель должна быть только входным и выходным слоем. Она может помочь разобрать естественный язык, предложить черновой разбор запроса, переформулировать ответ для человека. Но она не должна решать, является ли факт допустимым, есть ли конфликт, можно ли записать что-то в защищённую память, можно ли принять результат решателя как истину.
что касается ресурсоёмкости, там тоже не один режим. Простые запросы должны проходить без тяжёлого решателя. Например, если факт уже принят в память и вопрос простой, это обычный поиск по принятому состоянию и выдача ответа. Здесь языковая модель может быть вообще не нужна, если вход уже нормализован. Если нужен разбор противоречий или короткая причинная цепочка, включается внутренний replay. Это дороже, но всё ещё ограниченный алгоритмический режим: пройти по сохранённым утверждениям, проверить связи, контекст и конфликт. Решатели включаются только для тяжёлых случаев. Это отдельный режим, а не постоянная часть каждого ответа.
солвер в HTCE — это не “мозг” и не “бог”, а внешний проверяющий инструмент. Он вызывается редко, по необходимости, с ограничением ресурсов. Его результат проходит через внутреннюю проверку, сравнение с evidence и обработку расхождений. Быстрые вопросы должны идти без солвера, иначе система будет непрактично медленной.
Вот это и есть то, чему могут завидовать.
Нет. Завидовать могут лишь доказаному превосходству. И какие же ваши доказательства?
Никаких.
Много англицизмов наоборот - признак плохой работы, автор пытается взять читателя наукообразностью. Либо сам плохо понимает смысл терминов и не умеет подобрать корректное название, заменяя первую пришедшую в голову мысль первым найденным в гугле англицизмом.
Ну а про недостатки LLM уже написано гигабайты текста. Про необходимость эти недостатки устранаять написано ещё больше. И предложено масса вариантов улучшения. Но ни один пока не взлетел. Автор предложил миллион первый вариант. Зная статистику остальных можно уверенно утверждать - этот тоже не взлетит.
Главное - кроме громких заявлений автору вообще нечего показать. Подсказать вам, сколько в мире таких громких авторов?
Понимаю ваш вопрос, здесь есть небольшое смешение двух разных вещей: обсуждение идеи и решение о том, как именно мне реализовывать собственный проект. Опубликовал материал, чтобы поделиться архитектурным подходом, показать что уже работает, а что требует каких-то технических решений, получить технические вопросы, рассказать о новом видении с определенного угла процесса развития искуственного интеллекта. Но выбор реализации, дальнейшего применения и формы развития системы всё же остаётся за мной, как автором проекта. На текущем этапе она реализована в той части, которая была запланирована: как исследовательское когнитивное ядро с ограниченными режимами, проверками и внутренними границами и оно работает! Если вам сама идея Вам не кажется убедительной — это нормально, развернитесь и двигайтесь к лучшим идеям, здесь простор огромен - лучше конечно своим! Можно не принимать её, спорить с архитектурой, указывать на слабые места, предлагать альтернативы. Я готов обсуждать конкретные технические вопросы: где арбитраж, где LLM, где алгоритмический допуск, где solver, где защита от галлюцинаций. Но решать, нужен ли мне этот проект, как я буду его использовать и в каком направлении развивать, — это уже моя зона ответственности.
Не понимаю в чем профит этой системы? Как я понял на каждом слое также используется какая-либо llm для проверки фактов, памяти, источников и.т.п. Так что мешает llm вытащить источник и сказать - "вот нашел источник, он праводоподобный"?
Как Вам объяснить…сформулирую ответ так, чтобы снять главное недопонимание: в HTCE не предполагается, что “на каждом слое сидит LLM”. Профит как раз в том, что часть проверок должна быть обычным кодом, журналом, хэшами, нормализованными утверждениями и внешними решателями, а не самоотчётом модели. Что одна LLM проверяет другую LLM. Что LLM вообще не получает права записывать истину. Она работает с языком, а допуск знания должен идти через журнал, источник, проверку конфликта, след, ограниченный статус и аудит.
Работаю над похожим, но менее сложным рантаймом. Забавно было увидеть похожий нейминг слоёв памяти в Вашей архитектуре. В своём проекте я сделал акцент на максимальной наблюдаемости памяти. Слой L1 вынесен в отдельную видимую панель, чтобы сразу видеть ложные срабатывания, шумные формулировки и неправильные записи.
А вот это уже интересней! Готов к диалогу)
Покажу картинку, чтобы не пересказывать всю схему.
У меня похожее направление, но проще по акценту, не доказывать истину формально, а сделать память модели видимой и проверяемой. А всё, что можно детерминировать, постепенно уезжает из промпта в рантайм, слепки, внутренние действия и состояние системы. То есть это не столько про границы истины, сколько про наблюдаемость памяти.

Если сделать по Вашему интерфейсу, моя система могла бы выглядеть так (у меня по факту немного по другому):

Да, направление очень близкое. Мне тоже кажется, что L1 нельзя прятать внутрь “магической памяти”. Если L1 невидим, потом невозможно понять, где именно появилась ошибка: на входе, при нормализации, при извлечении факта, при допуске в память или уже при ответе?

HTCE: когнитивное ядро нового поколения, которое не верит без доказательств