Сила графів знань для ШІ в застосунках RAG. Частина 2
Ця стаття написана здебільшого як «мозковий дамп», який допомагає мені структурувати інформацію в голові, а також, щоб відкрити на цю тему дискусію, яка часто буває не менш цінною, ніж сама стаття.
Оскільки цей напрямок дуже новий і наші знання в ньому ще формуються, матеріал буде цінний не лише як джерело нової інформації та навчання, а і як можливість для читачів поділитись власним досвідом. Що стимулюватиме розвиток ШІ та формуватиме нову методологію побудови графів знань та RAG.
Написання статті значною мірою надихнув Томаж Братаніч (Tomaž Bratanič), хочу сказати йому величезне спасибі!
Коли використовувати графи знань в RAG
Якщо наше завдання — знайти, наприклад, скільки разів Шерлок Холмс відвідав Бейкер-стріт, граф знань буде кращим варіантом (за умови, що автор прямо в книзі цього не написав). Адже ми можемо побудувати запит до бази даних, яка порахує усі такі події (за умови, що ми їх витягнули із книги та зберегли в базі).
Надавши таку підраховану відповідь у контекст LLM, ми побачимо, що її якість очевидно буде набагато кращою за векторний пошук.
Граф застосовують у випадках, коли простий пошук у векторній базі й повернення декількох чанків не є достатнім інструментом. Тобто коли ми не можемо відповісти на питання користувача, бо його написано в тексті не явно. Графи також потрібні, коли інформація дуже сильно розмазана по багатьох частинах тексту, прихована або неочевидна, і треба зробити складніший запит в базу. А також коли запит користувача потребує точної й чіткої відповіді, часто — кількісної або зі складними звʼязками.
Наприклад: «Виведи усі назви локацій, де жертва розслідування Холмса була жіночої статі та мала сестру-близнючку». Якщо відповідь навіть і міститься в чанках, але, наприклад, у 100 фрагментах, а в RAG налаштовано повертати тільки перші Top K = 10 із векторної бази, то результат буде неповним або навіть неправильним.
На запит «Cкільки разів Гелен Стоунер відвідала Бейкер-стріт, коли там була присутня місис Хадсон?» векторний пошук теж не здатний надати точну та адекватну відповідь, а головне таку, яку можна легко перевірити, якщо цього не було написано автором книги напряму. Так само з питанням, де треба знайти усі складні звʼязки. Наприклад: «Видай список усіх знайомих знайомих, кого Шерлок Холмс знав через когось, другого та третього рівнів. Тобто знайомих знайомих знайомих, яких він не знав особисто».
MATCH (p:Person) -[:HAS_FRIEND*2..3]-> (friend:Person) RETURN DISTINCT friend
Цей запит досить легко читати. Можу тільки додати, що MATCH у мові запитів Cypher виконує схожу функцію з SELECT у мові SQL. Де p та friend — це змінні. Замість них можна написати що завгодно, а :Person — це тип ноди.
Якщо ми знайшли чанк/шматок тексту або пару чанків схожого тексту і цього буде достатньо для відповіді, тут краще підійде пошук подібності у векторній БД. Наприклад, коли користувач питає «Де Шерлок Холмс почувався найкраще?» За умови, що в тексті книги це було вказано явно.
А як спершу знайти ноду Шерлок Холмс чи Гелен Стоунер в графі? Як вони там представлені? Адже користувач при наборі тексту міг припуститися помилки в імені або вказати його в скороченій формі. Не так, як нода збережена в графі. Тут теж буде корисним векторний пошук подібностей.
📌
Читайте в моїй попередній статті: Що таке граф знань та як їх застосовувати в Agentic RAG із LLM. Частина 1.
Сила графів знань
Графи знань (Knowledge Graph, KG) пропонують спрощений і гнучкий спосіб пов’язувати й структурувати інформацію, роблячи її природно зрозумілою для людини. На відміну від структурованих табличних даних з жорсткими схемами та типами даних, графи знань дозволяють розміщувати неповну і навіть суперечливу інформацію. Хоча ці характеристики можуть здатися недоліками, насправді вони добре пристосовані до особливостей людських знань, які часто є суперечливими та неповними.
KG більш адаптовані до проблеми «сміття на вході, сміття на виході». Тобто вони є настільки якісними, наскільки якісними ви їх створили, і мета цієї статті — описати кроки та рекомендації щодо створення якісних KG.
Графи знань є неоціненними для відповіді на запитання в кілька етапів, аналітики в режимі реального часу та інтеграції структурованих і неструктурованих даних в єдину базу даних.
Триплет складається із двох нод і одного направленого звʼязка між ними. Нода може бути імʼям людини, локацією, назвою компанії тощо. Детальніше про це нижче.
(Шерлок) -[:HAS_FRIEND]-> (Ватсон)
Кожна нода може мати багато звʼязків з іншими нодами. Мінімальна одиниця триплету виглядає так: в круглих скобках відображено дві ноди та у квадратних направлений звʼязок між ними. У фігурних лапках ми можемо додати властивості нод та звʼязків:
CREATE
(Шерлок: Person {fullname: 'Шерлок Холмс', birthday: 'January 6, 1854', nationality: 'British'}),
(Baker211B: Location {address: '221B Baker Street, London, UK'}),
(Ватсон: Person {fullname: 'Доктор Ватсон'}),
(Шерлок) -[:RESIDED_IN {years: '1881-1904'}]-> (Baker211B),
(Шерлок) -[:HAS_FRIEND]-> (Ватсон)
(Ватсон) -[:HAS_FRIEND]-> (Шерлок)
Якщо ви знайомі із SQL, проведімо паралель із мовою запитів Cypher. Для початку розглянемо ноди: ви можете сприймати назву ноди Шерлок як «колонку» з унікальним ідентифікатором в таблиці Person, тоді fullname, birthday, nationality — це додаткові колонки.
Рухаємося далі та розглянемо триплет. Уявіть собі це як проміжну таблицю many-to-many, де ви зберігаєте звʼязки між двома нодами. Різниця тільки в тім, що у нас немає таблиці, яка обʼєднує записи в БД за спільними характеристикама чи колонками. Це окремі ноди, які можуть мати довільні звʼязки з іншими нодами.
📌
Про роботу LLM із SQL читайте в моїй попередній статті: Wren AI Text-to-SQL: UI та API, або Як спростити роботу з реляційними базами в застосунках RAG/Agent.
Більшість людських знань зберігається в неструктурованих формах. Хоча структуровані табличні дані з реляційних баз даних зі жорсткими схемами можуть зберігатися в KG, не всі дані KG можуть бути перетворені в табличну форму.
Розглянемо приклад отримання даних з художньої книги: головні герої, місця, які вони відвідали, їхні характеристики та дії — все це можна представити в KG. Однак більшу частину цієї інформації нелегко перетворити в табличний формат. Графи знань чудово підходять для збору та організації складної інформації такого типу. Вони структурують її в більш гнучкий і всеосяжний спосіб для зберігання та аналізу людських знань.
📌
Читайте в моїй попередній статті більше про Vector DB, пошук схожості, RAG та агентів: Еволюція ботів з ШІ: використовуємо можливості агентів, моделей RAG і LLM.
Схема побудови графа з інформації
Щоб перетворити інформацію на знання, нам потрібно структурувати дані. Оскільки ми маємо неструктуровані дані, дуже важко зробити їх структурованими в традиційній табличній формі, оскільки при такому представленні деяка інформація може бути відсутньою або не повністю узгодженою.
Тому варто використовувати найменшу можливу міру структуризації KG: триплети. Триплети складаються з двох вузлів (вершини), з’єднаних відношенням (ребрами) з напрямком. Багато триплетів, які пов’язані або не пов’язані у великі ланцюги, утворюють граф.
На картинці зображено граф знань про лікарні та їхніх лікарів. Вузол «Лікар» має набір властивостей, наведених праворуч на малюнку.
Визначення співвідношень
Визначення співвідношень (Coreference Resolution, CR) визначає всі вирази, які посилаються на один і той самий вузол, хай то сутність, рівень або концепт. Зокрема, цей процес знаходить займенники та замінює їх відповідними вершинами посилань.
Займенниками можуть бути такими:
— Особа або предмет. Наприклад: він, вона, вони, воно.
— Місце, що вказує на географічні позначення. Наприклад: тут, там, скрізь.
— Присвоєння, що вказує на позначення власності. Наприклад: мій, твій, їхній.
Приклад: «Шерлок Холмс, відомий у літературі детектив, мешкав на Бейкер-стріт, 221Б з 1881 по 1904 рік. Він був відомий своєю винятковою дедукцією, криміналістикою та навичками критичного мислення». Eng: «Sherlock Holmes, the famous fictional detective, resided at 221B Baker Street from 1881 to 1904. He was known for his exceptional deduction, forensic science, and logical reasoning skills. »
Розв’язання проблеми визначення співвідношень, яку до недавнього часу вирішували бібліотеки НЛП, такі як stanfordnlp/CoreNLP, F-Coref (FastCoref, LingMess), чи розширення фреймворків типу spaCy (Fastcoref, NeuralCoref або Crosslingual Coreference), розвинулося з появою великих мовних моделей (LLM).
Сучасні
from fastcoref import FCoref model = FCoref(device='cpu') <em>#OR for Nvidia FCoref(device='cuda:0')</em> preds = model.predict( texts=['Fastcoref is a great package. I am glad Damien Berezenko introduced it to me. He is a good engineer.'] ) preds[0].get_clusters() print(preds[0].get_clusters()) [['Fastcoref', 'it'], ['I', 'me'], ['Damien Berezenko', 'He']]
Визначення (екстракція) вузлів
Спираючись на текст з визначеними співвідношеннями перетворенням посилань, ми можемо виокремити вузли за допомогою методів розпізнавання іменованих об’єктів (NER), рівнів і концептів. Кожен ідентифікований вузол класифікується за його типом, таким як NER, концепція або рівень, що може бути збережено як властивість вузла.
Використання можливостей LLM є ефективним методом для досягнення високої точності в цьому процесі. Вузли можуть бути класифіковані як суб’єкти, які діють на об’єкти, або як самі об’єкти.
Приклади типів NER включають:
- Особа. Імена фізичних осіб.
- Компанія. Назви організацій.
- Місцеперебування. Географічні місця.
- Геополітичні об’єкти. Країни, регіони або міста.
Рівні зазвичай стосуються ієрархічних позицій або рангів у структурі. Вони представляють різні яруси або етапи в системі, організовуючи вузли в певному порядку від загального до конкретного. Наприклад, у корпоративній ієрархії рівні можуть бути такими: «керівник», «менеджер», «працівник».
Концепти — це абстрактні ідеї або категорії, які інкапсулюють певні атрибути або властивості. На відміну від рівнів, концепти не визначають позицію в ієрархії й можуть охоплювати декілька рівнів. У графі знань прикладами концептів є «штучний інтелект», «вища освіта», «кліматичні зміни» та «квантова фізика».
Концепції може бути складніше виокремити, і якщо ви вирішили їх зафіксувати, варто позначати як такі, що можуть змінюватися з часом (так званий «зсув концепції», детальніше розкрию у наступній статті).
Приклад графа, що представляє академічну установу:
Іменовані обʼєкти (NER)
- Університет: Херсонський національний технічний університет
- Факультет: Інформаційних технологій та дизайну
- Кафедра: Комп’ютерних систем та мереж
- Курс: Цифрова математика
Рівні
- Університет (вищий рівень)
- Факультет (наступний рівень вниз)
- Кафедра (ще нижче)
- Курс (нижній рівень)
Концепції
- Вища освіта. Поширюється на весь заклад.
- Наукові дослідження: Актуально на рівні університету, факультету та кафедри.
- Цифрова математика. Галузь дослідження, яка може бути в центрі уваги на факультеті або курсі.
Висновки
Побудова графу знань із вільного тексту складається із декількох етапів. Coreference Resolution — дуже важливий перший крок для підвищення якості створеного графа. Coreference Resolution та Node Extraction часто поєднують в одному кроці. Набір утиліт постійно змінюється і покращується, що дозволяє будувати якісніші графи. Граф може надати більшу якість та деталізацію, аніж векторний пошук, але обидва часто доповнюють один одного.
В наступній статті про Knowledge Graph продовжимо розглядати побудову зв’язків, властивостей нод, зсув знань, wikification та уточнення знань, а також онтологію та кластеризацію нод із векторним пошуком для RAG retrieval.
Meetup кожну середу, починаючи з 25.09.2024. Запрошую в голосовий чат Discord обговорити графи знань, RAG та ШІ кожну середу о 20:00 за Києвом, починаючи із 25 вересня. iCal 📆.
Подяка
Хочу виразити подяку співавторам за коментарі та вичитку тексту:
Окремо виражаю подяку редакції DOU за можливість розмістити мій топік, що закликав приєднатись до співавторства та допоміг знайти усіх цих чудових людей!
Підтримка
Якщо вам сподобалася ця стаття і ви хочете підтримати мене:
- Натисніть «Подобається 👍» та додайте «До обраного ⭐️» мою статтю; це допоможе мені. Також слідкуйте за мною на DOU, щоб отримувати останні статті.
- Дайте відгук у коментарях нижче, навіть якщо це просте «дякую» — це допоможе мені розуміти, що моя робота була не марною. Якщо є помилки, скажіть де, а найголовніше як виправити, не претендую на роль всезнайки.
Шукаю Rust/Python розробника для стартапу що знається на NLP та має досвід роботи із моделями hugging face і хотів би втілити ідеї про графи знань та RAG описані в моїх статтях. Напишіть мені в LinkedIn або Discord. На разі працю над PoC, який використовує описані принципи у моїх статтях з побудови RAG та KG. Буду радий поділитись своїми напрацюваннями й знаннями.
Mykhailo
Олександр Мельник
4 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів