Таблиці з кількома моделями: одна таблиця для файлів, ембеддингів та гібридного пошуку для агентів.

Протягом багатьох років ця база даних розвивалася у напрямку єдиної системи, яка охоплює обробку розподілених транзакцій для критичних навантажень, технології HTAP, багатомодельні дані та гібридний пошук. Продукт Lakebase свідчить про подальшу зміну акцентів. Тепер питання полягає не лише у тому, що може обробляти база даних, а й у тому, кому вона слугує. Раніше бази даних створювалися для розробників, адміністраторів БД та додатків. Виробник стверджує, що в епоху ШІ вони також мають обслуговувати новий тип користувачів – агентів.

Згідно з цим визначенням, „база даних ШІ“ — це не просто система, яка може зберігати зображення, PDF-файли чи вектори. Це система, створена для того, щоб надавати агентам повний, актуальний та надійний контекст для міркувань та дій, з використанням ембеддингів, необроблених файлів та гібридних методів пошуку, які працюють з одного місця. Решта тексту описує функцію багатомодельних таблиць у Lakebase та проблему, яку вона вирішує. Це твердження виробника, тож перевірте їх на власних завданнях.

Проблема даних агента

Уявіть собі рішення, яке має прийняти агент. Йому може знадобитися структурований профіль користувача, текстове узагальнення розмови, оригінальний PDF з бази знань, семантичні результати з пошуку векторів та поточний стан бізнесу — усе це одночасно.

Сьогодні ці п’ять елементів зазвичай знаходяться у п’яти системах: системі зберігання об’єктів, пошуковій системі, векторній базі даних, бізнес-базі даних та офлайн-сховищі. Не існує спільних транзакцій, єдиного знімка стану чи загальної ієрархії.

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

Таблиця багатомодельного типу — це рішення Lakebase. Це ключова функція керування даними продукту, яка дозволяє обробляти зображення, аудіо, відео, PDF-файли, скріншоти веб-сторінок, вектори, JSON та структуровані дані як окремі об’єкти бази даних. Усі вони знаходяться в одній системі, яка забезпечує транзакції, послідовність, високу доступність, гібридний пошук, аналітичні обчислення та онлайн-надання даних.

Чому агентам потрібна інша модель даних

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

Існує чотири основні зміни:

1. Неструктуровані дані потрапляють на критичну доріжку обробки. Вони більше не є просто додатком у сховищі об’єктів, а стають ключовим елементом для прийняття рішень.
2. Доступ до даних перетворюється на гібридний пошук. Одна заявка може поєднувати структуровані фільтри, пошук за повним текстом, векторний аналіз та агрегацію даних.
3. Зростає потреба у роботі в реальному часі. Агенти працюють цілодобово, а щоденна звітність вже не встигає за цим темпом.
4. Функції генеруються динамічно. Багато полів не вводяться безпосередньо – моделі отримують їх асинхронно з необроблених даних.

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

Основні можливості

Одне місце для багатомодельних об’єктів

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

Це робиться для того, щоб гарантувати, що сирий об’єкт та його похідні характеристики, такі як анотації, мітки, ембеддинги та показники ризику, завжди відповідали одній і тій самій версії даних. Не повинно траплятися, що об’єкт оновлюється, але його характеристики все ще описують старий вміст.

Динамічні стовпці характеристик

Дані багатомодельного підходу є дуже насиченими, і один сирий об’єкт може створювати безкінечний набір характеристик: семантичних, структурних, пов’язаних із якістю та специфічних для бізнесу. Із тексту можна отримати теми, резюме, ембеддинги, мітки безпеки, мову та оцінку якості. Із зображення — результати OCR, теги, оцінки ризиків та атрибути бізнесу. Кожна нова модель додає ще більше.

За класичною схемою кожна нова характеристика означає зміну DDL. Кожна зміна DDL спричиняє анулювання кешу, посилення операцій запису та тиск на компактацію у фоновому режимі, тому швидкість роботи з характеристиками зменшується до швидкості блокувань таблиць.

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

Асинхронні обчислення майже в реальному часі

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

Обробка даних моделлю зазвичай займає від сотень мілісекунд до секунд, що занадто повільно, щоб блокувати онлайн-записи. Тому таблиця не чекає:

1. Спочатку зберігаються необроблені дані, що зберігає первісну затримку запису в реальному часі.
2. Фонові завдання починають вилучення ознак, створення індексів та доповнення даних відповідно до їхньої лінійності.
3. Отримані значення з’являються протягом майже реального часу.
4. Під час читання завжди отримується однаковий знімок даних.

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

Послідовність груп стовпців

