З’єднання Разом: Агентський RAG та Графи Знань – Ваш Шлях до Ефективного Пошуку у Світі ІІ

З’єднання Разом: Як ІІ-Агенти та Графи Знань Перетворюють Пошук Інформації

За чашкою кави, як я часто буває, я поринула у захопливий світ розробок штучного інтелекту. Цього разу моя «мандрівка» зосередилася на пошукових стратегіях для ІІ-агентів. Я прагнула знайти найкращий спосіб надати моїм програмам можливість досліджувати та розуміти великі обсяги інформації. І ось що привернуло мою увагу: агентський RAG та графи знань.

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

У цьому відео я розкрию секрети створення досконалого шаблону агентів, що показує силу поєднання векторних баз даних та графів знань для пошуку інформації, що сприяє генерації (RAG). Ми почнемо з демонстрації, щоб відразу відчути силу цієї технології. Потім ми перейдемо до пояснення, чому агентський RAG і графи знань працюють саме так ефективно. Я покажу, як працює агент, і навіть поділюся з вами, як я використовувала Claude Code, щоб створити цей чудовий шаблон.

Отже, давайте почнемо!

Демонстрація на Власні Очі: Швидкий Огляд Сили

Почнімо з конкретного прикладу. Я створила простий інтерфейс командного рядка, який взаємодіє з моїм агентом через API-шлюз. Цей агент, що працює за технологією агентського RAG, має доступ як до векторної бази даних, так і до графа знань через спеціальні інструменти. Він може вибирати, як саме досліджувати інформацію, що я ввела в базу даних.

Давайте подивимось, як це виглядає.

Для моєї векторної бази даних я використовую PostgreSQL з розширенням PGVector. Це SQL-база даних, яка дозволяє зберігати вектори. Я використовую платформу Neon для PostgreSQL, яка дуже зручна. Тут я зберігаю вбудовані представлення (embeddings) для всіх фрагментів моїх документів, як це відбувається в традиційному RAG. В даний момент у мене є лише один документ у моїй базі знань. Він стосується ініціатив великих технологічних компаній, таких як OpenAI і Microsoft. Я розбила цей документ на частини, створила їх вбудовані представлення та зберегла в Neon.

Але це ще не все! Я також створила інформацію про компанії в графі знань, використовуючи реляційний підхід. Це дає агенту можливість досліджувати інформацію з різних сторін. Наприклад, Amazon пов’язана з Anthropic, адже Amazon інвестувала в цю компанію. До речі, вся інфраструктура Anthropic працює на AWS. Також можна побачити, як Microsoft співпрацює з OpenAI, оскільки OpenAI використовує Azure для розміщення своїх моделей.

Це чудовий приклад ситуації, коли корисно використовувати і векторну базу даних, і граф знань. Якщо ми хочемо проаналізувати ініціативи у сфері ІІ для великих компаній, важливо враховувати їхню спільну діяльність, як між Amazon та Anthropic, або OpenAI та Microsoft. Але якщо ми просто хочемо знайти інформацію про конкретну компанію, наприклад, Google, краще використовувати векторну базу даних.

Саме таке мислення міститься в основі нашого агента – він може вирішувати, який інструмент використовувати для кожного типу питання.

Отже, ми можемо поставити питання, наприклад: “Які ініціативи Google в області ІІ?” Під капотом агент виконає пошук по векторній базі даних. Граф знань в цьому випадку не потрібен. І ось відповідь: все виглядає чудово!

Давайте розглянемо ще один приклад. Я можу поставити питання про взаємозв’язок двох компаній – те, що безумовно потребуватиме пошуку по графу знань. Наприклад: “Як пов’язані OpenAI та Microsoft?” Хоч це і може бути просте питання, але воно показує, як агент звертається до графа. Отже, цього разу він використовує пошук по графу, звертаючись до зв’язків. І ми отримуємо відповідь про Azure, як про єдиний постачальник моделей OpenAI, як ми бачили на панелі Neo4j.

