Графы, онтологии и источники истины

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

Структура вместо токенов: графы, онтологии и источники истины

Контекст приходит формами

Zach Blumenfeld из Neo4j в докладе «AI on Your Lakehouse» формулирует тезис, который стоит выписать отдельно: контекст приходит формами (shapes). Вместо «дадим агенту text-to-SQL и vector search» ему дают три готовые формы представления данных: connections — граф-семантический слой поверх warehouse, объясняющий, как джойнить таблицы; table of contents — дерево документов со ссылками для навигации; themes — кластеры документов, вскрывающие глобальные паттерны. Каждая форма — отдельный скрипт-инструмент внутри одного skill.

Ключевое инженерное решение там же: в граф уезжают только метаданные. Проект Neo Carta (Neo4j Labs) поднимает MCP-сервер, который тянет из BigQuery схему и строит граф database → schema → HAS_TABLE → table → column, опционально с репрезентативными значениями и явными join-путями (источник — information_schema, но можно кормить query logs или задавать джойны руками). В демо это 6 таблиц и 5 reference join paths, загрузка идемпотентна. Агент читает граф и пишет корректный text-to-SQL. ETL самих данных не происходит.

Причин отказа от ETL Blumenfeld называет три, и третья интереснее первых двух. Объём — терабайты, непрерывно обновляемые, придётся строить синхронизацию. Кастомность — часть свойств в граф не нужна, часть нужна иначе. И security posture: данные физически перенести можно, но по требованиям безопасности запрещено — обычная ситуация в регулируемом контуре, отсекающая целый класс архитектур ещё до обсуждения качества. ETL, по его словам, оправдан только когда нужны сами графовые вычисления: рекурсивные джоины с требованием по латентности, graph embeddings, кластеризация.

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

A/B на одних данных: вектора против графа

Stephen Chin (Neo4j) в докладе «CrabRAG» показал сравнение, которое редко делают честно: из одних и тех же markdown-файлов построены два хранилища — векторное (PGVector или LanceDB) и графовое (Cognee поверх Neo4j). Графовый поиск гибридный: вектора дают seed-ноды, дальше обход на один хоп и ранжирование по связности, в контекст попадает только выигравшее подмножество.

Метрик он не привёл — сравнение качественное, на двух вопросах. «Что на WAN с EOL-софтом»: векторный ответ — «не удалось найти конкретики, уточните»; графовый — конкретное имя хоста и устаревшая версия ОС. «Какие management-порты слушают на 0.0.0.0»: векторный — «сходи проверь конфигурацию сам»; графовый нашёл HAProxy и OpenVPN, пройдя от ноды роутера pfSense по связям. Демо на трёх-четырёх машинах домашней лаборатории, а заявка — на дата-центры и финансовые данные. Разрыв в масштабе оценивай сам.

Его же аргумент про стоимость файловой памяти: в типовой раскладке (AGENTS.md, файлы памяти, файлы инструментов, дневные файлы) всё это просто markdown — читаемо, легко компактится руками, но агенты грузят «всё подряд в надежде, что что-то пригодится», очень репетитивно. Его замер: «мои агенты грузят как минимум 100k токенов на каждый раунд». Это оценка практика без методологии измерения, бери её как порядок величины. Важнее порог: на малом масштабе с сильной моделью markdown работает, а «когда объём не влезает в миллионное окно современных моделей, markdown-файлов уже недостаточно». Ниже этого порога структура не окупается — честная граница в обе стороны.

Отдельное свойство графа, которое обычно недооценивают: он объясним и аудируем. Видно возвращённый подграф и то, какая его часть дала ответ. Если ответ неверен, ты чинишь extraction или схлопываешь дубликаты нод вместо того, чтобы крутить промпт. Для регулируемых доменов это сильнее любого прироста качества.

Единственная проверяемая цифра

