Якщо ви створюєте додаток із посиленою генерацією за допомогою пошуку (RAG) з PostgreSQL та pgvector, ви, ймовірно, зіштовхнетеся з проблемою обробки багатокористувацького середовища. Ця стаття пояснює, як вибрати правильний підхід до управління багатокористувацьким середовищем для вашого випадку використання.
Що таке багатокористувацьке середовище?
Багатокористувацьке середовище схоже на багатоквартирний будинок для програмного забезпечення. Як і в одному будинку можуть жити кілька орендарів (сім'ї або індивіди), багатокористувацький додаток обслуговує кілька клієнтів або організацій, використовуючи одну інстанцію програмного забезпечення.
Багатокористувацьке середовище обслуговує кількох "орендарів" незалежно та безпечно — запобігаючи випадковому або несанкціонованому перехресному посиланні приватної інформації між різними користувачами. Це означає проектування системи, яка не лише ефективно знаходить і повертає інформацію, але й строго дотримується меж даних, які належать кожному користувачу.
Багатокористувацькі додатки: переваги та недоліки
Багатокористувацьке середовище в RAG додатках є важливим з кількох ключових причин, які забезпечують переваги:
- Ізоляція даних: Це дозволяє кільком орендарям використовувати ту саму систему RAG, зберігаючи їхні дані окремими та безпечними. Це критично для збереження конфіденційності та приватності.
- Масштабованість: Архітектура багатокористувацького середовища дозволяє системі ефективно обслуговувати багатьох користувачів або організацій без потреби в окремих розгортаннях для кожного, що веде до кращого використання ресурсів і економії коштів.
- Налаштування: Різні орендарі часто мають унікальні потреби. Багатокористувацьке середовище дозволяє налаштовувати систему RAG для кожного орендаря, наприклад, використовуючи специфічні для орендаря бази знань або налаштовуючи моделі для конкретних областей.
- Відповідність вимогам: У багатьох галузях регуляторні вимоги вимагають суворого розмежування даних. Багатокористувацьке середовище допомагає відповідати цим вимогам, забезпечуючи, щоб дані від різних орендарів не змішувались.
- Ефективні оновлення: У багатокористувацькій системі оновлення та вдосконалення можуть бути впроваджені для всіх орендарів одночасно, гарантуючи, що всі отримують останні функції та патчі безпеки.
- Економічність: Спільне використання інфраструктури та ресурсів серед орендарів може значно знизити операційні витрати в порівнянні з підтримкою окремих систем для кожного користувача або організації.
- Послідовність продуктивності: Добре спроектована багатокористувацька система RAG може забезпечити більш стабільну продуктивність для всіх орендарів, оскільки ресурси динамічно розподіляються залежно від використання.
Щоб побудувати довготривалу продуктивність, гнучкість і ефективність, також корисно пам'ятати про потенційні виклики багатокористувацьких архітектур:
- Багатокористувацьке середовище дозволяє кілька точок доступу для користувачів, що може збільшити загрозу порушення безпеки.
- Обслуговування кількох клієнтів в одній інстанції програми або бази даних додає додатковий рівень складності до бази коду та підтримки бази даних.
- Резервне копіювання та відновлення є складнішими, тому не всі постачальники пропонують надійні послуги відновлення.
- Можливість надання орендареві специфічних налаштувань обмежена, і часто необхідно балансувати спільну базу коду з унікальними вимогами орендарів.
- Технічні проблеми на стороні постачальника можуть вплинути на всіх орендарів одночасно. Це може стосуватися доступності, оновлень системи та інших глобальних процесів.
Переваги PostgreSQL для багатокористувацьких RAG додатків
PostgreSQL, вдосконалений розширенням pgvector (популярне відкритий розширення для обробки векторів у PostgreSQL), пропонує надійне рішення для реалізації багатокористувацьких RAG додатків. Його здатність ефективно зберігати та шукати векторні вбудови разом із традиційними типами даних робить його ідеальним вибором для організацій, які хочуть використовувати свою існуючу інфраструктуру.
Ось чому PostgreSQL є відмінним вибором для багатокористувацьких RAG додатків:
1.
Вбудований повнотекстовий пошук: PostgreSQL має потужні можливості повнотекстового пошуку, що є критично важливим для ефективного пошуку в системах RAG.
2. Підтримка JSON: PostgreSQL обробляє дані у форматі JSON нативно, що дозволяє гнучко зберігати документи та метадані.
3. Розширення для векторів: Розширення, такі як pgvector, дають змогу виконувати пошук за схожістю векторів, що є важливим для пошуку за вбудовами.
4. Безпека на рівні рядка: Ця функція дозволяє здійснювати точний контроль доступу, що критично для багатокористувацьких налаштувань, щоб забезпечити ізоляцію даних.
5. Масштабованість: PostgreSQL здатний обробляти великі набори даних і одночасних користувачів, що важливо для масштабування багатокористувацьких додатків.
6. Відповідність ACID: атомарність, узгодженість, ізоляція та довговічність (ACID) забезпечують цілісність даних та узгодженість транзакцій.
7. Розширюваність: Можна додавати кастомні функції та розширення, щоб адаптувати базу даних до специфічних потреб RAG.
8. Економічність: Як відкрите рішення з відкритим кодом, PostgreSQL може бути більш економічним у порівнянні з деякими хмарними альтернативами.
Використання PostgreSQL для багатокористувацьких RAG додатків також дає вам перевагу від використання стеку відкритих розширень Timescale Cloud, щоб легко будувати та масштабувати додатки RAG, пошуку та агентів. Окрім pgvector, цей стек включає pgvectorscale (яке будується на основі pgvector для покращеної продуктивності та масштабування) і pgai (яке приносить створення вбудов та завершенням великих мовних моделей до бази даних, даючи більше розробникам PostgreSQL навички інженерів ШІ). Обидва ці розширення доповнюють pgvector та залежать від його можливостей.
Реалізація RAG з PostgreSQL
Реалізація RAG з PostgreSQL включає багатоетапний процес, який використовує можливості зберігання векторів у базі даних. Робочий процес зазвичай включає імпорт і розбиття даних, перетворення тексту у векторні вбудови за допомогою моделі вбудовування та зберігання цих векторів у PostgreSQL за допомогою pgvector.
Коли система отримує запит від користувача, вона знаходить найбільш релевантні дані з векторної бази даних на основі пошуку за схожістю. Ця отримана інформація потім поєднується з питанням користувача та додатковим контекстом для створення комплексного запиту для великої мовної моделі (LLM). LLM обробляє цей розширений запит і генерує відповідь, яка потім повертається користувачу, забезпечуючи точнішу та контекстуально релевантну відповідь.
Стратегії обробки багатокористувацького середовища для RAG в PostgreSQL
Щоб вибрати правильну стратегію для вашого багатокористувацького RAG додатку з PostgreSQL, враховуйте ваші вимоги (та вимоги ваших користувачів або клієнтів) до спільних ресурсів, розділення даних, налаштувань, масштабованості та, звісно, витрат.
PostgreSQL пропонує чотири рівні реалізації багатокористувацького середовища — таблиця, схема, логічна база даних і база даних як сервіс — кожен з яких підходить для різних сценаріїв використання і має свої переваги та недоліки. Ось порівняльний огляд кожного рівня.
- Багатокористувацьке середовище на рівні таблиці дає кожному орендарю свою таблицю. Це просто, але може призвести до проблем з ізоляцією даних. Багатокористувацьке середовище на рівні таблиці добре підходить для простих додатків з спільними даними.
- Розділення на рівні схем дає кожному орендарю свою схему в тій самій логічній базі даних. Це забезпечує кращу ізоляцію з мінімальними операційними та витратними накладними витратами, балансуючи ізоляцію та ефективність для більшості випадків використання.
- Розділення на рівні логічної бази даних дає кожному орендарю свою логічну базу даних в одній інстанції бази даних. Розділення на рівні логічної бази даних забезпечує сильніше розділення, але збільшує складність. Логічні бази даних підходять для клієнтів, яким потрібна суворіша ізоляція.
4.
Розділення на рівні сервісу бази даних дає кожному орендарю свій власний сервіс бази даних. Розділення на рівні сервісу ідеально підходить для сценаріїв з високими вимогами до безпеки або клієнтів з унікальними потребами. Це забезпечує найвищу ізоляцію, але за рахунок збільшення ресурсів і накладних витрат на управління.
Висновок
Ретельно враховуючи оптимальні випадки використання, переваги та недоліки кожного підходу до багатокористувацького середовища та узгоджуючи їх з потребами вашого додатку, ви можете створити масштабовану, безпечну та ефективну систему RAG на PostgreSQL. Оскільки технології RAG продовжують розвиватися, розширюваність PostgreSQL і сильна підтримка спільноти гарантують, що він залишатиметься адаптивною платформою для створення складних багатокористувацьких AI додатків.
Додатково, PostgreSQL на Timescale Cloud дозволяє зберігати ваші реляційні, часові ряди, події, напівструктуровані дані та векторні дані в одному місці. Це усуває операційну складність управління окремою векторною базою даних. Він може забезпечити продуктивність, багаті можливості та досвід користувачів, який дорівнює або перевершує спеціалізовані інструменти.
Створіть безкоштовний обліковий запис, щоб спробувати стек відкритих рішень AI Timescale Cloud сьогодні (включаючи pgvector, pgai та pgvectorscale).
Цю статтю написали Автар Севратан і Аня Сейдж і спочатку опублікували тут на офіційному блозі Timescale 11 жовтня 2024 року.
Перекладено з: Building Multi-Tenant RAG Applications With PostgreSQL: Choosing the Right Approach