Головна / Статті / Онтологія-орієнтований GraphRAG: коли векторам потрібні типовані зв’язки

graphrag ontology rag knowledge-graph retrieval security

Онтологія-орієнтований GraphRAG: коли векторам потрібні типовані зв’язки

Як анкори ідентифікаторів, контракти онтологій, фузія рангів та механізми «цитувати або відхилити» усувають проблеми RAG щодо CVE, багатокрокової власності та неявних фактів у графах.

2819 слів

Технологія щільного пошуку добре відповідає на багато запитань, проте все одно зазнає невдач у певних ситуаціях: з точними ідентифікаторами, багатоетапними зв’язками та фактами, які існують лише у вигляді графової структури. GraphRAG, який враховує онтологію, сприймає ці невдачі як елементи для проектування — не як причини відмовитися від векторів, а як підстави для додавання типованого шару знань поруч із ними.

Частина 1 — Як саме працює RAG

У класичному підході RAG запит вставляється у систему, отримуються найближчі фрагменти тексту, і на основі цього контексту генерується відповідь. Для запиту про вразливість, наприклад:

question: "path traversal apache httpd"

рейтинги векторів та лексичні показники можуть не збігатися:

VECTOR (cosine)                       LEXICAL (keyword overlap)
1. CVE-2021-41773  0.746  ← correct   1. CVE-2021-28544  6.60
2. CVE-2021-23797  0.735              2. CVE-2021-40525  6.47
3. CVE-2021-32643  0.728              5. CVE-2021-41773  5.57  ← correct, buried

Коли правильний CVE є, але не є домінуючим, система генерує відповідь самостійно. Домени, що містять багато ідентифікаторів (CVE, SKU, ідентифікатори замовлень), швидко виявляють цю проблему.

Частина 2 — Перешкоди, з якими він стикається

Невдача 1 — точні ідентифікатори

Лексична збігність допомагає, проте „шумні“ сусіди все одно перемагають. Отриманий прозовий текст навіть може відхилити саму концепцію вразливості:

[S1] "Rejected reason: This vulnerability does not meet the criteria for a
      security vulnerability…"

Потім генерація відтворює неправильного сусіда.

Поразка 2 — повнота взаємозв’язків

На запитання „Які продукти постраждали?“ потрібні зв’язки, а не лише найближчий абзац. Алгоритми схожості повертають відповідні CVE, але не простежують посилання типу AFFECTS.

Поразка 3 — факти, які ніхто не записав

Деякі відповіді існують лише у вигляді перетину елементів — ніколи як окреме речення. Жоден фрагмент тексту не містить цього з’єднання; лише граф може його показати.

Частина 3 — що додає граф знань

Вузли та ребра з визначеними типами роблять ідентифікатори та взаємозв’язки першокласними:

(:Vulnerability {cve_id: 'CVE-2021-41773', cvss_base_score: 9.8, cvss_severity: 'CRITICAL'})
   -[:AFFECTS {version: '2.4.49'}]-> (:Product {key: 'apache:http_server'})
   -[:HAS_WEAKNESS]->                (:Weakness {cwe_id: 'CWE-22'})

Проходження по графу дає відповіді на запитання про взаємозв’язки; вектори все ще корисні, коли прозовий текст є належним доказом.

Онтологія проти графа знань — оперативна відмінність

Онтологія — це угода щодо того, які типи ентитетів, які типи ребер та які властивості є необхідними. Граф знань — це заповнена інстанція відповідно до цієї угоди. Без онтології процес вилучення даних стає нестабільним, а об’єднання інформації — ненадійним. З онтологією пайплайни перевіряють та відхиляють некоректні тріпли ще до того, як вони завадять отриманню потрібних даних.

Три значення терміна “GraphRAG”

Граф як індекс — зберігання фрагментів тексту, але їх отримання через сусідства в графі.
Граф як пам’ять — ентитети та ребра є основним джерелом зберігання; текст є доказом.
Граф як планувальник — агент спочатку планує кроки, а потім отримує текст.

Дизайни, що враховують онтологію, зазвичай поєднують підходи (2) та (1): структуровані факти для точності та вихідний текст для посилань.

Частина 4 — Архітектура, шар за шаром

Процес обробки даних витягує ентитети/взаємозв’язки з онтології, записує факти графа, зберігає фрагменти вихідного тексту та створює векторний/лексичний індекс на основі тексту. Час виконання запиту дозволяє визначати ідентифікатори, розширювати сусідства в графі, здійснювати щільне/лексичне пошукове знаходження, об’єднувати рейтинги та формувати запит із окремими розділами ФАКТИ та ДОВІДКИ, а також правилами цитування.

