Таблицы с несколькими моделями: одна таблица для файлов, эмбеддингов и гибридный поиск для агентов.

На протяжении многих лет рассматриваемая база данных развивалась в направлении единой системы, обеспечивающей обработку распределенных транзакций для критически важных нагрузок, поддержку режима HTAP, работу с многомодельными данными и гибкий поиск. Продукт Lakebase свидетельствует о дальнейшем смещении акцентов. Вопрос теперь заключается не только в том, что может обрабатывать база данных, но и в том, кому она служит. Раньше базы данных создавались для разработчиков, администраторов БД и приложений. Производитель утверждает, что в эпоху ИИ они также должны обслуживать новый тип пользователей — агентов.

Согласно этому определению, «база данных ИИ» — это не просто такая, которая может хранить изображения, PDF-файлы или векторы. Это система, созданная для предоставления агентам полного, актуального и надежного контекста для принятия решений и действий, при этом встроенные элементы, сырые файлы и гибкий поиск работают из одного и того же источника. Остальная часть текста описывает функцию многомодельных таблиц в Lakebase и проблему, которую она решает. Это утверждения производителя, поэтому протестируйте их на собственных задачах.

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

Представьте ситуацию, когда агенту необходимо принять решение. Ему может потребоваться структурированный профиль пользователя, текстовое резюме разговора, оригинальный PDF-файл из базы знаний, семантические результаты поиска с использованием векторов и текущее состояние бизнеса — все это одновременно.

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

Если PDF обновляется, в то время как его ссылка по-прежнему ведет на старую версию, агент дает уверенный, но неверный ответ, и никто об этом не знает. Это не проблема хранения большего количества типов данных — это проблема управления. Как только мультимодельные данные попадают на критически важный участок обработки, кто-то должен гарантировать согласованность версий, полноту вычислений, возможность отслеживания и доверие к результатам. Во многих командах этим человеком является тот, кто отвечает за пайплайн, регулярно отлаживает его и переписывает каждый квартал.

Таблица с поддержкой нескольких моделей — это решение Lakebase. Она является ключевой функцией управления данными продукта и обрабатывает изображения, аудио, видео, PDF-файлы, снимки веб-страниц, векторы, JSON-данные и структурированные колонки как отдельные объекты базы данных. Все они находятся в одной системе, которая обеспечивает транзакции, согласованность данных, высокую доступность, гибкий поиск, аналитические вычисления и онлайн-обслуживание.

Почему агентам нужна другая модель данных

Объекты, с которыми работает агент, по своей природе являются мультимодельными. Источники данных варьируются от естественного языка до изображений, PDF-файлов, веб-страниц, таблиц и бизнес-контекста. В процессе работы агент использует пользовательскую память, базы знаний, результаты технологии RAG, структурированные бизнес-данные, семантические профили и результаты промежуточных моделей.

Следуют четыре ключевых изменения:

1. Структурированные данные переходят на ключевой участок обработки. Они больше не являются просто вложениями, хранящимися в системе хранения объектов, а становятся важным входным материалом для принятия решений.
2. Доступ к информации превращается в гибридный поиск. Одна заявка может сочетать в себе структурированные фильтры, поиск по полному тексту, векторный поиск и аналитическую агрегацию.
3. Растут требования к реальному времени. Системы работают круглосуточно, а отчетность за следующий день уже не может справляться с такими темпами.
4. Функции генерируются динамически. Многие поля не задаются напрямую; модели извлекают их асинхронно из сырых данных.

Практический вопрос заключается в том, как объединить сырые мультимодельные данные, структурированные поля, вычисленные характеристики и асинхронные результаты в одной базе данных, чтобы они могли одновременно обслуживать онлайн-транзакции, аналитику и гибридный поиск, не теряя при этом согласованности и прозрачности. Именно решение этой задачи стоит перед проектированием мультимодельных таблиц.

Основные возможности

Одно место для мультимодельных объектов

Таблицы мультимоделей помещают эти объекты под собственный контроль транзакций и версий базы данных. Большие объекты, такие как изображения, аудио, видео, PDF-файлы и снимки веб-страниц, могут храниться несколькими разными способами. Физическое расположение байтов имеет меньшее значение, чем то, что обещает база данных: постоянный идентификатор, способ доступа к объекту, номер версии, статус видимости и определённый диапазон транзакции.

Это предназначено для того, чтобы гарантировать, что сырой объект и его производные характеристики, такие как краткое описание, метки, векторные представления и оценки риска, всегда соответствовали одной и той же версии данных. Ошибка, при которой объект обновляется, но его характеристики по-прежнему описывают старый контент, не должна возникать.

Динамические столбцы характеристик

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

В рамках классической схемы каждая новая характеристика требует изменения DDL. Каждое такое изменение приводит к аннулированию кэша, увеличению объёма записей и дополнительной нагрузке на процесс сжатия данных, в результате чего скорость работы с характеристиками снижается до скорости блокировок таблиц.

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

Асинхронные вычисления в реальном времени

Многие столбцы вообще не создаются пользователями. Их генерируют задачи на обработку данных, включая создание эмбеддингов, кратких краткосписков, результатов OCR, оценок качества, индексов полнотекстового поиска и векторных индексов, с использованием встроенных функций моделей, фоновых задач или внешних пайплайнов.

