Исправление проблем RAG с помощью онтологии и графа знаний в документации по полупроводникам
Документация по разработке полупроводниковых устройств получила онтологию RDF/OWL, граф знаний Neo4j и механизм поиска с ограничениями онтологии, что позволило сократить количество дополнительных вопросов в рамках технологии RAG на 30 процентов.
Источники: How I Built a Semantic Layer to Ground Our RAG System…And Why Ontology Was the Missing Piece
Где терпит неудачу простой RAG
Первый прототип генерации с использованием метода retrieval-augmented generation для обработки документации продукта обычно выглядит многообещающе: подключается векторный хранилище, документы делятся на части, выполняются несколько запросов, и ответы кажутся правдоподобными. Затем инженер по верификации спрашивает, какой метод следует использовать для проверки конкретного блока с учётом ограничений по ресурсам, и система с полной уверенностью отвечает о методах функциональной верификации. Содержание оказывается точным с точки зрения самой системы, но неверным для поставленного вопроса.
Причина кроется в словарном запасе. В процессе верификации полупроводников термин «методология» не является обычным словом. Он относится к конкретным подходам к верификации, каждый из которых связан с определенными инструментами, этапами и результатами выполнения. Система извлекла текст, но не знания. Поэтому речь идет о проблеме смысла, а не о проблеме извлечения информации, и лучшая модель вкладки эту проблему не решит. Семантический слой может ее решить. Далее описывается, как такой слой проектируется и создается для набора документации EDA: онтология, граф знаний, связь с технологией RAG и полученные результаты.
Документация как «пустыня знаний»
Речь идет о программном обеспечении для верификации в корпоративных условиях, в котором имеются тысячи тем в формате DITA XML, распределенных по нескольким линейкам продуктов и охватывающих настройку инструментов, рабочие процессы выполнения задач и рекомендации по методологии. Эти материалы существуют, но представлены в виде обычного текста, а не структурированных знаний. Этапы верификации, методологии и инструменты находятся в отдельных документах и связаны между собой лишь на основе того, что уже известно читателю. Опытный инженер с десятилетним стажем справляется с этим, тогда как искусственный интеллект, пытающийся найти нужную информацию, оказывается в ситуации, похожей на минное поле.
Целью было создание решения, которое одновременно удовлетворяло бы нескольким потребностям: использование технологии RAG, корпоративный поиск, поиск контента и долгосрочное управление контентом.
Сначала необходимо сформулировать проблему
Прежде чем был написан хотя бы один фрагмент кода онтологии, прошли недели обсуждений с участием менеджеров продуктов, экспертов по верификации, руководителей отделов документации, инженеров по поиску и команды по науке о данных, работающих над помощником GenAI. Эти беседы определялись тремя вопросами.
Во-первых, какие бизнес-результаты имеют значение? Ответами стали более высокая точность поиска, стандартизированный слой обеспечения основ для помощников на основе больших языковых моделей и объединенные данные всех линеек продуктов. Во-вторых, как выглядит неудача в настоящее время? Поиск по ключевым словам возвращает нерелевантные результаты, пользователи отправляют дополнительные запросы, поскольку первый ответ не учитывает контекст, а ручное связывание контента не справляется с объемом работы. В-третьих, как будет выглядеть успех? Система поиска должна понимать, что запрос о динамической верификации проектов с управлением энергопотреблением требует контента, связанного с определенной методологией, на определенном этапе верификации, с использованием конкретных инструментов, а не просто любого документа, содержащего соответствующие ключевые слова.
Эта подготовительная работа предотвращает чрезмерное разрастание онтологии — привычку моделировать всё, что кажется интеллектуально интересным, вместо того, что действительно необходимо бизнесу.
Открытие концепций и проектирование онтологии
Проектирование онтологии начинается с поиска знаний, а не с использования инструментов вроде Protégé или файлов формата Turtle. В его основу легли четыре источника информации:
- Интервью с инженерами по верификации, которые описали свой подход к взаимосвязям между инструментами, порядку их выполнения и точкам принятия решений, отличающемуся от способа работы самих инструментов
- Существующая документация и интерфейсы инструментов, в которых повторяющиеся термины выявили концепции, остававшиеся стабильными на протяжении многих лет
- Логи, файлы конфигурации и определения работоспособности процессов, показывающие реальные связи между инструментами, этапами и результатами, которые зачастую не совпадали с информацией в документации
В результате был сформирован основной набор стабильных концепций домена, фактически таксономия, которая сначала намеренно была записана в Excel. Работа над онтологией является коллективной, и те, кто должен проверять модель — эксперты в данной области и менеджеры продукта — не владеют языком Turtle. Таблица в электронном виде позволяет им верифицировать и усовершенствовать модель, а также сформировать общее понимание задолго до начала формальной кодировки.
После того как модель была утверждена после нескольких раундов проверки, она была формализована с использованием стандартов семантического веба:
- RDF представляет каждую сущность и связь в виде троек
- OWL обеспечивает иерархии классов, ограничения свойств и логические правила
- SKOS стандартизирует терминологию в различных линейках продуктов с помощью контролируемых словарей
- Schematron проверяет правильность использования онтологии во время создания контента в Oxygen XML
Сама онтология хранится в файлах TTL, в то время как правила Schematron напрямую встраиваются в среду создания контента. Поэтому авторы не могут ввести концепции, нарушающие структуру онтологии, так что контроль является частью рабочего процесса, а не чем-то, что добавляется в последний момент. Каждая связь обеспечивается с помощью метаданных пролога в DITA XML и контролируемых словарей; не допускаются свободные теги и подходы вроде «примерно достаточно».
Архитектура графа знаний
Онтологии нужно место для хранения — граф, который можно запрашивать и исследовать. Дизайн разделен на слои:
- Слой схемы: определения онтологии в файлах TTL
- Слой терминологии: словарь на основе SKOS
- Слой экземпляров: тройки RDF, создаваемые на основе метаданных контента
- Инфраструктурный слой: Neo4j для хранения и запросов
Вокруг этих слоев расположены пайплайны семантической обработки, которые преобразуют созданный контент в тройки, готовые к использованию в графе, и загружают их в Neo4j, а также API для запросов и поиска, обеспечивающие доступ к графу для таких инструментов, как пайплайн RAG, и облачная инфраструктура Azure для масштабирования и интеграции с существующими сервисами платформы.
Пайплайн от создания контента до формирования графа делает этот подход более чем просто упражнением в использовании онтологий. Авторы пишут тексты в формате DITA с использованием Oxygen XML. Схематрон контролирует наличие метаданных, соответствующих онтологии, во время ввода текста. Контент публикуется через Adobe Experience Manager. Семантические метаданные сохраняются в неизменном виде и загружаются в Neo4j, где системы поиска, аналитики и искусственного интеллекта могут выполнять по ним запросы. Это означает полный архитектурный контроль над всем потоком данных — от инструментов создания контента через граф до слоя API.
Интеграция семантического слоя в RAG
Именно здесь прилагаемые усилия приносят результат. Стандартный подход RAG разбивает документы на фрагменты, встраивает эти фрагменты, хранит их в векторной базе данных, выполняет поиск по сходству и передает найденные результаты в LLM. Этот метод работает, но не учитывает смысл, причем постоянно возникают три основных проблемы:
- Путаница в контексте, когда система находит правильный концепт в неправильном контексте, как описывалось ранее на этапе верификации
- Несоответствие словаря, когда инженеры используют сокращения, а в документации — формальные термины, в результате чего упускается релевантный контент
- Галлюцинации из-за неоднозначности, когда нечеткие термины в фрагменте позволяют LLM заполнять пробелы правдоподобными, но неверными знаниями из определенной области
Благодаря использованию графа знаний в качестве основного слоя поиск меняется четырьмя способами.
Правила онтологии ограничивают то, что может быть извлечено. Когда в запросе указывается методология верификации, сначала происходит поиск соответствия этому термину в онтологии, после чего поиск ограничивается контентом, помеченным этой методологией и её допустимыми связями. Векторный поиск всё равно выполняется, но уже над семантически отфильтрованным подмножеством данных.
Соблюдается канонический словарь терминов. Пользовательские запросы преобразуются в стандартизированные термины перед извлечением информации, поэтому выражение «power-aware sim» преобразуется в формальный термин «simуляция с учётом потребления энергии», и возвращается соответствующий контент независимо от того, как инженер сформулировал свой вопрос.
Фрагменты текста формируются в соответствии с границами онтологии, а не по фиксированному размеру. Отрывок, описывающий роль того или иного инструмента на определённом этапе верификации, остаётся целым и не разрезается посереди концепции.
Недопустимые комбинации фильтруются. Онтология указывает, какие комбинации инструментов, методологий и этапов считаются допустимыми, поэтому фрагменты, предполагающие недопустимую комбинацию, понижаются в приоритете или удаляются до того, как их увидит большая языковая модель.
Положительные результаты проявились сразу. Ответы основаны на проверенном контенте с метками онтологии, а не на предположениях модели относительно верификации полупроводников. Ограничение того, что может видеть модель, устраняет категорию галлюцинаций, вызванных неоднозначным или безконтекстным поиском. Каждый полученный фрагмент содержит метаданные онтологии, что позволяет системе объяснить свой выбор: какой объект, какая связь, какое ограничение. Кроме того, агентные рабочие процессы могут проследовать по графу для планирования многоэтапных задач верификации на основе реальных связей между объектами, а не только сходства текста.
Технологическая стек
- Создание контента: Oxygen XML с DITA
- Проверка корректности и управление: Schematron и Schematron Quick Fix
- Кодирование онтологий: RDF, OWL и SKOS в файлах Turtle
- Граф знаний: Neo4j
- Публикация: Adobe Experience Manager
- Облака: Microsoft Azure
- Интеграция RAG: пользовательские API поиска, объединяющие Neo4j и векторный поиск
- Слой ИИ: собственный корпоративный ассистент на основе технологий GenAI
Результаты
После внедрения за собой оставили след четыре показателя:
- Количество повторных запросов сократилось на 30%. Документация теперь служит высокоточным эталоном для ИИ-ассистентов, что позволяет пользователям гораздо чаще получать правильный ответ с первой попытки. Именно этот показатель был ключевым, поскольку он напрямую отражает качество поиска.
- Частота повторного использования контента выросла на 25%. Благодаря семантическим тегам и пониманию взаимосвязей один и тот же контент может использоваться в нескольких линейках продуктов без необходимости вручную копировать его.
- Время ручного создания ссылок сократилось на 60%. Функция «Связанный контент» в AEM теперь работает на основе графа, поэтому ссылки, ранее создававшиеся вручную, генерируются из отношений в онтологии. Удобство использования для пользователей также улучшилось на 25%.
- Циклы ручной проверки контента сократились на 40%. Правила Schematron, полученные из онтологии, выявляют проблемы в Oxygen во время работы авторов, что позволяет обеспечивать высокое качество на ранних этапах.
Уроки для подобных проектов
Сначала смоделируйте область применения, прежде чем выбирать технологию. Команды часто сразу переходят к использованию Neo4j или векторных баз данных, не определившись с элементами и их связями. Это всё равно что строить дом, не нарисовав план. Проведите начальный этап работы в таблице вместе с экспертами по области. Это может показаться не таким привлекательным, но именно здесь заключается истинная ценность.
Рассматривайте управление как структуру. Онтология без управления быстро деградирует, поскольку каждый новый автор, продукт или нестандартный случай подрывают её целостность. Внедряйте механизмы проверки в процесс создания контента, чтобы они выполнялись автоматически, а не в ходе периодических аудитов, которые всегда происходят с опозданием.
RAG без семантики — это поиск с дополнительными этапами. Векторное сходство необходимо, но недостаточно для поиска в крупных предприятиях. Когда в домене имеются структурированные связи, иерархии и ограничения, как это обычно бывает в корпоративных доменах, семантический слой позволяет перейти от поиска похожего текста к поиску релевантных знаний.
Измеряйте то, что важно для бизнеса. Фраза «Мы создали граф знаний» не является бизнес-результатом. В то время как фраза «Количество последующих запросов сократилось на 30% благодаря повышению точности поиска» — да. Каждый архитектурный выбор должен быть связан с показателем, который ценят люди вне команды.
Что дальше
Семантический слой — это основа, а не предел. Он постоянно развивается: тестируются, проверяются и объединяются новые концепции без нарушения существующей семантики, а достижения в инструментах на основе LLM, слиянии графов и искусственного интеллекта и агентной архитектуре позволяют строить что-то новое на его основе. Более общий урок заключается в том, что в спешке к технологиям GenAI наименее оцениваемой инвестицией является не улучшенная модель или более большое окно контекста, а более качественная семантическая основа. Модели приходят и уходят, но смысл остается.
Связанные материалы
- Почему агентам для анализа данных ИИ нужен семантический слой вместо чистого SQL — Преобразование текста в SQL на основе сырых таблиц склада приводит к созданию ложных метрик и игнорированию правил доступа. Узнайте, как семантический слой вроде Cube в сочетании с MCP придаёт агентам управляемый бизнес-смысл.
- От примитивного подхода к производственной системе RAG для документов SEC 10-K: разбиение на фрагменты, гибридный поиск — Почему стандартная система RAG не справлялась с 300-страничными документами 10-K и как это исправить: разбиение на фрагменты с учётом структуры разделов, гибридный метод поиска, переранжирование с использованием кросс-кодеров, проверка качества и использование метаданных.