Автоматическое построение графа знаний из текстов под ключ

Почему граф знаний не собирается из текстов сам

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

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

Отношения даются ещё тяжелее. Правила «кто на кого ссылается» и «что из чего следует» нужно описать схемой типов, иначе извлечённые факты не с чем сопоставить. Тип связи, её направление и опора на конкретный фрагмент текста задаются онтологией — только после этого по графу можно строить запросы, а не листать источники.

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

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

Что даёт автоматическое извлечение сущностей и связей

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

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

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

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

Практический эффект: корпус в десятки тысяч документов обрабатывается за одну ночь вместо недель ручной разметки, доля связей с подтверждённым источником доходит до 0,9 на контрольной выборке, а класс ошибок «разные написания одной сущности» уходит на этапе нормализации, а не всплывает в отчётах.

Способы построения: сравнение подходов и ограничения

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

Правила и словари синонимов удобно описывать в переносимом формате SKOS: схему правит эксперт-предметник, а не разработчик, и она не привязана к одной системе. Ниже — варианты, между которыми реально выбирают, с их пределами.

Ни один из вариантов не даёт готового графа «из коробки» — ограничения методов снимаются только их сочетанием. Поэтому на старте мы фиксируем схему отношений, собираем эталонную разметку на 200–300 фрагментах и по ней выбираем, где достаточно правил, а где нужна модель.

Этапы внедрения: от аудита корпуса до передачи схемы

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

1. Аудит корпуса текстов. Считаем объём и форматы, долю сканов и таблиц, находим дубликаты, разноязычные вставки и документы с устаревшими реквизитами. На выходе — карта корпуса: что извлекается уверенно, что требует предобработки, а что в граф не попадёт вовсе.

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

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

4. Контрольные выборки. Размечаем вручную несколько сотен фрагментов и считаем полноту и точность отдельно по каждому типу связи, а не одной усреднённой цифрой. Ошибки разбираем по причинам и возвращаемся к правилам и словарям, пока показатели не стабилизируются.

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

6. Передача решения. Отдаём схему связей, словари, правила, скрипты пересборки графа и регламент обновления; проводим разбор с вашей командой, чтобы граф можно было расширять без нас.

Что передаём на руки: артефакты и регламенты сопровождения

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

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

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

Кейс: граф знаний по архиву технической документации

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

Мы собрали конвейер: разметка структуры документов, извлечение сущностей и отношений, нормализация терминов (один узел под пятью написаниями — одна запись), выборочная проверка человеком. Связи легли в графовую базу Neo4j — обход на 3-5 переходов перестал быть ручной сборкой и выполняется запросом.

Метрики до и после

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

Чем отличается извлечение связей от разметки сущностей?

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

Извлечение связей добавляет второй слой — типы отношений между найденными сущностями: «работает в», «владеет долей», «поставляет», «подчиняется», «упоминается вместе с». Здесь решает контекст упоминания: отношение выводится не из близости слов, а из синтаксической роли и сказуемого, поэтому «директор подписал договор с поставщиком» и «директор упомянул поставщика в отчёте» дают разные рёбра с разной уверенностью.

Между двумя слоями стоит разрешение неоднозначности. Одна организация в корпусе встречается как полное наименование, аббревиатура и опечатка; человек — по фамилии, инициалам и должности. Если упоминания не сведены к одному узлу, граф распадается на изолированные фрагменты, и связи теряются чаще, чем при ошибке разметки.

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

Технические сомнения: качество, объём и сопровождение

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

Как граф избавляется от дублей?

Один объект приходит сокращением, опечаткой, в другом падеже, латиницей и кириллицей. Блок слияния сравнивает варианты по написанию, контексту и внешним справочникам и сводит их в один узел с синонимами. Каждое слияние журналируется и обратимо: ошибочное объединение разбирается, а не остаётся навсегда.

Придётся ли отказываться от своей онтологии?

Нет. Если у вас есть отраслевая модель, справочники или принятый классификатор, извлечение ведётся в их рамках: типы узлов, связи и атрибуты берутся оттуда, а не из нашей схемы по умолчанию. Расхождения показываем отдельно — вы решаете, расширять модель или нормализовать данные под неё.

Что происходит при обновлении корпуса?

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

Обсудим задачу: что нужно для старта работ

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

• Состав корпуса: сколько документов и типов, примерный объём, языки, в каком виде они лежат сейчас — текстовые файлы, вёрстка, сканы, выгрузка из учётной системы или переписка.
• 5–10 примеров реальных документов разного типа: по ним видно разметку, плотность терминов, долю таблиц и изображений — это точнее любой анкеты.
• Текущие словари и справочники: классификаторы, реестры, списки синонимов и сокращений. Если они уже ведутся, мы подхватываем их как основу, а не строим терминологию заново.
• Ожидаемый результат по связям: какие типы сущностей и отношений нужны, требуется ли вес или степень уверенности у каждой связи, насколько глубоко строить цепочки.
• Правила доступа: где физически лежат данные, кто владелец, разрешена ли выгрузка и есть ли фрагменты, которые обрабатывать нельзя.
• Точка приложения: какой процесс должен получить граф — поиск по базе, отчётность, ответы на вопросы сотрудников или разбор обращений.

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