Що таке граф знань та як їх приміряти в Agentic RAG із LLM

Усі статті, обговорення, новини про AI — в одному місці. Підписуйтеся на DOU | AI!

Одним зі способів полегшення пошуку взаємопов’язаної та релевантної інформації з додатковим контекстом для запиту користувача в RAG додатках із ШІ є використання бази даних Knowledge Graph, яка збирає дані в повʼязані мережі. Наприклад, Neo4j, FalkorDB або Nebula Graph.

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

Графи знань проти пошуку подібності в неструктурованих векторних базах даних

Векторні бази даних (Vector DB) і пошук за схожістю між фрагментами (Chunks) тексту пропонують значні переваги для застосунків ШІ та RAG/Agent. Пошук Chunks за схожістю може витягувати семантично схожі фрагменти інформації з неструктурованих даних, що дозволяє збагачувати контекст для застосунків ШІ та підвищувати якість відповідей Large Language Models (LLM). Найбільш помітною перевагою пошуку за схожістю є його здатність працювати без будь-якої попередньо визначеної схеми чи знань про дані. Він завжди забезпечує певний рівень результату незалежно від запиту. Однак це буває і недоліком, оскільки результати не завжди є точними.

Існують методи, які полегшують цю проблему та покращують результати векторного пошуку такі як переранжування та критичне оцінювання, підбір оптимального розміру чанків, та додавання метаданих та фільтрація, але ці кроки не обовʼязкові і навіть виконавши їх векторний пошук схожості має свої обмеження. Наприклад, він не здатен відповісти на питання, що охоплюють кілька фрагментів тексту або весь масив даних. Він не справляється з питаннями на кшталт «Скільки разів у книзі згадується Холмс?». А також з питаннями, що вимагають розуміння ідей, частини яких «горизонтально» пронизані та повʼязані скрізь увесь текст. Попри недоліки, простота пошуку схожості у Vector DB та той факт, що він завжди працює, зробили такий підхід досить популярним і незамінним механізмом збагачення контексту для відповідей LLMs при створенні різноманітних застосунків ШІ.

Пошук за схожістю також неефективний для вилучення непрямих зв’язків між об’єктами з «багаторівневими» зв’язками. Наприклад, особа, яка знає особу, яка відвідувала певне місце. Саме тут структурована інформація має перевагу. Структуровані бази даних можуть обробляти складні запити та відстежувати зв’язки між різними частинами даних, надаючи повнішу і точну відповідь. Але вони мають схему і правила, як вставляти та витягувати інформацію. Це робить їх більш складними, ніж пошук за схожістю у векторних БД.

Онтологія

Якщо ви знайомі з термінологією Schema з реляційної БД, це схожий термін, але для вільного тексту та простішої структури даних, ніж SQL.

Так само як і у випадку зі схемою SQL, онтологія є формою класифікації, організації та індексування знань у групи або типи для полегшення пошуку цієї інформації.

Розглянемо цей приклад: «Andre летить у Париж». Розділимо на три частини:

• «Andre» — це суб’єкт (Вузол/Node);
• «летить у» є відношенням (Звʼязок/Relationship);
• «Париж» — це об’єкт (Вузол/Node).

Вузол представляє такі сутності, як місце, особа, організація тощо. Відношення представляє зв’язок між цими сутностями, як-от залежності чи власники.

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

• субʼєкт може бути з міткою: Людина або Машина;
• звʼязок двох категорій: «ДІЄ» і «МАЄ»;
• об’єкт це: місто або машина.

Це наша схема — наша онтологія. Коли ви створюєте граф знань, потрібно створити онтологію для даного тексту. Побудуйте онтологію з сутностями («Париж», «Andre», «Volvo V70») або концептами («Місто», «Людина», «Автомобіль»).

Існують напрацювання, як створити онтологію за допомогою моделей LLM без залучення людей. Це також може бути місцем для незначного вдосконалення, а ми хочемо накопичити якомога більше дрібних удосконалень, оскільки всі вони разом створюють кращий продукт. Тому перевіряйте такі автоматично створені онтології.

Я хотів би підкреслити універсальність баз даних графів знань (KGDB). Вони вміють працювати з різними типами даних, включаючи зберігання пов’язаних знань, витягнутих з неструктурованих текстових даних, таких як книга, напівструктурованих даних і структурованих таблиць, таких як CSV-файли. Крім того, деякі KGDB (Neo4j, SurrealDB і FalkorDB) можуть функціонувати як векторні бази даних. Це підвищує їхню гнучкість і розширює можливості використання зі штучним інтелектом. І Neo4j, і FalkorDB підтримують мову запитів Cypher Query і протокол доступу Bolt.

