Третья часть серии о трёхслойном семантическом движке. Первая — «Где живёт смысл» (часть 1), вторая — «Как построить карту смысла» (часть 2).
В предыдущей части мы разобрались с семантической картой. Полюса возникают из динамики представлений, обучаются через приближённые градиенты, борются с вымиранием, разделяют потоки и в идеале дают системе устойчивые координаты, относительно которых можно работать с контекстом.
Но координаты сами по себе не являются знанием.
Карта говорит: «мы находимся в области медицины». Она не говорит: «у пациента Иванова аллергия на пенициллин, последний анализ крови был 14 марта, лечащий врач — Петрова». Это другое. Это факты. И они живут по другим правилам.
В первой статье мы сказали, что фактологию лучше вынести наружу — в отдельную структуру, которую можно редактировать, не переобучая модель. Теперь пора разобраться, что это значит на практике, почему простой граф недостаточен и как проблема противоречивых знаний превращается в проблему времени.
Почему факт не должен жить в весах
Представим, что система должна помнить дату рождения конкретного человека. В монолитной модели этот факт распределён внутри миллиардов параметров. Он не существует в одном месте — он размазан по всему пространству весов, как запах в комнате.
Это даёт огромную ёмкость. Но создаёт три проблемы.
Первая — редактирование. Если дата изменилась, нельзя просто открыть строку и исправить. Нужно либо переобучать модель, либо использовать сложные механизмы точечного вмешательства, которые плохо масштабируются и непредсказуемо влияют на соседние знания.
Вторая — проверяемость. Нельзя спросить модель: «откуда ты знаешь эту дату?» Она не покажет источник. Она выдаст ответ с некоторой уверенностью, но происхождение этого ответа скрыто внутри вычислительной динамики.
Третья — конфликт. Если модель одновременно встречает два противоречивых факта, она не может явно сказать: «здесь противоречие». Она усреднит, забудет одно, или начнёт выдавать разные ответы в зависимости от контекста. Ни один из этих исходов не является корректным.
Поэтому Layer 3 предлагает другой принцип. Факт существует явно. Как узел графа. Со свойствами, связями, источником и состоянием.
Граф как память
Вместо «модель где-то внутри знает» появляется:
Пациент: Иванов
├── аллергия → пенициллин
├── последний анализ → 2026-03-14
├── лечащий врач → Петрова
│ │
│ └── специализация → кардиология
└── диагноз → гипертония
│
└── подтверждён → 2025-11-02
Это принципиально другой способ обращения со знанием. Если Иванов сменил врача — меняется одна связь. Если анализ устарел — обновляется дата. Если диагноз снят — связь удаляется или помечается как неактуальная. Никакого переобучения.
И здесь появляется важное свойство, которого нет у параметрической памяти: разделение структуры вычисления и содержимого знания. Модель не меняется, когда меняется факт. Семантическая карта не перестраивается, когда пользователь добавляет новую запись. Вычислительный механизм стабилен. Данные — нет.
Это и есть та граница, о которой мы говорили в конце второй статьи. Структура меняется медленно. Содержание — быстро. Архитектура должна проводить эту границу автоматически.
Но процессор не любит графы
На бумаге всё выглядит аккуратно. Узлы, связи, обход. На практике возникает физическая проблема.
Процессор оптимизирован для последовательного чтения: прочитал адрес, перешёл к следующему, затем к следующему. Это то, для чего спроектированы кэш, конвейер и векторные инструкции.
Граф говорит другое. Взяли вершину. Посмотрели соседей. Перешли по адресу. Посмотрели следующих. Прыгнули в совершенно другое место памяти. Каждый переход — потенциальный промах кэша, простой конвейера, потерянное время.
Наивная реализация графового обхода на потребительском процессоре может потерять до 90% производительности просто из-за хаотичности доступа. Это не теоретическая оценка — это то, что наблюдается в реальных графовых базах данных при работе с большими разреженными структурами.
Решения известны и частично применяются в существующих системах. Плотная упаковка соседей в последовательные массивы, чтобы обход стал линейным чтением. Разбиение графа на локальные блоки, помещающиеся в кэш. Предварительная подгрузка данных до того, как они понадобятся. Пакетная обработка нескольких запросов одновременно через векторные инструкции.
Каждый из приёмов решает часть проблемы. Ни один не решает её полностью. Их комбинация может дать ускорение в 5–10 раз по сравнению с наивным обходом, но конкретный выигрыш зависит от структуры графа, размера рабочего набора и конкретного процессора. Это территория бенчмарков, не теоретических рассуждений.
Для этой статьи достаточно понять принцип: архитектурное решение порождает физическую проблему, и физическая проблема не решается на уровне математической модели. В какой-то момент математика упирается в кэш-линии и пропускную способность шины.
Парадокс редактируемости
Но здесь возникает противоречие, которое легко пропустить.
Все оптимизации, о которых мы только что говорили, предполагают, что граф стабилен. Плотные массивы скомпилированы. Блоки разрезаны. Кэш прогрет. Система готова к быстрому обходу.
А теперь пользователь добавляет факт.
Если каждая запись требует перестроения всей структуры, производительность разрушается. Перестройка графа на миллионы вершин занимает секунды или минуты. Для интерактивной сессии это неприемлемо.
Но если не перестраивать — новый факт лежит где-то отдельно, не оптимизирован, не упакован, и обход к нему будет медленным.
Это и есть парадокс редактируемости: система должна быть одновременно стабильной для быстрого чтения и живой для быстрой записи.
Решение — разделить граф на два уровня. Фундамент — стабильная, оптимизированная структура, которая не меняется в процессе работы. И поверх неё — буфер изменений: компактный слой для новых и изменённых связей, оптимизированный под быструю запись.
При обходе система сначала проверяет буфер, затем фундамент. Большинство запросов попадают в фундамент и получают полную скорость. Новые связи обходятся чуть медленнее, но это приемлемо. Фоновый процесс периодически сливает буфер в фундамент, переоптимизирует его и атомарно подменяет старую версию. Пользователь видит мгновенный отклик. Полная оптимизация происходит незаметно.
Это не новая идея. Современные базы данных работают по тому же принципу: быстрый журнал записей поверх оптимизированного хранилища. Проверенный паттерн, не эксперимент.
Но граф хранит факты, а не знания о фактах
И вот здесь начинается самое интересное.
Представим, что в графе есть запись:
Компания X → CEO → Иван Петров
Это факт. Но достаточно ли его?
Что если Иван Петров перестал быть CEO три месяца назад, но запись не обновлена? Что если источник этой информации — новостная статья с ошибкой? Что если в другой ветке графа есть другая запись:
Компания X → CEO → Мария Иванова
Теперь у нас два противоречивых утверждения в одной памяти. Система должна что-то с ними делать. Но что?
Простой граф не даёт ответа. Он хранит связи. Но он не хранит отношение системы к этим связям. Не хранит источник, время, степень доверия, область применимости.
Это значит, что граф сам по себе — ещё не память. Это скелет памяти. А живая память требует метаданных.
Память должна знать, когда она узнала
Попробуем представить, что нужно добавить к каждому факту, чтобы система могла работать с противоречиями осмысленно.
Факт: Компания X → CEO → Иван Петров ├── источник: годовая отчётность, 2024 ├── достоверность: высокая ├── актуальность: до подтверждения изменения └── конфликтует с: [запись 2] Факт: Компания X → CEO → Мария Иванова ├── источник: пресс-релиз, март 2026 ├── достоверность: средняя (не подтверждено независимо) ├── актуальность: текущая └── конфликтует с: [запись 1]
Теперь система может рассуждать. Запись 2 новее. Запись 1 подтверждена, но устарела. Запись 2 свежее, но не подтверждена независимо. В зависимости от задачи система может выбрать одну, другую, или эскалировать: «есть противоречие, источник не подтверждён, требуется уточнение».
Это уже не просто граф. Это граф с временной координатой, источником и степенью доверия. И это принципиально меняет природу Layer 3.
Из хранилища фактов он превращается в систему управления знаниями, где каждый элемент имеет историю, контекст и статус.
Противоречие — это не ошибка
Здесь важно остановиться и сказать одну вещь явно.
В обычной базе данных противоречие — это ошибка. Два несовместимых значения в одном поле означают, что данные повреждены. Их нужно исправить.
В системе, работающей с реальным миром, противоречие — это нормальное состояние. Информация приходит из разных источников, в разное время, с разной достоверностью. Факты устаревают. Мнения расходятся. Контекст меняется.
Если архитектура не способна хранить противоречие явно, она будет вынуждена либо молча выбирать одну версию (теряя информацию), либо усреднять (производя бессмыслицу), либо игнорировать новую информацию (застревая в прошлом). Ни один из этих вариантов не является корректным.
Поэтому Layer 3 должен быть способен хранить несколько версий одного факта одновременно, с явным указанием их статуса. И задача системы — не устранить противоречие, а представить его в таком виде, чтобы вышестоящий слой мог принять решение.
Это напрямую связано с механизмом эскалации, о котором мы говорили в контексте этических полюсов. Когда Layer 3 обнаруживает неразрешимое противоречие, он не пытается разрешить его сам. Он формирует запрос к Layer 2 или к внешнему оператору: «здесь конфликт, вот источники, вот временные метки, вот степени доверия — что делать?»
Система не принимает решение за человека. Она делает противоречие видимым.
Время как четвёртое измерение памяти
Если посмотреть на всё это целиком, обнаруживается, что память в такой архитектуре имеет не три измерения (сущность, свойство, связь), а четыре. Четвёртое — время.
Каждый факт существует не просто как связь, а как связь в момент. Она была верна тогда. Она может быть верна сейчас. Она может быть верна до некоторого события. Она может быть верна только в определённом контексте.
Это меняет природу обхода графа. Система не просто ищет связь. Она ищет связь, актуальную для данного момента и данного контекста. Если связь устарела, она не удаляется — она помечается. Потому что устаревший факт может быть нужен для восстановления истории, для объяснения, для аудита.
И здесь появляется ещё одна связь с Layer 1. Семантическая карта хранит устойчивые координаты: что такое «компания», что такое «CEO», что такое «назначение». Эти координаты меняются медленно. Граф хранит конкретные назначения конкретных людей. Эти записи меняются быстро.
Структура и содержание. Медленное и быстрое. Устойчивое и преходящее. Граница между ними — это и есть граница между Layer 1 и Layer 3. И архитектура должна проводить её не вручную, а автоматически, через разную скорость обновления.
Что происходит, когда граф противоречит карте
Вернёмся к вопросу, которым закончилась вторая статья. Семантический слой говорит: X является частью Y. Графовая память содержит: X не является частью Y. Что побеждает?
Теперь мы можем ответить более конкретно.
Семантическая карта не хранит фактов. Она хранит тип отношения. «Является частью» — это координата. Конкретное утверждение «X является частью Y» — это запись в графе. Если граф говорит, что X больше не является частью Y, это не противоречит карте. Карта по-прежнему знает, что такое «часть» и что такое «целое». Изменился конкретный факт, не структура.
Настоящее противоречие возникает тогда, когда граф содержит запись, которая нарушает инвариант, заданный картой. Например, карта содержит полюс «организация не может быть собственным учредителем», а граф содержит петлю: X → учредитель → X. Это не просто противоречивый факт. Это нарушение структурного ограничения.
В таком случае Layer 3 не может разрешить конфликт самостоятельно. Он эскалирует. И это правильно. Потому что разрешение структурных противоречий — это не задача памяти. Это задача того, кто определяет правила.
Три слоя как три режима времени
Если собрать всё вместе, получается любопытная картина. Три слоя работают в разных временных масштабах.
Layer 1 меняется крайне медленно. Семантические полюса — это координаты, которые формируются в процессе обучения и затем сохраняют устойчивость. Они могут адаптироваться, но не реагируют на каждый запрос. Это геологическое время системы.
Layer 2 живёт в масштабе текущего контекста. Каждый запрос разворачивает новое локальное пространство, обрабатывает его и передаёт дальше. Это время разговора, время сессии.
Layer 3 занимает промежуточное положение. Он меняется быстрее, чем Layer 1, но медленнее, чем Layer 2. Факты добавляются, обновляются, устаревают. Но структура графа, его онтология, его правила целостности — относительно стабильны.
Три режима времени. Три типа изменений. Три разных механизма обновления. И три разных ответа на вопрос: «что делать, когда что-то меняется?»
На Layer 1: почти ничего. Координаты сохраняются.
На Layer 2: каждый раз заново. Контекст формируется под запрос.
На Layer 3: точечно. Конкретная связь обновляется, остальное не трогается.
Это не просто инженерное разделение. Это отражение того, как устроено любое знание. Есть то, что меняется раз в поколение. Есть то, что меняется каждый день. И есть то, что меняется прямо сейчас, в момент разговора. Система, которая пытается хранить всё это в одном режиме, неизбежно путает скорости.
Что мы доказали и чего не доказали
На этом месте стоит остановиться и быть честными.
Мы не доказали, что графовая память работает лучше параметрической для всех задач. Для некоторых задач распределённое представление внутри весов может быть эффективнее — особенно когда факты тесно переплетены и не имеют чёткой структуры.
Мы не доказали, что метаданные (источник, время, доверие) можно автоматически извлекать и поддерживать в актуальном состоянии. Это отдельная сложная задача, и она не решается одной архитектурной схемой.
Мы не доказали, что система эскалации при противоречиях не приведёт к постоянным ложным тревогам. Если граф содержит тысячи мелких несогласованностей, система может эскалировать на каждом шагу, становясь практически бесполезной.
Мы не доказали, что разделение на фундамент и буфер изменений не создаст задержек, неприемлемых для интерактивных задач.
Всё это — экспериментальные вопросы. Каждый из них требует бенчмарка, baseline и критерия провала. Архитектура предлагает направление. Эксперимент покажет, верное ли оно.
Но мы сделали кое-что другое. Мы превратили расплывчатый вопрос «как машина должна помнить?» в набор конкретных инженерных задач. Как хранить. Как редактировать. Как обходить. Как разрешать противоречия. Как управлять временем. Как отделять структуру от содержания.
Это уже не философия памяти. Это спецификация.
Что остаётся за пределами архитектуры
Три статьи этой серии прошли один путь.
Первая поставила вопрос: где живёт смысл, если модель работает с последовательностью токенов? И предложила ответ: возможно, смысл нуждается в отдельном слое устойчивых координат.
Вторая разобрала, как эти координаты могут возникать, обучаться, выживать и не превращаться в декорацию. И показала, что каждый ответ порождает новую проблему: дискретный выбор ломает градиент, мёртвые полюса опустошают карту, разделение потоков создаёт конфликты на границе.
Третья показала, что координаты — не знание. Знание живёт в графе, и граф должен уметь хранить не только факты, но и отношение к фактам: время, источник, доверие, противоречие. И что проблема противоречивых знаний в конечном счёте превращается в проблему времени — в вопрос о том, когда факт был верен, откуда он пришёл и до какого момента остаётся актуальным.
Но за всеми этими слоями остаётся вопрос, который ни одна архитектура не закрывает.
Кто решает, какие координаты правильные? Кто определяет, что является допустимым ограничением, а что — цензурой? Кто несёт ответственность, когда система эскалирует и человек принимает неверное решение? Кто обновляет граф, когда мир меняется быстрее, чем система успевает фиксировать?
Архитектура может сделать эти вопросы видимыми. Может создать место, где они формулируются. Может разделить ответственность между слоями так, что ни один слой не принимает решений, которые должен принимать человек.
Но она не может ответить на них вместо человека.
И, возможно, это и есть главное свойство всей конструкции. Не то, что она решает проблему смысла. А то, что она не позволяет системе решить её за нас.
Вместо заключения
Когда мы начинали, вопрос звучал так: где живёт смысл?
Теперь мы можем ответить чуть точнее. Смысл не живёт в одном месте. Он распределён по трём режимам.
Устойчивые координаты — в Layer 1. Они меняются медленно и задают систему отсчёта.
Живой контекст — в Layer 2. Он формируется каждый раз заново и не претендует на вечность.
Изменяемое знание — в Layer 3. Оно хранит факты, их источники, их время и их противоречия.
Ни один из этих слоёв не является «пониманием». Но вместе они создают структуру, в которой понимание может быть не просто вероятностным паттерном, а явным, проверяемым и редактируемым объектом.
Или не могут. Это покажет эксперимент.
Но даже если архитектура не подтвердится в заявленной форме, сам вопрос останется. Потому что по мере того, как модели становятся больше, контексты длиннее, а задачи сложнее, вопрос «где живёт смысл и кто им управляет» будет возникать снова и снова. Не как философская абстракция. Как инженерная задача.
И тогда придётся отвечать. Не на вопрос «понимает ли машина». А на вопрос: какую структуру она строит, кто может её изменить и что происходит, когда она ошибается.
Это уже не вопрос о машине.
Это вопрос о том, какую форму мы хотим сохранить для себя.