Три рішення, які змусили прийняти дані

Ідентифікатори є кращим варіантом за нечітке збіг, коли присутній токен CVE/продукту.
Зважене об’єднання має підвищувати рейтинги елементів графа для запитів на ідентифікатори, не приховуючи при цьому прозовий текст у запитах на оповідання.
Перевірки вірності мають відхиляти відповіді, які посилаються на відсутні теги чи суперечать властивостям графа.

Частина 5 — Один запит, від початку до кінця

Запит:

Q: "which products are affected by CVE-2021-41773"

Розв’язання проблеми ідентифікаторів:

ANCHOR  Vulnerability  CVE-2021-41773  method=identifier  conf=1.00

Ваги фузії, коли ідентифікатор є опорою:

weights = {graph: 2.0, vector: 1.0}     # identifier match
# a lexical product match would be 1.2; no anchor at all, 0.0

Конкуруючі списки:

VECTOR  1. CVE-2021-21022 (Magento IDOR)   2. CVE-2021-27385  …
GRAPH   1. CVE-2021-41773 (anchor)         2. CVE-2021-25216 (shares netapp:cloud_backup)

Оцінки фузії за принципом взаємності рангу:

CVE-2021-41773   2.0/(60+1) = 0.03279   ← graph, rank 1
CVE-2021-21022   1.0/(60+1) = 0.01639   ← vector, rank 1

Факти графа, стиснуті для моделі:

FACTS (from the knowledge graph):
[G1] CVE-2021-41773 | CRITICAL 9.8 (CVSS 3.1) | CWE: CWE-22
     affects: apache:http_server 2.4.49, fedoraproject:fedora 34,
              fedoraproject:fedora 35, netapp:cloud_backup,
              oracle:instantis_enterprisetrack 17.1 / 17.2 / 17.3
     source: https://nvd.nist.gov/vuln/detail/CVE-2021-41773

Джерела доказів:

EVIDENCE (source text):
[S1] "A flaw was found in a change made to path normalization in Apache
      HTTP Server 2.4.49. An attacker could use a path traversal attack…"

Структурована відповідь з посиланнями:

{"answer": "CVE-2021-41773 is CRITICAL with a CVSS base score of 9.8 [G1].
            It affects apache:http_server 2.4.49, fedoraproject:fedora 34,
            fedoraproject:fedora 35 [G1].",
 "sources": ["G1"],
 "entities": [{"label": "Vulnerability", "key": "CVE-2021-41773"}],
 "confidence": "high"}

Блокувальні механізми після генерації:

✓ every cited tag exists in the context
✓ the answer cites something at all
✓ every CVE id in the answer appears in the context
✓ entity labels are real ontology classes
✓ numbers that look like CVSS scores match the graph facts
→ ACCEPTED

Погана відповідь, яка не пройшла перевірку:

{"answer": "CVE-2021-41773 scores 4.3 and affects nginx [G1]."}

Причини відхилення:

✗ states 4.3 but the graph facts say [9.8]
✗ entity Product nginx:nginx is not in the context
→ REJECTED → one repair attempt → still bad → REFUSAL

Та сама технологія, але на один крок далі

Об’єднання інвентарю перетворює „постраждалі продукти“ на „постраждалі додатки першого рівня та відповідні команди“:

application        criticality  team            library  pinned    match_precision
checkout-web       tier1        payments        httpd    2.4.49    version-exact
log-aggregator     tier2        infrastructure  httpd    2.4.49    version-exact
api-gateway        tier1        platform-core   httpd    1.15.17   product-level

Та сама система опор та фузії; ще один додатковий крок через посилання між додатками.

Частина 6 — Результати, витрати та помилки

Щодо ідентифікаторів та багатокрокових суїт, фузія з урахуванням онтології підвищує точність порівняно з базовими підходами, що використовують лише вектори; у випадку запитів з чистим прозовим текстом покращення є меншим — тому краще залишатися з векторами. Витрати пов’язані з екстракцією, операціями над графами та трохи довшими запитами, а не з відмовою від ембеддингів.

Баги, тому що саме вони є справжнім змістом

Типові баги в продакшені: зміщення онтології (проникнення нового типу ребра), галюцинації екстрактора (неправильний рівень серйозності), помилки копіювання параметрів фузії, теги посилань, яких немає в контексті, та кеш, що подає застарілі знімки графа після оновлення CVE. Кожен баг відповідає певному тесту: перевірка схеми, меж властивостей, налаштувань фузії, перевірка наявності посилань та контроль TTL/недійсності.