Самое ценное измерение приводит Nyah Macklin (Neo4j), ссылаясь на работу Jiang et al. по модели ComGPT для телекома (IEEE Communications Magazine, март 2026). Ablation на QA по стандартам 3GPP: базовая модель — 37%, дообучение на доменных данных — 54%, связка knowledge graph и RAG вместе — 91% точности.

Читать это надо аккуратно. Разрыв закрыло сочетание графа и RAG, каждый по отдельности работал заметно хуже. Домен узкий (телеком-стандарты), и сама спикер настаивает читать первоисточник, а не верить цифре на слайде. Но это единственная воспроизводимая цифра в пользу графового слоя, и она измерена на ablation, а не на демо.

Онтология как рабочий инструмент

Слово «онтология» отпугивает, и зря — вопрос в масштабе. Ian Gotts (San Francisco Architect Community Group) даёт ориентиры: чтобы описать организацию и культуру — слой, который он считает самым важным и наименее оцифрованным, — нужно примерно 10 узлов и 20 рёбер. Полная карта всех слоёв контекста — 80–100 узлов и около 200 рёбер. Стартовая онтология измеряется десятками узлов, а не тысячами, и подъёмна для маленькой команды за один заход.

Реплика из зала на том же обсуждении бьёт не слабее: «мир картировать нельзя, всё устаревает в момент фиксации». Ответ — целиться в «достаточно хорошо»: покрыть те сущности, о которых агент реально ошибается, и расширять по фактическим сбоям.

Второй способ не строить лишнего — не изобретать с нуля. Frank Coyle (UC Berkeley) напоминает, что за последние 15–20 лет наработаны готовые словари: schema.org, FOAF для соцсвязей, Dublin Core для публикаций. Wikipedia стоит на DBpedia. Способов построить собственную два: top-down (эксперты описывают домен) и bottom-up (вытягивать сущности и связи из реальных взаимодействий). Он же называет историческую границу прямо: экспертные системы 80-х не масштабировались, и это привело к AI winter. Нынешняя связка вероятностной модели и символьного слоя — попытка обойти ту же стену с другой стороны.

У онтологии есть и вторая роль — валидатор на выходе агентного цикла. Coyle вставляет в цикл, где модель вызывает инструмент при stop_reason == tool_use, шаг, на котором результат приводится к форме, понятной ризонеру поверх доменной онтологии: если результат разумный, цикл идёт дальше, если нет — результат возвращается в LLM или зовут человека. Его формула: «Pydantic на входе, онтология на леджере», и агенты по возможности без side effects — сначала прогнать через онтологию, потом менять состояние в БД. Ловятся вещи, которые тяжело поймать текстовыми правилами: повторный refund по тому же заказу; выплата на support desk вместо покупателя (через OWL disjoint — customer и support rep непересекающиеся классы); выдуманный статус «probably shipped» при перечислении допустимых paid, shipped и refunded. Реализуемо и в маленькой системе, если домен формализуем.

Иерархия источников истины

Ishita Daga, ML-инженер Tesla, в докладе «Enterprise Agents Have a Structure Problem» настаивает: агент не должен взвешивать все базы знаний одинаково. Источники истины ранжируются от самого чистого и наименее гибкого к самому грязному и гибкому:

1. semantic layer — курируемые определения KPI, метрик и бизнес-терминов;
2. canonical queries, они же parametric, — набор готовых запросов, агент выбирает и докручивает фильтры;
3. database graph — таблицы, связанные с колонками и метриками; максимальная гибкость.

Отвечать надо начиная с чистейшего. Её цифра: первые два слоя закрывают примерно 80% задач, граф — оставшиеся 20. При этом database graph она называет «самым хитрым»: дорого строить, тяжело поддерживать — и рекомендует энтерпрайзам начинать с первых двух слоёв. Это прямой контраргумент желанию сразу строить граф.

Проблема, которая структурой не решается

Та же Ishita Daga называет три структурные причины провала enterprise-агента: ambiguity (агент не знает, какая таблица или база знаний — источник истины), staleness (определения KPI и процессы меняются быстрее, чем обновляются .md-файлы и skills) и preference — у каждой команды своё определение одной и той же метрики. Первые две лечатся описанным выше. Третью она прямо называет нерешённой проблемой индустрии.

