Forwarded from Machinelearning
Он выступает прослойкой между вашим агентом (например, LangChain, LlamaIndex, VertexAI) и базой данных, упрощая работу с базой, подключение, управление, безопасность и мониторинг.,
Подходит для разработки AI-агентов, которые могут создавать и управлять в реальными БД.
Особенности:
Если делаете агентов, которые работают с
SQL/PostgreSQL/MySQL — точно стоит попробовать.▪ GitHub: https://github.com/googleapis/genai-toolbox
@ai_machinelearning_big_data
#AI #ML #aiagent #opensource #MCP #databases #genai
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10🔥7👍5
📊 Новое поколение баз данных для ИИ-агентов
Когда LLM-агенты работают с БД, они не делают один большой запрос. Вместо этого они засыпают систему тысячами мелких пробных запросов: проверяют структуру, ищут связи, тестируют планы. Это явление получило название agentic speculation. Итог — колоссальный перерасход ресурсов.
🆕 Исследователи предлагают «agent-first database» — базу, спроектированную с учётом поведения агентов.
🔑 Как это работает:
- Агент отправляет не просто SQL-запрос, а пробу с брифом: какая цель, на каком этапе он сейчас, какая нужна точность и что в приоритете.
- База может дать приближённый ответ, если данных уже достаточно, вместо того чтобы тратить ресурсы на полный расчёт.
- Запросы поддерживают семантический поиск по таблицам и строкам, что в SQL выразить сложно.
⚙️ Внутренние механизмы:
- Sleeper agents подсказывают лучшие join’ы, объясняют пустые результаты и оценивают стоимость запросов.
- Оптимизатор проб объединяет похожие запросы, кэширует частичные результаты и выдаёт быстрые ответы, когда «достаточно сигнала».
- Agentic memory хранит знания, которые можно переиспользовать в будущем.
- Общий менеджер транзакций позволяет быстро пробовать разные сценарии («what-if») без лишних затрат.
📌 Вывод: традиционный SQL не подходит для эпохи LLM. Нужны базы, которые понимают стратегию агента, сокращают лишние шаги и экономят ресурсы.
🔗 Paper: arxiv.org/abs/2509.00997
#AI #Databases #LLM #Agents
@sqlhub
Когда LLM-агенты работают с БД, они не делают один большой запрос. Вместо этого они засыпают систему тысячами мелких пробных запросов: проверяют структуру, ищут связи, тестируют планы. Это явление получило название agentic speculation. Итог — колоссальный перерасход ресурсов.
🆕 Исследователи предлагают «agent-first database» — базу, спроектированную с учётом поведения агентов.
🔑 Как это работает:
- Агент отправляет не просто SQL-запрос, а пробу с брифом: какая цель, на каком этапе он сейчас, какая нужна точность и что в приоритете.
- База может дать приближённый ответ, если данных уже достаточно, вместо того чтобы тратить ресурсы на полный расчёт.
- Запросы поддерживают семантический поиск по таблицам и строкам, что в SQL выразить сложно.
⚙️ Внутренние механизмы:
- Sleeper agents подсказывают лучшие join’ы, объясняют пустые результаты и оценивают стоимость запросов.
- Оптимизатор проб объединяет похожие запросы, кэширует частичные результаты и выдаёт быстрые ответы, когда «достаточно сигнала».
- Agentic memory хранит знания, которые можно переиспользовать в будущем.
- Общий менеджер транзакций позволяет быстро пробовать разные сценарии («what-if») без лишних затрат.
📌 Вывод: традиционный SQL не подходит для эпохи LLM. Нужны базы, которые понимают стратегию агента, сокращают лишние шаги и экономят ресурсы.
🔗 Paper: arxiv.org/abs/2509.00997
#AI #Databases #LLM #Agents
@sqlhub
👍11❤9🔥4👎1
🟡🔵 Разбираемся с SQL JOIN и фильтрами в OUTER JOIN
Одна из самых частых ошибок при работе с SQL - путаница между условием в
Когда мы пишем
✨ Пример:
У нас есть две таблицы:
- Левая: фигура + число
- Правая: число + фигура
Мы делаем
1. Фильтр в ON
Если написать
2. Фильтр в WHERE
Если написать
⚡ Почему это нужно знать?
-
-
- В
📌 Вывод:
- Если нужно оставить все строки из левой таблицы и лишь добавить совпадения справа - фильтр ставим в
- Если хотим действительно отобрать только подходящие строки — фильтр в
Именно поэтому в сложных запросах всегда спрашивай себя: фильтр — это часть логики соединения или это окончательное ограничение?
#SQL #joins #databases
Одна из самых частых ошибок при работе с SQL - путаница между условием в
ON и фильтром в WHERE. На картинке это отлично показано.Когда мы пишем
LEFT OUTER JOIN, мы ожидаем, что слева попадут все строки. Но результат зависит от того, где именно мы накладываем фильтры.✨ Пример:
У нас есть две таблицы:
- Левая: фигура + число
- Правая: число + фигура
Мы делаем
LEFT OUTER JOIN. 1. Фильтр в ON
Если написать
ON right_table.number = 1, то соединение будет проверять условие именно во время джойна. Это значит: строки слева сохранятся, даже если справа нет совпадений — просто будут NULL.2. Фильтр в WHERE
Если написать
WHERE left_table.number = 1, то фильтрация произойдёт уже после объединения. В этом случае строки, не прошедшие условие, полностью исчезнут из результата.⚡ Почему это нужно знать?
-
ON управляет логикой соединения. -
WHERE убирает строки после соединения. - В
OUTER JOIN это принципиальная разница: при фильтре в ON мы сохраним «пустые» строки, при фильтре в WHERE они будут удалены. 📌 Вывод:
- Если нужно оставить все строки из левой таблицы и лишь добавить совпадения справа - фильтр ставим в
ON. - Если хотим действительно отобрать только подходящие строки — фильтр в
WHERE. Именно поэтому в сложных запросах всегда спрашивай себя: фильтр — это часть логики соединения или это окончательное ограничение?
#SQL #joins #databases
❤9👍9🔥5