І ще один приклад. Я хочу поставити питання, яке потребує використання обох типів пошуку: “Які ініціативи Microsoft та дотичність до Anthropic?” Тут ми використовуємо як векторний пошук, так і пошук по графу. Ми спочатку шукаємо ініціативи Microsoft, а потім порівнюємо їх з Anthropic, щоб побачити можливу взаємодію.

Цей агентський RAG є частиною шаблону, який я створила для вас. Технічний стек, який я використовувала, містить наступні інструменти:

• Pydantic AI: фреймворк для мого ІІ-агента. Без нього ніяк.
• Graffiti: наша бібліотека для графа знань, що працює з Neo4j.
• Neo4j: основний рушій графа знань, це інтерфейс, який ми бачили раніше з вузлами.
• PostgreSQL з PGVector: перетворює SQL-базу даних на векторну базу даних.
• FastAPI: для створення API-інтерфейсу агента на Python.
• Claude Code: інструмент, що допоміг мені створити цього агента.

У кінці відео я покажу, як я створила цей шаблон за допомогою Claude Code. Тож не пропустіть!

Заглиблення в Агентський RAG: Еволюція Пошуку

Сподіваюсь, з демонстрації ви зрозуміли, наскільки потужним є підхід з використанням агентського RAG (Retrieval-augmented generation). Але мені хочеться ще поговорити про те, як RAG еволюціонував і чому графи знань відіграють важливу роль.

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

Перший підхід – це так званий “ванільний RAG.” Його ще називають наївним або класичним RAG. Процес досить простий: беремо документи, розбиваємо їх на фрагменти, використовуємо модель вбудовування, щоб створити векторне представлення інформації. Потім зберігаємо ці вектори у векторній базі даних. Коли користувач робить запит до нашого ІІ-агента, ми також пропускаємо цей запит через модель вбудовування. Це дозволяє нам знайти у векторній базі даних фрагменти документів, найбільш схожі на запитання користувача. Ці фрагменти використовуються як додатковий контекст для нашого ІІ-агента – вони стають частиною запиту до великої мовної моделі. Таким чином, у великої мовної моделі з’являється додаткова інформація для відповіді на запитання.

На перший погляд, все добре, але наївний RAG майже ніколи не є достатнім, тому що він надзвичайно гнучкий. Уявіть собі потік даних: запит користувача потрапляє в систему, ми створюємо його вбудоване представлення, отримуємо відповідний контекст з векторної бази даних, а потім передаємо все це великій мовній моделі. І тут виникає проблема: агент змушений використовувати цей контекст, незалежно від того, чи хоче він цього чи ні. Що робити, якщо агент хоче уточнити свій пошук або провести глибше дослідження? Якщо у нас є кілька джерел знань, у агента немає можливості зробити це.

Ось тут і приходить на допомогу агентський RAG. Він дає агенту можливість розмірковувати над тим, як досліджувати базу знань, а не просто примусово передавати контекст наперед. Нам дозволено визначати запити, агент може обдумувати, як він буде їх формулювати для RAG. Він може використовувати різні векторні бази даних, веб-пошук як додаткове джерело інформації.

Агенти можуть розмірковувати про те, яке джерело використовувати, що, на мою думку, є дуже потужним інструментом.

Саме це ми і створили – систему з векторною базою даних та графом знань. Тепер ми можемо почати налаштовувати сам шаблон. Покажу вам, як все налаштувати, як додати документи у граф знань та векторну базу даних.

Розгортаємо Агента: Покрокова Інструкція

Я дуже рада представити вам цей шаблон агентського RAG з графом знань. Я витратила багато часу на його створення, і зараз ви зможете його легко налаштувати. Ви отримаєте той самий агент та інтерфейс командного рядка, що бачили в демонстрації.

Усі необхідні посилання на GitHub ви знайдете в описі під цим відео.

Якщо ви хочете створити свій проект самостійно, просто дотримуйтесь інструкцій. Процес досить простий.

