LLM можуть одночасно «бачити» лише обмежений обсяг тексту (ліміт контексту). Цього достатньо для невеликих завдань, але підхід перестає працювати, коли база знань налічує тисячі сторінок. Навіть за достатнього ліміту контексту продуктивність може знижуватися через проблему «голки в копиці сіна».
RAG («генерація з доповненням за допомогою пошуку») став дуже поширеним підходом: ви підтримуєте базу знань (документи, вікі, політики, стенограми тощо), виконуєте семантичний пошук за запитом користувача, щоб за допомогою ембедингів отримати найрелевантніші фрагменти, а потім передаєте їх у LLM разом із запитанням. Це обмежує контекст моделі та за належної реалізації може підвищити якість відповідей і зменшити кількість галюцинацій.
pgai — це розширення Postgres із відкритим кодом (і супутні інструменти), яке допомагає створювати процеси «пошуку для ШІ» на основі надійної бази даних PostgreSQL із відкритим кодом.
Головна ідея — перенести більше стандартних етапів RAG на рівень бази даних (завантаження → поділ на фрагменти → створення ембедингів → синхронізація ембедингів), а не використовувати БД «лише як сховище» ембедингів.
Перші враження обнадійливі, але щойно конвеєр RAG стає хоча б трохи складнішим (особливо щодо підходів до поділу на фрагменти), pgai вже не підходить. Утім, ми уважно стежитимемо за цим проєктом.
RAG можна побудувати багатьма способами. Докладніше про різні підходи читайте в матеріалі «Практичні приклади налаштованих рішень RAG». Коли важлива якість, простір можливих рішень виявляється напрочуд широким, а типовий підхід зазвичай має такий вигляд:
Візьміть набір документів.
Розділіть їх на фрагменти. Для цього існує багато методів (наприклад, поділ за абзацами або семантичне групування).
Перетворіть кожен фрагмент на ембединг.
Зберігайте ембединги у векторній базі даних (Pinecone, Milvus тощо) або в Postgres за допомогою pgvector.
Під час обробки запиту знайдіть найближчі фрагменти `і передайте їх у LLM (знову ж таки, це теж можна зробити багатьма способами).
У багатьох технологічних стеках кроки (1)–(3) виконуються поза базою даних — у коді застосунку або конвеєрі даних, а база даних переважно використовується для:
зберігання ембедингів
пошуку за ембедингами
pgai — це розширення Postgres із відкритим кодом, розроблене Timescale, яке намагається стерти цю межу.
Замість того щоб змушувати застосунок керувати ембедингами вручну, pgai перетворює їх на функцію бази даних:
Ви визначаєте, для якої таблиці або документів потрібно створити ембединги.
Ви вказуєте модель ембедингів і стратегію поділу на фрагменти.
Рештою керує pgai, зокрема оновлює ембединги відповідно до змін у вихідних даних.
Переваги звучать привабливо:
Менше спеціалізованого зв’язувального коду, який потрібно підтримувати.
Має бути простіше підтримувати ембединги актуальними, коли вихідні документи змінюються.
Postgres/pgai керує повторними спробами, обмеженнями частоти запитів, невдалими завданнями тощо.
Примітка для читача: pgai містить pgvector — ще одне дуже популярне розширення Postgres для RAG. pgvector додає до Postgres зберігання векторів і пошук за подібністю, а pgai використовує ці можливості для автоматизації таких етапів RAG, як поділ на фрагменти, створення ембедингів і підтримання їхньої актуальності.
1) Його легко запустити.
За стандартного сценарію все досить просто:
Завантажте Docker-образи Timescale (база даних і робочий процес).
Надайте ключ API свого постачальника ембедингів.
Виконайте кілька SQL-команд, щоб оголосити векторизатор (тобто що перетворювати на ембединги, як ділити дані на фрагменти та яку модель використовувати).
Після цього pgai запускає робочий процес векторизатора як окремий процес, що асинхронно створює ембединги (наприклад, кожні 5 хвилин або з будь-якою іншою заданою періодичністю).
2) Зручно, що весь конвеєр працює «поруч» із базою даних.
pgai може отримувати вміст із таблиць, а також завантажувати документи з таких сховищ, як S3, після чого аналізувати їх, ділити на фрагменти та створювати ембединги. Він також підтримує різні формати текстових документів, як-от PDF, Markdown тощо.
1) Ви значною мірою втрачаєте контроль (а для RAG він іноді необхідний).
Високоефективні системи RAG (за критерієм якості відповідей) часто потребують спеціалізованих конвеєрів, зокрема:
власних правил поділу на фрагменти (за заголовками, сторінками, репліками мовців тощо)
поділу на фрагменти з урахуванням метаданих (збереження назв розділів, часових позначок, авторів і типу документа)
різних стратегій створення ембедингів для кожного типу документів
У цих аспектах pgai пропонує менше гнучкості.
Наразі є дві основні стратегії: звичайний і рекурсивний поділ тексту за кількістю символів, а також варіант без поділу. Для деяких сценаріїв цього може вистачити, але чимало робочих систем RAG потребують ширших можливостей налаштування.
Було б чудово, якби Timescale додала складніші стратегії поділу на фрагменти, подібні до тих, що є в бібліотеках на кшталт Chonkie, а також підтримала передові підходи, як-от контекстний пошук Anthropic.
2) Насамперед текст, а не мультимодальність.
Багато цікавих завдань RAG уже не обмежуються лише текстом:
PDF-файли з діаграмами
знімки екрана та зображення
аудіозаписи
відеокліпи
Навіть якщо з цих джерел можна «видобути текст», це не те саме, що повноцінний конвеєр мультимодальних ембедингів.
Якщо згодом pgai забезпечить наскрізну підтримку мультимодальних моделей (завантаження → поділ → створення ембедингів для великих зображень, аудіо й відео в S3 із надійною синхронізацією), це буде вагомою перевагою. Однак сьогодні це процес створення текстових ембедингів.
3) Якщо вам потрібні лише ембединги, pgai може бути зайвим.
Якщо ваш конвеєр завантаження даних уже спеціалізований (або має таким бути), то «створення ембедингів для фрагментів тексту» — не найскладніша частина RAG. У такому разі pgai розв’язує найпростішу частину проблеми.
Крім того, якщо база знань оновлюється рідко, автоматична синхронізація ембедингів не настільки цінна.
Особливо вдалий спосіб використання pgai — розгорнути над базами даних інтерфейс перетворення тексту на SQL. Це досить легко зробити за допомогою модуля semantic_catalog, який пропонує pgai. Просто налаштуйте все так:
Bash
а потім запустіть збір даних із ваших словників даних у семантичний каталог командою pgai semantic-catalog create. Так буде створено контекст із вашого сховища даних, що матиме приблизно такий вигляд:
Plain Text
Тепер цей контекст доступний pgai кількома способами:
Через семантичний пошук:
Цей запит поверне таблиці, функції та інші об’єкти, які можуть стосуватися вашого запиту природною мовою:
Bash
Отримання необробленого контексту:
Буде виведено необроблений контекст YAML, пов’язаний із вашим запитом природною мовою:
Bash
Генерування SQL:
Або можна безпосередньо згенерувати необроблений SQL, потрібний для відповіді на ваш запит. Контекст із попереднього кроку надсилається до LLM, після чого генерується відповідь:
Bash
Якщо ви створюєте відносно просту систему RAG, варто спробувати pgai, якщо вам потрібні:
Postgres як основна система обліку даних,
мінімум зв’язувального коду,
ембединги, що автоматично синхронізуються,
швидкий спосіб додати до баз даних перетворення тексту на SQL,
можливість експериментувати з новими інструментами RAG і розширеннями Postgres.
Імовірно, із pgai варто зачекати, якщо вашому конвеєру RAG потрібне щось із наведеного нижче:
складна спеціалізована логіка завантаження або поділу на фрагменти
багато типів документів із різними вимогами до аналізу
мультимодальні ембединги
Насамкінець: очевидно, що pgvector набув значного поширення, але поки неясно, чи отримає pgai такий самий інтерес і, відповідно, підтримку (хоча він існує лише близько 18 місяців).
pgai пропонує цікавий підхід до RAG: база даних виконує більше рутинних операційних завдань, завдяки чому код застосунку стає простішим.
Наразі він:
зручний і справді приємний у роботі для простих конфігурацій RAG
недостатньо гнучкий для більш спеціалізованих конвеєрів (особливо мультимодальних)
Він має потенціал, і безперечно варто стежити за його розвитком.