У порівнянні з реляційними базами даних, KGDB може продемонструвати вищу продуктивність, особливо коли очікується велика кількість операцій SQL Join. KGDB використовує знання, пов’язуючи вузли зі зв’язками, і не покладається на індексування табличної інформації, як реляційні БД. Тому, якщо потрібно витягти понад п’ять рівнів глибоких ієрархічних операцій з’єднань зі зв’язками «батьки-нащадки», або сформувати запити, що включають більш як 500 ідентифікаторів з’єднань, KGDB буде ефективнішим вибором. Крім того, KGDB здійснює повнотекстовий пошук в індексі, що полегшує пошук даних без знання схеми.

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

• якщо ви плануєте зберігати лише структуровані дані, реляційна БД забезпечить кращу продуктивність та універсальність, а головне — мова SQL для запитів буде звичнішою, ніж Cypher.
• Деякі KGDB, такі як Neo4j, FalkorDB та SurrealDB, мають набір основних векторних операцій, що робить їх універсальними БД. Однак вони можуть бути не такими швидкими у пошуку даних, як спеціалізовані векторні БД, і обмежені у можливостях, у порівнянні із спеціалізованими векторними базами такими як як Milvus, Chroma або Weavite. Крім того, Neo4j має обмеження вимірності 4,096. Що є досить великим і має бути достатнім для майже всіх завдань, але в деяких випадках буває незручним. Neo4j наразі не вміє використовувати векторний індекс у поєднанні з попередньою фільтрацією; можна застосовувати лише пост-фільтрацію у поєднанні з векторним індексом. Хоча SurrealDB не підтримує мову запитів Cypher Query, яка дуже схожа на традиційний SQL, але не є такою самою й іноді має погану документацію.
• KGDB скоріш не підходить для мультимедійного контенту. Натомість краще використовувати Vector DB або щось інше.

Ви зберігатимете всі ці типи даних у різних місцях і бекендах. Наприклад, текстові файли — в KGDB, векторній БД, або в обох сховищах. Табличні дані, ймовірно, в реляційній БД.

Неповний граф

Насправді у більшості випадків ви отримаєте свій Граф знань з онтологією, яка, як виявиться, не повністю охоплює ваші дані. Отже, швидше за все більшу частину часу ви матимете неповний граф. Тож інші засоби все ще можуть бути корисними для супроводу графу знань. Саме тоді нам знадобиться резервний план  —  вектори. Крім того, якщо ви зберігаєте та оброблюєте відгуки користувачів, можете автоматично або напівавтоматично витягувати додаткові метадані та онтологію свого набору даних, збагачуючи граф.

На щастя, бази даних Graph, на відміну від SQL/реляційних баз даних, називаються «без схем». Не найкраща назва (якщо ви запитаєте мене, я б назвав це «схема пізніше») оскільки ваша задача мати якомога повнішу схему/онтологію, щоб отримати більш значущу інформацію з великого набору даних. Тож підхід «схема пізніше» дозволяє гнучко додавати вашу онтологію по ходу роботи, покращуючи та витягуючи все більше і більше інформації з вашого набору даних з часом.

Вектор, граф та LLM

Можна подумати, що векторні бази даних і Graph DB несумісні. Цікаво, що їхнє поєднання здатне дати кращі результати.

Один із підходів  — збагатити ваш граф знань для першої фази RAG. Уявіть, що у вас є великий набір тексту. Скажімо, повне зібрання творів сера Артура Конан Дойля. LLM проаналізує текст і створить онтологію або схему для його книг. Однак цей процес може призвести до створення синонімів вузлів і зв’язків, а також до непов’язаних сутностей, які виглядають схожими.

Щоб розв’язати цю проблему, вставте всі сутності з вузлів і зв’язків у векторний простір. Модель Embeddings розташує схожі сутності близько одна до одної у векторній БД. Потім ідентифікуйте близькі пари та порівняйте їх за допомогою оцінки парної подібності (Pairwise) з LLM, щоб визначити, чи вони справді є синонімами. Повторюючи цей процес, ідентифікуйте пари синонімічних сутностей, зменшуючи втиірність та шум.

