Зачем LLM нужны онтологии и графы фактов
В первой статье мы остановились на том месте, где классический RAG начинает буксовать. Он умеет находить близкие по смыслу фрагменты текста, но не умеет по-настоящему "жить" внутри структуры знаний. До определённого масштаба это почти незаметно. Но как только данных становится очень много, а вопросы требуют не буквального извлечения фраз, а работы со связями, векторный поиск начинает всё чаще давать не то чтобы неправильный, а недостаточно глубокий результат. Он вытаскивает похожее. Но похожее — не всегда значит связанное.
Это различие долгое время казалось второстепенным, потому что человеческая работа с текстом тоже строится на чтении документов. Мы открываем файлы, смотрим таблицы, сопоставляем абзацы, делаем выводы. Кажется естественным научить этому и машину. Проблема в том, что человек во время чтения почти никогда не хранит знание в виде сплошного текста. Мы постоянно строим внутреннюю модель: кто с кем связан, что из чего следует, где причина, где следствие, что является частью чего, что к чему относится, что было раньше, что позже. То есть в сознании текст преобразуется в структуру. Языковая модель умеет очень правдоподобно имитировать этот процесс в ответе, но сама память у неё не устроена как явный граф понятий и связей.
Отсюда и возникает идея: а что, если не заставлять систему каждый раз заново “догадываться” о структуре текста, а вынести эту структуру в отдельный слой? Что, если вместо хранения знания в виде бесконечного массива документов и их чанков превращать содержание в граф фактов, где сущности и связи существуют в явном виде? Именно здесь появляются онтологии.
Слово “онтология” у многих вызывает либо академические ассоциации, либо ощущение чрезмерной сложности. Кажется, что это что-то из семантического веба, философии, старых исследовательских проектов и громоздких систем, которые трудно применить в реальных продуктах. Но если отбросить весь исторический и терминологический шум, идея довольно проста. Онтология — это не просто список терминов и не просто граф. Это структурированная модель предметной области, где явно заданы сущности, их свойства, отношения между ними и возможные правила интерпретации этих отношений.
В прикладном смысле можно начать с совсем простого уровня — с триплетов вида “субъект — предикат — объект”. Например: “Алиса — работает_в — компании”,
“Боб — изучал — Леонардо_да_Винчи”,
“сковорода — используется_для — жарки”,
“крыло — часть — самолёта”.
Уже здесь отличие от обычного текста становится огромным. В тексте связь может быть скрыта, размыта, сформулирована по-разному или зависеть от контекста. В триплете связь зафиксирована явно. Если таких триплетов много и они объединены в граф, мы начинаем работать не просто с набором фраз, а с моделью мира.
На этом месте обычно задают закономерный вопрос: а что это даёт практически? Ответ состоит из нескольких слоёв. Во-первых, текст сильно сжимается. Когда из него извлекаются факты и связи, уходит огромное количество языковой оболочки. Формулировки, повторения, стилистика, вводные конструкции, обрамление мысли — всё это может быть полезно для человека, но для машинной памяти часто оказывается лишним шумом. В нашем семинаре как раз подчёркивалось, что онтологическое представление позволяет сжать текст примерно на порядок, оставив в памяти факты и их связи Это не просто экономия места. Это смена самого принципа хранения знания.
Во-вторых, граф знаний позволяет работать с отношениями напрямую. В обычном RAG похожесть определяется через embedding-пространство: какие куски текста статистически близки к запросу. В онтологии связь не предполагается, а существует. Если один объект является частью другого, если человек состоит в отношении с организацией, если документ относится к проекту, если конкретный узел связан с несколькими доменами, это можно не угадывать по тексту, а читать из модели. Для систем, которым нужно отвечать на вопросы о сложных взаимосвязях, это огромный сдвиг.
Но, пожалуй, самое важное — граф открывает путь к логическому выводу. Не к полному “сильному ИИ” в голливудском смысле, а к очень практичной способности проходить по цепочкам отношений. Если у нас есть факт, что Алиса знает Боба, и другой факт, что Боб интересуется Леонардо да Винчи, то система может уже не искать буквальное предложение “Алиса знает Леонардо да Винчи”, а строить более содержательный ответ: прямого подтверждения нет, но по цепочке связей можно предположить, что такая осведомлённость вероятна. В обычном текстовом поиске подобные вещи легко теряются, особенно если данные размазаны по многим источникам. В графе они становятся естественным режимом работы.
До недавнего времени на этом месте теория сталкивалась с жёсткой практической преградой. Онтологии традиционно строились вручную. Это была тяжёлая работа аналитиков, инженеров знаний и специалистов по предметной области. Нужно было описывать сущности, продумывать домены, задавать связи, устранять противоречия, следить за непротиворечивостью модели, устранять дубли, согласовывать термины. Для крупных промышленных систем это означало годы труда и очень высокую стоимость владения. Поэтому в массовой AI-разработке онтологии долго проигрывали более простым решениям: векторный поиск, таблицы, SQL, поисковые индексы, разметка документов.
Ситуация изменилась с появлением сильных языковых моделей. Оказалось, что LLM можно использовать не только для генерации текста, но и как движок извлечения структуры. Модель уже умеет видеть сущности, отношения, типы связей, иерархии, принадлежности, временные последовательности. Если ей поставить правильную задачу, она может извлекать триплеты, группировать факты, строить первичный граф и даже порождать формальные представления вроде TTL или RDF. В семинаре это было показано на примере юридического текста: сначала из документа извлекаются триплеты, затем на их основе строится связанная модель, которую уже можно визуализировать и превращать в граф знаний
Однако здесь важно не впасть в другую крайность. Тот факт, что LLM умеет извлечь триплеты “из коробки”, ещё не означает, что задача построения онтологии решена. Наоборот, именно после этого начинаются настоящие инженерные сложности. Если взять небольшой текст, модель ещё может построить связный фрагмент графа. Но если дать ей книгу, большой корпус документов, промышленный архив или массив законов, сразу всплывают вопросы, которые в демо-режиме обычно не видны.
Первый вопрос — параллелизация. Большие документы приходится резать на части, иначе построение будет слишком медленным или нестабильным. Но если графы извлекаются по кускам, возникает проблема сшивки: как понять, что сущность из одной части документа — это та же сущность, что и в другой? Как объединить локальные графы в общую модель? Как не потерять связи, которые пересека��т границы чанков?
Второй вопрос — устранение дублей и неоднозначностей. Один и тот же объект может называться по-разному, несколько терминов могут обозначать одно и то же, а одно слово — разные сущности. Классический пример с “луком” как растением, оружием или элементом образа хорошо известен, но в реальных корпоративных данных всё гораздо сложнее: сокращения, внутренние названия, артикулы, исторические обозначения, устаревшие версии терминов, параллельные классификаторы.
Третий вопрос — непротиворечивость. Языковая модель может извлечь факты, которые локально выглядят правдоподобно, но глобально конфликтуют между собой. В одном месте сущность определяется как часть одного класса, в другом — другого. В одном документе указана одна метрика, в другом — иная, в одном домене это процесс, в другом — артефакт. Если не построить процедуры валидации, консолидации и нормализации, граф быстро превращается не в структуру знания, а в очень изощрённый хаос.
Именно поэтому переход от RAG к онтологиям — это не просто смена формата хранения. Это новый уровень архитектуры. Здесь уже недостаточно сказать “модель умеет извлекать триплеты”. Нужен целый pipeline: разбор текста, выделение сущностей, извлечение фактов, нормализация понятий, объединение локальных графов, проверка противоречий, формирование общей модели, экспорт в формальные форматы, подключение графовой базы, построение запросного слоя. Языковая модель здесь становится не хранилищем и не конечным ответчиком, а двигателем преобразования текста в знание.
Почему всё это вообще стоит усилий? Потому что в обмен мы получаем совсем другой режим работы с данными. Если RAG в первую очередь возвращает релевантные фрагменты текста, то онтология позволяет задавать вопросы к самой структуре знания. Можно искать не просто документы, а отношения между объектами. Можно строить запросы не только по словам, но по типам сущностей, по путям в графе, по логике принадлежности и связности. Можно соединять данные из разных источников, которые в текстовом поиске почти не сшиваются. Можно делать ответы более насыщенными фактами, потому что система опирается не на один-два похожих кусочка текста, а на плотную сеть явных отношений.
Это особенно заметно в тех областях, где знание по природе своей является сетью. Промышленность — очевидный пример. Самолёт, турбина, станок, производственная линия, склад, инженерная спецификация — всё это не просто текстовые описания. Это сложные системы “часть — целое”, “зависимость — условие”, “процедура — результат”, “материал — норматив”, “узел — модификация”. Если хранить это только как файлы и искать по ним через embeddings, мы всё время будем страдать от потери структуры. Если же превращать данные в онтологию, можно буквально обходить объектную модель мира.
То же самое справедливо и для правовых текстов. Законодательство — это не просто длинные документы. Это система определений, норм, исключений, отсылок, областей применения, зависимостей между статьями и актами. Когда LLM извлекает из юридического корпуса граф связей, возникает возможность задавать вопросы не только “что сказано в статье”, но и “какие нормы зависят от какого определения”, “какие исключения активируются в таком-то случае”, “какие сущности участвуют в этой норме”. Это уже гораздо ближе к интеллектуальной правовой навигации, чем к простому поиску по PDF.
Но наиболее интересный поворот начинается там, где онтология перестаёт быть просто “более удобной базой знаний” и начинает рассматриваться как форма памяти. Не памяти документа, а памяти системы. Если текст — это поток, то граф — это удержание структуры. А удержание структуры и есть то, чего так не хватает языковым моделям при долгой работе с миром. Именно поэтому разговор об онтологиях быстро выходит за рамки корпоративного поиска и упирается в более фундаментальную тему: можно ли использовать их как основу долговременной памяти для ИИ-систем, роботов и диалоговых агентов?
