Комментарии 10
Может быть, использовать маппинг "человеческих" определений на задачи для ai агентов по доменам в базе и объединять результаты работы агентов? Агенты настроены на определенные связанные таблицы и имеют ограничения на критерии поиска и связанности. Также хранилище может быть гетерогенным - часть в одной базе а часть в другой (и база другого типа, nosql).
Имеем агента по поиску документов по определенным признакам, агента по поиску зарплат, персонала и тд.
Ищем используя вгентов а затем делаем подобие lazy join результата работы агентов.
Те вносим промежуточный слой абстракции, язык высокого уровня на уровне агентов, вместо написания большого кода на ассемблере, пардон , SQL.
PS сейчас делаю пет проект для самообучения, вырожденный случай вашей темы - поиск в nosql базе по одному полю. Так что дилетант пока что в llm.
Все зависит от задачи. Вы абсолютно правы в том, что создание абстракции в виде некого DSL, на котором модель выражается - это эффективный путь решения проблемы. Особенно, если задать формальную грамматику языка и ограничить вывод модели при помощи guided_decoding и качественно написанного промпта.
Задача, которую мы решали, достаточно общая и SQL/Cypher в ней вполне выступают в виде абстрактных DSL с последующей агрегацией результатов каждого из этапов.
я не "настоящий сварщик" в LLM, скорее парень "от сохи" (консалтинг в основном), поэтому полноценно вести дискуссию по теме не могу - нужно подтянуть уровень, чем только начал заниматься.
Практически хотелось бы понять на примерах использование.
К примеру, есть база репозитория документов. FileNet, CMOD, Vignette, Cmis или еще что то изобретенное для хранения документов, нет им числа. Как правило в базе хранятся метаданные документов и сущности самого репозитория. Неподготовленный человек заглянув в базу, ахнет и точно сразу не поймет все взаимосвязи.
Содержимое документов может храниться в базе, но как правило, без полнотекстового поиска либо без LLM friendly поиска по KNN вектору. В моей практике поиск по содержимому выносился в nosql базу.
Еще есть логи связанные с обработкой документов.
Есть пользователь который желает искать к примеру документы, используя чат. Варианты поиска:
Найти документы по метаданным ( заголовок, автор, дата и тд) - его можно реализовать поиском в базе используя sql, и как правило в nosql ( в моей практике это был индекс lucene)
Найти документы по метаданным и контенту ( точно совпадение или по KNN) - тут пожалуй лучше искать по nosql ( lucene).
Найти документы по метаданным и по результату их обработки - придется искать в логах ( еще один агент?) и либо в SQL базе, либо в nosql ( индекс). Затем объединять результаты. Понятно что никакого честного join с total hits не будет, это page iterator, но для чата сойдет. Получается в бизнес задачах от агентов не уйти, их же можно использовать и внутри больших баз.
Последний вопрос - а как быть с доступом (security)? Чтобы результат поиска не попал к тем кто прав на него не имеет. Вопрос доступа нужно пробрасывать на уровень ниже, получается. А он не всегда доступен на уровне базы, обычно это API выше уровнем.
Спасибо за публикацию, встряхнули.
У нас, очевидно, база postgresql, поэтому нам доступны все ее преимущества, включая ролевые модели, разделение по схемам, полнотекстовый поиск, векторный поиск, поиск по графу и т.д. Поэтому разграничение доступов у нас на уровне базы. Логи можно присвоить документу, разбить на чанки и проиндексировать - в целом да, на эту задачу можно создать отдельного агента со своими инструментами поиска/фильтрации
Увел в сторону, пардон - начал о наболевшем говорить.
Все верно, ваша тема получается агент для постгресс.
Возможно, желательно иметь простую настройку для агента, наподобие набора таблиц с которыми он работает и их маппинг на человеческий язык в бизнес задаче. А уже низкоуровневая связанность по ключам и создание запросов - работа агента, верно?
Создал агента для 5 таблиц , к примеру, описал их, дав им "человеческие" названия, описал выходные поля "по человечески" - к примеру, AMOUNT в таблице SALARY стал "зарплатой" - и вперед, отправляю текстовый запрос агенту?
Нужен открытый стандарт для интеграции подобных агентов.
Есть такие стандарты на уровне обсуждения или уже по факту у вендоров?
Спасибо
Стандарта нет, потому что слишком много частных случаев) В целом LLM достаточно умны, чтобы понимать что чем в БД является, особенно если есть метаданные и названия сущностей осмысленны. Собственно важность сбора и систематизации метаданных освещал в предыдущей статье
Вообще на мой диелитанский может взгляд, одна из проблем SQL как языка это очень слабые возможности по абстрагированию / инкапсуляции. То есть он как бы сразу подразумевает получение а) различной информации сразу б) обработку / вычисление информации прямо в запросе. Да, есть представления, но на практике там много вопросов с производительностью, да и использование их очень громоздкое, поэтому на практике представления используются не так часто.
Ну и плюс SQL достаточно низкоуровневый язык реляционной алгебры (с типами JOIN и вот этим всем), нет логики классов / объектов (которые вполне понятны ИИ и упрощают его работу)
В итоге соответственно ИИ нужно самому заниматься абстрагированием (причем не только низкоуровневых абстракций SQL, но и логики конкретного приложения), у него часто не хватает информации и т.п. Соответственно он и ошибается как не в себя.
Для эффективного ИИ нужно повышать уровень абстракции языка, а не пытаться научить ИИ тому, что далеко не все даже самые продвинутые программисты умеют делать.
Попробуйте MCP + примеры типовых запросов с джойнами с комментарием к каждому. МCP сам выдирает нужную часть структуры БД и строит запрос. На Postgre пишет прекрасно и локанично. В том числе со сложными структурами.
Проводил коллегам воркшоп как раз на эту тему и во время него аналитик, у которого с SQL лучше, чем у 80% разрабов, предложил один вариант, а Sonet 3,7 более локаничный и красивый с учётом не очевидных условий, подсмотренный в примерах. В качестве инструмента был Cursor.
Привет, Савелий!
Статья интересная. После прочтения понимаю, что сделать полноценную замену аналитику для получения ответов на ad-hoc запросов может быть трудной и даже не решаемой.
Как понимаю, у решения задачи, за которую Вы принялись, есть как преимущество - можно запрашивать действительно любые расчеты, а не только то, что уже считали; так и недостатки - помимо тех, что упомянули в статье, нет гарантии что два раза на один и тот же запрос вернутся одинаковые данные. А ещё, если вы предоставляете пользователю удобный интерфейс для ad-hoc, надо ожидать, что количество запросов возрастёт и даже если сами запросы будут предельно оптимальны, есть риск того, что узким горлышком станет производительность системы.
Что скажете?
LLM пайплайны укрощают сложность баз данных, или как мы подружили ИИ с БД без ИБД