І навпаки, ви можете взяти інформацію з вашого вже наявного графа знань, щоб використовувати його для збагачення метаданих до фрагментів у векторній БД. Ці метадані допоможуть відфільтрувати фрагменти, що стосуються запиту користувача. Наприклад, якщо запит користувача містить 2024 рік, а ваші фрагменти мають в метаданих тег «рік=2024», відфільтруйте та шукайте лише фрагменти з указаним роком. А потім шукайте подібності лише серед них, зменшуючи шум.

Розріджені та Густі Графи

Оскільки це досить новий напрямок, термінологія ще не зовсім стала. Терміни розріджений (sparse) та густий (dense) графи ще можна зустріти як малий та великий граф. Останні дві назви, як на мене, дуже погана ідея. Ці терміни плутають і ведуть в неправильному напрямку розуміння цих сутностей.
Для розуміння різниці між густим та розрідженим графами уявіть текст будь-якої книги. Ми можемо витягнути з неї тільки людей та місця, в той час як там містяться ще й події, концепти тощо. Витягнувши лише дуже лімітовані типи даних, ми зможемо створити граф, який називають «розрідженими». У той же час, якщо ми витягуємо з тексту усю можливу доступну інформацію, це дає створити «густий» граф.
Не дивлячись на ніби більшу перевагу «густих» графів, на практиці (принаймні наразі) вони менш оптимальні. Тому що створюють складнощі в здобуванні інформації. Для таких даних тяжко побудувати конвеєр RAG, який би автоматично створював запити до KGDB, щоб діставати ці дані. Друга проблема — LLM, витягнувши і підставивши додаткову (не значиму) інформацію, збережену в базі, як контекст, може заплутати LLM.

Висновки

Важливо розуміти свої дані та як з ними працювати. Введення додаткового контексту, як правило, забезпечує кращі результати. Граф знань допомагає знаходити взаємопов’язану інформацію з додатковим контекстом. На відміну від векторних баз даних, графи знань не лише індексують інформацію, але й встановлюють логічні залежності між сутностями в тексті. Бази даних графів знань (KGDB) є універсальними, працюють з різними типами даних і можуть функціонувати як векторні бази даних.

Вони перевершують реляційні бази даних у продуктивності, особливо при великій кількості SQL Join операцій. KGDB використовують знання для зв’язування вузлів і можуть виконувати повнотекстовий пошук, що робить їх ефективними для глибоких ієрархічних запитів. KGDB мають обмеження. Для структурованих табличних даних реляційні БД можуть бути продуктивнішими і зручнішими. Структуровані бази даних кращі для складних запитів, але мають і складніші схеми та правила. KGDB можуть бути неефективними для мультимедійного контенту.

Граф знань часто буває неповним, тому варто використовувати резервні засоби (вектори). Бази даних Graph є «без схем», що дозволяє гнучко додавати онтологію протягом роботи, збагачуючи дані та покращуючи інформацію.

Векторні бази даних і пошук за схожістю корисні для ШІ та RAG/Agent застосунків, бо дозволяють витягувати семантично схожі фрагменти без схеми. Це спрощує роботу, але іноді призводить до неточних результатів. Недоліки містять нездатність обробляти запити, що охоплюють кілька фрагментів або складні питання. Векторний пошук неефективний для непрямих зв’язків між об’єктами.

Поєднання векторних баз даних і Graph DB здатне дати кращі результати. Можна збагатити граф знань, вставивши сутності у векторний простір. Модель Embeddings допоможе розташувати схожі сутності близько, а LLM визначить синоніми, зменшуючи шум. І навпаки, граф знань здатен збагачувати метадані у векторній БД для кращого фільтрування даних, що підвищує точність пошуку.

Підтримка

Якщо вам сподобалася ця стаття і ви хочете підтримати мене:

1. Натисніть «Подобається 👍» та додайте «До обраного ⭐️» мою статтю; це допоможе мені. Також слідкуйте за мною на DOU, щоб отримувати останні статті.
2. Дайте відгук у коментарях нижче, навіть якщо це просте «дякую» — це допоможе мені розуміти, що моя робота була не марною. Якщо є помилки, скажіть де, а найголовніше як виправити, не претендую на роль всезнайки.
3. Шукаю ентузіастів та однодумців, що знаються на Python та NLP і хотіли б втілити описані ідеї та моїх статтях у життя, і, можливо, навіть зробити сумісний проєкт. Напишіть мені в LinkedIn. На разі працю над PoC, який використовує описані принципи у моїх статтях з побудови RAG та KG. Буду радий поділитись своїми напрацюваннями й знаннями.