Выполнение моделей обычно занимает от нескольких сотен миллисекунд до нескольких секунд, что слишком медленно, чтобы блокировать онлайн-запись. Поэтому таблица не ждет:

1. Сначала сохраняются сырые данные, что позволяет сохранить исходную задержку записи.
2. Фоновые задачи начинают извлечение признаков, создание индексов и восполнение данных в соответствии с их происхождением.
3. Расчётные значения появляются в почти реальном времени.
4. При чтении всегда получается один и тот же консистентный снимок данных.

Основание для этого подхода заключается в том, что строгая синхронизация каждой расчётной колонки является нецелесообразной и ненужной. Правильной целью является контролируемый баланс между задержкой, пропускной способностью, эффективностью хранения и консистентностью. Вычислительные задачи генерируют значения, а таблица делает их управляемыми, доступными для поиска, анализа и последовательного чтения.

Консистентность групп колонок

Асинхронные вычисления создают проблему видимости данных. Как только появляется строка, такие элементы, как признак А, признак Б, эмбеддинги, индексы полнотекстового поиска и метки качества, могут быть готовы в разное время — в результате работы разных задач и моделей. Если запрос обнаруживает, что признак Б уже готов, в то время как признак А всё ещё обрабатывается, он вернёт неверные ответы без какого-либо предупреждения.

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

Разделённое хранение и вычисления с использованием «горячих» и «холодных» данных

Объем мультимодальных данных растет без ограничений — включая документы, изображения, видео, векторы и полученные признаки, поэтому хранение всего этого в оперативной памяти невозможно в масштабах. Эти таблицы работают в архитектуре с разделенным хранилищем, где «горячие» и «холодные» данные рассматриваются как единый спектр:

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

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

Происхождение данных и единый каталог

Из какого фрагмента текста взято это встраивание? Какая модель аудита присвоила эту маркировку безопасности? Какую версию PDF описывает это резюме?

Цепочка происхождения и единый каталог составляют основу метаданных. Они отражают взаимосвязи между сырыми объектами, структурированными полями, динамическими столбцами признаков, задачами модели, версиями и правами доступа. Метаданные обеспечивают три основных функции:

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

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

Многомодельная таблица представляет собой общую основу для трех типов работ с одними и теми же данными:

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

Доступ агентов по своей природе является многоэтапным. Запрос может сначала пройти фильтрацию по структурированным условиям, затем выполнить поиск полнотекстового содержимого, после этого найти похожий контент с помощью векторного восстановления результатов, а затем произвести ранжирование по тегам, качеству, свежести данных и наличию разрешений. Ни один специализированный движок не покрывает все четыре этапа.

Основной компромисс заключается между почти реальным временем обработки и высокой степенью синхронизации. Поиск и аналитика не требуют использования производных характеристик для выполнения операций в рамках транзакции записи, однако эти характеристики должны становиться доступными в короткий промежуток времени и читаться из единообразной копии данных. Именно так одна таблица может обеспечивать онлайн-записи, гибкий поиск и аналитику без необходимости хранения трех отдельных копий данных.

Что оно заменяет

В современных проектах с использованием агентов это решение заменяет набор инструментов вроде хранилищ объектов, поисковой системы, векторной базы данных, бизнес-базы данных и офлайн-хранилища. Старый компромисс между широтой функционала различных моделей и строгим управлением данными в стиле традиционных баз данных должен исчезнуть.

Почему это важно

Настоящий вопрос не в том, может ли база данных для ИИ хранить изображения, PDF-файлы или векторы. Вопрос в том, что изменится, когда агенты станут основными пользователями такой базы данных.

Если ответ заключается в том, что на каждый тип данных требуется отдельная изолированная система, это означает большую площадь для защиты, больше каналов, которые могут быть нарушены, и более значительное скрытое отклонение. Если же ответ — единая управляемая таблица, в которой каждая модальность является объектом первого класса, то получается настоящая основа для хранения данных вместо временной структуры, состоящей из каналов обработки.

Таблицы с поддержкой нескольких моделей объединяют структурированные данные, неструктурированные данные, характеристики, полученные с помощью ИИ, и бизнес-семантику в единую систему для выполнения транзакций, управления и вычислений. Базы данных раньше использовались для объединения данных. В эпоху ИИ им необходимо объединять данные, семантику и операции, их генерирующие, и эта функция является первым шагом Lakebase в этом направлении.

Оценка

Таблицы с поддержкой нескольких моделей поставляются в составе Lakebase. Чтобы оценить их подходящесть для вашей рабочей нагрузки агента, перечислите типы данных, которыми необходимо управлять, сценарий использования агента, а также любые требования к производительности или регулированию, затем создайте модель одной такой таблицы и сравните её с системой, которую она будет заменять. Критерием успеха является отсутствие неверных ответов от агента.

Связанные материалы

• Онтология или семантический слой? Что нужно ИИ-агенту от каждого из них: в чём разница между онтологиями и семантическими слоями, что происходит, если есть только один из них, какова роль графов знаний и пошаговая инструкция по созданию слоя контекста.
• Повторно используемые промпты для ИИ-агентов, которые должен сохранять каждый разработчик: библиотека промптов с категоризацией для ревью кода, тестирования, отладки, дизайна, создания документации, работы с Git и обучения, плюс пять привычек, которые помогают сделать любой промпт для агента более эффективным.