Асинхронні обчислення створюють проблему видимості даних. Як тільки з’являється рядок, такі елементи, як характеристика A, характеристика B, ембеддинги, індекси повного тексту та мітки якості, можуть бути оброблені у різний час завдяки різним завданням та моделям. Якщо запит бачить, що обробка характеристики B завершена, тоді як обробка характеристики A ще триває, він поверне неправильні відповіді без жодних попереджень.

Консистентність груп стовпців забезпечується на рівні сховища даних. Група бізнес-стовпців стає новим видимим знімком лише після того, як усі пов’язані похідні стовпці будуть оброблені. Запити та гібридний пошук читають консистентний знімок та ніколи не стикаються з неповними даними.

Розділене зберігання та обробка даних, із поєднанням „гарячих“ та „холодних“ даних

Обсяг даних у багатьох моделях постійно зростає — у документах, зображеннях, відео, векторах та похідних характеристиках, тому зберігання всіх цих даних у «гарячому» режимі є нежиттєздатним у масштабному використанні. Ці таблиці реалізовані за принципом роз’єднаної архітектури з спільним зберіганням та розглядають «гарячі» та «холодні» дані як єдиний континуум:

• Найновіші дані, наприклад останні 90 днів, зберігаються у кеші на SSD, щоб забезпечити швидкий доступ.
• Старіші дані, наприклад старші за 90 днів, зберігаються на дешевшому спільному зберіганні, проте залишаються доступними для запитів, пошуку та аналізу через ту саму інтерфейсну платформу.

Немає потреби змінювати системи для отримання доступу до «холодних» даних чи поєднувати онлайн-базу даних, об’єктне зберігання та офлайн-сховище для відповіді на одне запитання. Існує один спосіб відображення даних, одна інтерфейсна площина для запитів та одна модель управління.

Історія походження та єдиний каталог

З якого фрагмента тексту походить цей ембеддинг? Яка модель аудиту присвоїла ту мітку безпеки? Яку версію PDF описує цей огляд?

Лінійність та уніфікований каталог становлять основу метаданих. Вони фіксують, як первинні об’єкти, структуровані поля, динамічні стовпці ознак, завдання моделей, версії та дозволи взаємопов’язані. Метадані підтримують три аспекти:

1. Запуск. Фонові завдання з вилучення даних, створення індексів та доповнення інформації автоматично запускаються на основі лінійності.
2. Повнота. Перш ніж даний стан стане видимим, система перевіряє, чи була повністю обчислена група стовпців або знімок.
3. Відстежуваність. Коли агент надає відповідь, її можна простежити до документів, зображень, записів та похідних ознак, які він використав.

Один рівень доступу для транзакцій, аналітики та пошуку

Таблиця з кількома моделями описується як спільна основа для трьох типів роботи з одними й тими самими даними:

• онлайн-транзакції, тобто операції з записом даних з гарантіями ACID та високою доступністю;
• аналітика, тобто масштабні сканування, агрегації, фільтрація, об’єднання даних та аналіз характеристик;
• гібридний пошук, тобто структуровані фільтри у поєднанні з пошуком у повному тексті, відтворенням векторів, фільтрацією за тегами та ранжуванням за критеріями бізнесу.

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

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

Що воно замінює

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

Чому це важливо

Справжнє питання не в тому, чи може база даних для ШІ зберігати зображення, PDF-файли чи вектори. Важливо те, що зміниться, коли агенти стануть основними користувачами цієї бази даних.

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

Таблиці з підтримкою кількох моделей об’єднують структуровані та неструктуровані дані, характеристики, отримані за допомогою ШІ, та бізнес-семантику під одну систему для здійснення транзакцій, керування та обробки даних. Бази даних раніше використовувалися для об’єднання даних. У епоху ШІ їм потрібно об’єднувати дані, семантику та операції, які їх створюють, і ця функція є першим кроком Lakebase у цьому напрямку.

Оцінка

Таблиці з підтримкою кількох моделей постачаються як частина Lakebase. Щоб оцінити їх з точки зору навантаження вашого агента, визначте типи даних, якими потрібно керувати, сценарій роботи агента, який ви розробляєте, а також будь-які вимоги до продуктивності чи керування, потім створіть одну таблицю з підтримкою кількох моделей та порівняйте її з системою, яку вона має замінити. Ключовим критерієм є те, чи припиняє агент надсилати неправильні відповіді.

Пов’язані матеріали

• Онтологія чи семантичний шар? Що потрібно AI-агенту від кожного з них: У чому різниця між онтологіями та семантичними шарами, що відбувається, коли є лише один з них, де застосовуються графи знань та практичний порядок створення шару контексту.
• Повторно використовувані запити AI Agent, які кожен розробник повинен зберігати: бібліотека класифікованих запитів для перегляду коду, тестування, виправлення помилок, дизайну, документації, Git та навчання, а також п’ять звичок, які покращують ефективність будь-якого запиту до агента.