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