
Основной сценарий
Представим себе такой сценарий. Пользователь устно и/или в чате поручает ИИ-агенту найти и приобрести нужный товар с заданными параметрами. ИИ-агент в разговоре уточняет у пользователя задание, составляет описание товара и на его основе формирует запрос к поисковой системе.
В сниппетах поисковой выдачи ИИ-агент получает:
-
Список глобально уникальных идентификаторов товаров, чтобы можно было различить похожие товары и объединить одинаковые
-
Основные параметры этих товаров, чтобы можно было составить шорт-лист для дальнейшего анализа товаров
-
URL ресурсов для приобретения товаров (сайты производителя, маркетплейсов, интернет-магазинов, лендинги, карточки товаров, обзоры и отзывы и т.п.)
Затем ИИ-агент заходит на эти ресурсы, получает доступ к метаданным баз данных (БД), формирует SQL-запросы и уточняет в БД параметры товаров и условия их приобретения.
Собранные данные ИИ-агент сверяет с поручением пользователя и либо сам осуществляет заказ (попутно организуя логистику), либо составляет обзор товаров и передает несколько предложений на выбор и утверждение пользователя, либо (если ничего подходящего не нашлось) отчитывается о своей тщетной попытке выполнить поручение. При необходимости и возможности ИИ-агент может поторговаться.
Чтобы такой сценарий осуществился в жизни, уже многое готово, а остальное вполне осуществимо.
Другие сценарии
Необходимая для этого инфраструктура вполне может быть использована и во многих других сценариях, в том числе:
-
Поиск опубликованных научных данных
-
Поиск технических решений
-
Поиск комплектующих и запчастей
-
Компоновка информационной системы из доступных модулей
-
Поиск жилья
-
Поиск работы
-
Поиск и доставка продуктов
-
Выбор методики лечения, клиники, врача и медикаментов
-
Выбор учебного заведения/курсов, учебной программы и репетитора
-
Поиск авиабилетов и отелей
-
Поиск развлечений и активностей
-
Поиск финансовых инструментов
-
Поиск информационных ресурсов и СМИ
Посмотрим теперь на эту инфраструктуру.
Поиск в интернете с помощью LLM
Поиск в интернете с помощью LLM, в том числе, с использованием ИИ-агентов, уже реализован. Но LLM извлекает данные с тех же самых интернет-страниц, что и люди, и поисковые роботы.
Встречаются предложения добавить специально для RAG (Retrieval-Augmented Generation) интернет-страницы в более машиночитаемом формате (Markdown, JSON и т.п.), чтобы LLM обрабатывала не расплывчатые фразы, а четкие параметры. Но это полумера.
Эти страницы – лишь ненужный посредник между компонентом поиска RAG и БД, замедляющий и усложняющий поиск. Поэтому LLM должна искать непосредственно в БД, которая должна содержать всё необходимое для генерации человекочитаемого контента, либо ссылки на человекочитаемые интернет-страницы.
Поиск с помощью LLM непосредственно в БД
Поиск и авторизация с помощью LLM непосредственно в БД (в частности, в PostgreSQL) уже реализованы с использованием Model Context Protocol (MCP).
Однако для полноценного поиска с помощью LLM в БД потребуется:
-
Совершенствование MCP-серверов, чтобы они могли уверенно ориентироваться в метаданных (структура таблиц, типы данных, связи, семантическое описание полей) ранее неизвестных им БД
-
Более полное описание метаданных в БД
Вопросы информационной безопасности при предоставлении LLM прямого доступа к БД оставим за скобками. Необходимые технические решения существуют, и нужно только грамотно ими воспользоваться.
UUIDv7 в базах данных
UUIDv7 – это описанная в стандарте RFC 9562 новая версия идентификаторов формата UUID, предназначенная для замены натуральных ключей и генерируемых возрастающих целочисленных идентификаторов (далее – автоинкремент как механизм, bigint – как тип данных) в базах данных и распределенных системах. Идентификатор версии UUIDv7 включает в себя временную метку (timestamp) для сортируемости и уникальности, случайные данные для уникальности и другие данные. Рекомендовано хранить UUID в БД как 128-битные двоичные данные для максимальной производительности.
Автоинкремент заменяет собой изменчивые натуральные ключи для связей между таблицами БД.
В свою очередь, UUIDv7 при той же производительности устраняет недостатки автоинкремента:
-
Сложность слияния данных с одинаковыми ключами из разных таблиц БД
-
Необходимость генерации новых ключей и их синхронизации с ключами из источника данных при экспорте и импорте данных и при параллельной генерации записей несколькими микросервисами
-
Возможные ошибки из-за коллизии ключей при слиянии данных
-
Раскрытие количества записей в таблице БД
-
Легкость подбора валидного ключа хакером
Все недостатки простейших реализаций UUIDv7 устранены в продвинутых реализациях UUIDv7:
-
Нарушение монотонности (возрастания) генерируемых идентификаторов при откате системных часов назад или при большом темпе генерации
-
Нарушение монотонности (возрастания) генерируемых идентификаторов и конкуренция за блокировки (lock contention) при параллельной генерации идентификаторов в нескольких микросервисах (это ведь только в идеальном мире каждый микросервис пишет в свою таблицу)
-
Раскрытие даты и времени создания записи
Монотонность гарантируется не во всех случаях. Незначительные нарушения монотонности не влияют на производительность, но могут затруднить поиск багов, пагинацию, поиск в логах, использование в БД временных рядов и т.п.
Хотя UUID вдвое длиннее, чем bigint (128 битов против 64), но разница в реально занимаемом месте на диске гораздо меньше, а упрощение архитектуры при использовании UUID вместо bigint устраняет необходимость в промежуточных таблицах и слоях данных.
Благодаря своим преимуществам UUIDv7 может стать основным типом идентификаторов в БД и затем использоваться для поиска во внешних системах (ресурсах), подключенных к интернету.
Поиск по UUIDv7 во внешних системах, подключенных к интернету
Если отвлечься от баз данных и обратить внимание на поиск в интернете, то можно увидеть и другие важные недостатки у натуральных ключей и bigint:
-
Один и тот же экземпляр сущности (объект, событие, явление, понятие) может обозначаться в разных системах разными ключами
-
Один и тот же ключ, сгенерированный автоинкрементом в разных системах, практически наверняка указывает на разные экземпляры сущности
Поэтому глобальный поиск в базах данных с использованием натуральных ключей и bigint невозможен. Но использование UUIDv7 делает легко осуществимым поиск во внешних системах (ресурсах), подключенных к интернету. Изменения в алгоритмах поисковых систем скорее всего не потребуются.
Поиск UUIDv7 в интернете с помощью LLM
Поиск UUIDv7 в интернете LLM может осуществляться с помощью поисковых систем (Google и т.п.). По запрошенному в поисковой строке UUIDv7 (ключевому слову) в поисковую выдачу должен попасть расширенный сниппет (Rich Snippet, не путать с Featured Snippet), содержащий URL и относящиеся к нему данные. Для формирования такого сниппета необходимо дополнить микроразметку Schema.org соответствующими свойствами (properties).
Архитектура системы

Автор: SergeyProkhorenko