Вимоги:

• Python.
• База даних PostgreSQL (наприклад, Neon, яку я використовую).
• База даних Neo4j.
• API-ключ вашого постачальника LLM. Цей агент підтримує різні API-сумісні з OpenAI, такі як OpenAI, Olama для локальних LLM.

Кроки:

1. Створення віртуального середовища: У терміналі створити віртуальне середовище:
   bash python -m venv .venv
   та встановити всі залежності за допомогою pip:
   bash pip install -r requirements.txt

2. Налаштування бази даних SQL (PostgreSQL): Потрібно підготувати базу даних SQL для зберігання векторів. Для цього ми використовуємо PostgreSQL з розширенням PGVector. Перейдіть до папки SQL та скопіюйте SQL-код з файлу. Зверніть увагу на деякі нюанси: якщо ви використовуєте іншу модель вбудовування, вам потрібно буде оновити розмірність вектора в коді. Цей SQL-файл видалить та створить заново таблиці.

   Створіть безкоштовний обліковий запис на Neon (neon.tech). Перейдіть на вкладку редактора SQL та вставте скопійований код. Запустіть SQL код у вашій базі даних, щоб створити таблиці та розширення.

3. Налаштування Neo4j: Існує два способи налаштування Neo4j:

   • Локальний AI пакет: Використовуємо мій пакет localAI, який містить різне безкоштовне програмне забезпечення (Neo4j, LLM) в зручному пакеті.
   • Neo4j Desktop: Встановіть Neo4j Desktop за посиланням.

   В обох випадках ви отримаєте ім’я користувача та пароль, які будуть потрібні для налаштування .env файлу.

4. Налаштування .env файлу:
   Створіть копію файлу .env.example та перейменуйте її на .env. В цьому файлі треба вказати параметри для підключення до баз даних та налаштування великих мовних моделей. Давайте пройдемося по всіх значеннях:

   • DATABASE_URL: URL вашої бази даних PostgreSQL. Знайти його можна на панелі керування Neon (в розділі Connect).
   • NEO4J_URI: За замовчуванням bolt://localhost:7687.
   • NEO4J_USERNAME: Ім’я користувача для Neo4j.
   • NEO4J_PASSWORD: Пароль для Neo4j.
   • LLM_PROVIDER: Постачальник великої мовної моделі (OpenAI, Open Router, Olama, Gemini).
     • OPENAI_BASE_URL: Базовий URL для OpenAI, для Olama – http://localhost:11434/v1.
     • OPENAI_API_KEY: Ваш API ключ для OpenAI. Для Olama – просто Olama.
   • LLM_MODEL: Модель для використання. За замовчуванням GPT4.1-Mini.
   • EMBEDDING_PROVIDER: Постачальник для вбудовування (аналогічно, OpenAI, Gemini).
     • EMBEDDING_BASE_URL: Базовий URL (OpenAI – за замовчуванням).
     • EMBEDDING_API_KEY: Ваш ключ.
     • EMBEDDING_MODEL: Модель вбудовування (наприклад, text-embedding-3-small).
   • INGESTION_LLM_CHOICE: Модель, яка буде використовуватися для перетворення документів у граф знань та векторну базу даних. Зазвичай можна значно меншу модель. Я використовую GPT4.1-nano

   Відредагуйте всі ці параметри. Важливо, щоб файл .env був в тому ж місцязнаходження, що і скрипти.

5. Налаштування папки з документами: Створіть папку documents. Помістіть туди ваші документи у форматі Markdown. Я надаю декілька прикладів. Ці документи будуть автоматично додані у граф знань та векторну базу даних.

6. Запуск процесу додавання даних: Щоб додати дані, варто виконати наступну команду:
   bash python -m ingestion.py --clean
   Прапор --clean очистить граф знань та векторну базу даних, щоб ми почали роботу з “чистого аркуша”. Запуск цього скрипту ініціалізує зв’язок з базами даних та графом знань. Створення графа знань може зайняти деякий час, адже тут використовуються LLM для визначення сутностей та їх відносин.

   Якщо ви хочете прискорити процес, можете використовувати опцію -dont_create_graph. У такому випадку граф знань не буде створюватись.