Частина 7 — Коли це будувати, а коли — ні

Використовуйте цей підхід, коли дані містять ідентифікатори, запитання щодо власності/впливу у кілька етапів або факти, які ніколи не формулюються у вигляді речень. Уникайте його, якщо корпус достатньо малий для використання лише потужних гібридних методів пошуку, або якщо ніхто не буде підтримувати онтологію. GraphRAG — це не ознака складності; це рішення проблем, виявлених під час тестування.

П’ять інваріантів, які варто зберігати на будь-якому рівні

Онтологія на першому місці — типи перед тріплами.
Якорі для ідентифікаторів — точне збігання перед використанням коефіцієнта косинуса.
Розділення фактів та доказів у запиті.
Механізм цитування чи відхилення після генерації результату.
Оцінка за власними запитаннями — а не лише за публічними статистиками успішності.

Ці інваріанти залишаються корисними як під час демонстрації на ноутбуку, так і у системах забезпечення безпеки для кількох користувачів. Розширення охоплення має означати розширення онтології та відповідних елементів, а не додавання ще однієї інструкції до неструктурованої купи даних. Тримайте показники екстракції (точність/пригадування щодо елементів та зв’язків) поруч із показниками відповідей; інакше „краща“ модель може тихо створювати відношення, які здаються логічними, але провалюють перевірки. Версіонуйте онтологію як API: додавання змін є простим, перейменування вимагає процедур міграції, а видалення — створення „надгробків“, щоб старі копії не відновлювали видалені зв’язки. Для цілодобового моніторингу ставте сповіщення при різкому зростанні кількості відхилень на вході та при підвищенні рівня помилок екстрактора, а не лише при затримках Gateway — ці сигнали дозволяють виявити проблеми у системі знань ще до того, як користувачі помітять неправильну серйозність CVE. Нарешті, у перші місяці виділіть бюджет на людський огляд суперечливих CVE та мапувань продуктів; такі етикетки можуть призводити до проблем під час повторних тестувань.

Тести фузії, які забезпечують точність ваг фузії у міру зростання каталогу.

При оцінці постачальників чи фреймворків запитуйте, як вони кодують обмеження онтології, як поєднують ранги графів та векторів, та як перевіряють точність цитувань. Демонстрації, які показують лише красивий графічний інтерфейс без цих трьох відповідей, зазвичай створюють ту саму проблему RAG під новою назвою. Віддавайте перевагу простим, написаним вручну конвеєрам із чіткими орієнтирами перед „магічним агентним графовим міркуванням“, яке не може показати, який елемент пояснює ту чи іншу ступінь серйозності. Саме цей простий підхід робить GraphRAG, обізнаний з онтологією, функціональним.

Розглядайте ваги фузії як параметри конфігурації, які перевіряються: зберігайте їх поруч із фіксами, які зафіксовують запитання, списки кандидатів та очікуваний ідентифікатор лідера. Коли хтось „налаштовує“ ваги у ноутбуці, вимагайте PR, який оновить ці фікси, щоб регресії не залишалися прихованими у „командному знанні“.

Розглядайте ваги фузії як конфігурацію, що перевіряється: зберігайте їх поруч із фікстурами, які фіксують запитання, списки кандидатів та очікуваний ідентифікатор лідера. Коли хтось „налаштовує“ ваги у нотатнику, вимагайте PR, який оновить ці фікстури, щоб регресії не залишалися прихованими у „кочових“ знаннях.

Розглядайте ваги фузії як конфігурацію, що перевіряється: зберігайте їх поруч із фіксами, які фіксують запитання, списки кандидатів та очікуваний ідентифікатор лідера. Коли хтось „налаштовує“ ваги у нотатнику, вимагайте PR, який оновить ці фікси, щоб регресії не залишалися прихованими у „кочових“ знаннях.

Розглядайте ваги фузії як конфігурацію, що перевіряється: зберігайте їх поруч із фікстурами, які фіксують запитання, списки кандидатів та очікуваний ідентифікатор лідера. Коли хтось „налаштовує“ ваги у ноутбуці, вимагайте PR, який оновить ці фікстури, щоб регресії не залишалися прихованими у „племінних“ знаннях.

Розглядайте ваги фузії як конфігурацію, що перевіряється: зберігайте їх поруч із фіксами, які зафіксовують запитання, списки кандидатів та очікуваний ідентифікатор лідера. Коли хтось „налаштовує“ ваги у ноутбуці, вимагайте PR, який оновить ці фікси, щоб регресії не могли ховатися у „племінних“ знаннях.

Усі статті Надіслати бриф