И это честная позиция. Semantic layer фиксирует одно согласованное определение — но согласование и есть та работа, которую он не выполняет: если финансы и продажи считают «активного клиента» по-разному, слой лишь выбирает, чьё определение победит. Memory-файл не помогает по той же причине: он запоминает решение и не примиряет стороны. Ian Gotts подходит с другой стороны: правила уровня организационной культуры нельзя закодировать как «если X, то Y» — нужен вывод из ситуации, и готовых решений он не видел. А Omri Bruchim и Tomer Ast из monday.com формулируют симптом: данные есть все, retrieval работает — не хватает понимания связей. На вопрос «на чём мне сфокусироваться прямо сейчас» агент угадывает. Их вывод стоит держать в голове: «memory» и «retrieval» — это не то же самое, что «understanding».

Граф как control plane

Последний сдвиг — перестать думать о графе как об источнике фактов.

Что произошло: граф стал планом обхода, а не справочником

• Кто: Subbiah Sethuraman и Abhilash Asokan, ZS Associates (фарма-аналитика), доклад «Why We Killed Our Multi-Agent Pipeline».
• Что делали: до графа агенты выводили связи между метриками прямо из таблиц — это «не масштабировалось и часто выдавало связи, которых в данных не существует». Построили вручную, с доменными экспертами, граф сущностей уровнями: география, под ней плательщик и аккаунт, дальше бренд, затем KPI, а от них вторичный и третичный KPI. Явными рёбрами зафиксировали, какой KPI драйвит какой, и отдельно записали, что такое TRX (число выписанных рецептов). Дальше граф стал задавать не факты, а допустимые пути обхода: каждое ребро — гипотеза. Цикл такой: берут сущность, смотрят окрестность, достают гипотезы из рёбер, уходят в исходные данные и проверяют числами. Подтвердилось — идут дальше, нет — берут следующую гипотезу, до корневой причины.
• Результат: прогон занимает больше 50 ходов. Результат, на который у аналитика уходило 3–4 недели, получается за 20–30 минут.
• Вывод: граф ценен тем, что он ограничивает пространство поиска и делает шаги проверяемыми. Хранить правду он при этом не обязан. Цена входа соответствующая: доменная экспертиза и ручная работа над онтологией — это решение для крупной системы, и стартапу с одним Postgres оно не нужно.

Обратная сторона той же медали описана Emil Eifrem (Neo4j) как четыре проблемы «толстых агентов» без общего слоя: каждая команда заново ищет, где лежат данные; данные дублированы, и надо решать, какая копия правильная; нарушается DRY — изменение разносится руками по всем агентам; нет обучения, потому что связь между намерением и источником зашита в код и промпты. Это позиция вендора графовой БД, но список проверяется самостоятельно.

Что с этим делать

Начинай с semantic layer и канонических запросов. По оценке Tesla, эти два слоя закрывают около 80% задач, граф — ответ на оставшиеся 20%, и только когда они реально болят.

Держи метаданные отдельно от данных. Схема, join-пути и определения — самостоятельный артефакт для агента. Тащить сами данные в новое хранилище часто невозможно по требованиям безопасности.

Стартовая онтология — это десятки узлов. Ориентир Ian Gotts: 10 узлов и 20 рёбер на организацию и культуру, 80–100 узлов на полную карту. Бери готовые словари (schema.org, Dublin Core, FOAF) и расширяй по фактическим ошибкам агента.

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

Проверь свой markdown на порог. Если файлы памяти грузятся целиком каждый раунд и это заметно в счётчике токенов, ты уже за порогом, где структура окупается. Если нет, она тебе пока не нужна, и это нормально.

Согласование определений метрик планируй как организационную работу. Ни semantic layer, ни memory-файл не примиряют две команды, считающие метрику по-разному. Зафиксируй владельца определения явно.