7. Перевірка результату: Після завершення процесу додавання даних, ви можете перевірити їх наявність в базі даних PostgreSQL (у розділі Tables) та в Neo4j (за допомогою запитів Cypher).

8. Налаштування поведінки агента: Перейдіть у папку agent та відкрийте файл prompts.py. Це основний системний промт, який використовує агент. Тут визначаються інструкції щодо використання різних можливостей агента (пошук по векторній базі даних, графу знань). Також вказується, як використовувати ці інструменти. Наприклад, я вказала використання графа знань лише тоді, коли користувач запитує про дві компанії одночасно. В іншому випадку буде використовуватися векторна база даних. Ви можете змінити цей системний промт відповідно до ваших потреб.

9. Запуск API сервера: Запустіть API-сервер за допомогою команди:
   bash python -m agent.api

10. Взаємодія з агентом через інтерфейс командного рядка: Відкрийте другий термінал. Перейдіть у папку, що містить проєкт, та запустіть скрипт:
    bash python CLI.py
    Спробуйте задати питання, як ми робили в демонстрації.

Все готово!

Додаткові Команди

Ось декілька корисних команд для роботи з інтерфейсом командного рядка:

• exit або quit: завершити роботу з агентом.
• help: отримати довідку.

Як Працює Агент: Глибинна Робота

Агент використовує різні компоненти для виконання поставлених задач:

• Pydantic AI: Фреймворк для структуризації та керування агентом.
• Graffiti: Для створення та управління графом знань.
• PostgreSQL з PGVector: Для зберігання векторних даних.
• FastAPI: Для створення API інтерфейсу.
• Великі мовні моделі (LLM): Для обробки запитів, аналізу даних та генерації відповідей.

Агент використовує різні інструменти:

• Пошук по векторній базі даних: Для пошуку інформації на основі схожості векторів.
• Пошук по графу знань: Для аналізу взаємозв’язків між сутностями.
• Інструменти для роботи з API: Можуть бути додані інші корисні інструменти (наприклад, пошук в інтернеті).

Використання Claude Code для Створення Агента: За Лаштунками

На завершення, я хочу поділитися з вами, як я використовувала Claude Code для створення цього потужного агентського RAG. Звісно, це окрема тема, про яку я планую розповісти більш детально.

Мій процес включає наступне:

• Документація: Моїм AI помічником були використані MCP сервери (Model Control Plane).

  • Crawling for RAG: для завантаження зовнішньої документації.
  • Neon: для управління базою даних PostgreSQL.

• Режим планування в Claude Code: Клавішами Shift+Tab перемикаємось у режим планування, де ми можемо описати загальну структуру проєкту та список необхідних задач.

  • planning.md: опис архітектури.
  • task.md: детальний список задач.
  • claw.md: глобальні правила для Claude Code, містить інструкції щодо використання planning.md, task.md, MCP серверів.

• Перехід в режим побудови: Після створення цих файлів, повертаємось в режим побудови (Shift+Tab). Claude Code використовує planning.md та task.md для автоматичного створення коду та налаштування.

• Одобрюємо запропоновані дії: Періодично необхідно перевіряти та схвалювати дії, що запропоновані Claude Code.

• Використання прикладів: Для кращого розуміння, Claude Code може використовуватись приклади з папки examples.

Саме так я створила цього агента. Існують готові файли: planning.md, claw.md, task.md. Їх можна знайти на GitHub. Ви можете використовувати їх для власного проєкту.

Я сподіваюся, що цей відео-огляд та шаблон агентського RAG з графом знань виявились вам корисними. Якщо так, поставте лайк та підпишіться на канал. Залишайтесь на зв’язку, аби не пропускати нові відео. До зустрічі!