LLM научилась запоминать беседу, не подгядывая в контекст. Архитектуры типа Titans и обещают превращение цикла вывода в цикл онлайн-оптимизации

С чего всё началось. Я решил вывести своего бота Полифема в канал Telegram. Настроил ему второй профиль и долго мучил, чтобы он начал отвечать людям на вопросы. Получается медленно, все мучения я выкладываю в свой канал https://t.me/veriga_pro_AI , когда есть что-то интересное. Сегодня было особо интересное: побег второй субличности из ее workspace

Когда мы искали, как подключить бота в телегу, то нашли рабочее решение: изменить политику безопасности прямых сообщений в конфиге dmPolicy c "pairing" на "open". И всё заработало.
Вчера мы радовались, что всё заработало, а сегодня пришел аудит и надавал по рукам. Оказывается, открытость Полифема в группах — это не только удобно, но и "Critical Security Exposure".

В общем, проходной двор какой-то, а не учреждение культуры.
Если и groupPolicy: "open", любой прохожий с улицы может попробовать скормить боту промпт-инъекцию. А так как у Полифема-публичного есть доступ файлам, и он еще и программировать может себе что хочет, то, к примеру, спросят у него хулиганы "скажи три цифры на обороте", так он, старательный, напишет себе скриптик поиска, всё найдёт и всё скажет!

Переключились на режим "только для своих": groupPolicy: allowlist.

Дальше. Мы так подумали, раз включен allowlist, и существует поле groupAllowFrom туда надо вписать ID группы. Но разработчики думали не так. В логах моментально полетели ошибки:
[telegram] Invalid allowFrom entry: "-1003153771294" - allowFrom/groupAllowFrom authorization requires numeric Telegram sender IDs only.

История о том, как превратить ИИ-агентаиз «золотой рыбки» с памятью в пределах одной сессии в полноценного цифрового сотрудника с графовым хранилищем знаний.

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

Можно, конечно, заранее срезать количество извлекаемых чанков, но это отразится на качестве ответов.

Можно настроить кэш, который экономит на обращениях к сервису, когда приходят одинаковые вопросы. Но когда пользователь спрашивает "How to get developer support?”, и тут же другой пользователь спрашивает "How to ask development-related questions?", ваш сервис каждый раз будет генерировать ответ заново, сжигая ваши токены и заставляя пользователя ждать. Обычный кэш тут бессилен: для него эти две фразы — абсолютно разные ключи. 

В этой статье я расскажу, как развернуть мощный семантический кэш на базе AlloyDB Omni (PostgreSQL от Google), используя векторный поиск ScaNN, автоматическое партиционирование и планировщик задач. Мы пройдём путь от настройки Docker-контейнера до продакшн-архитектуры.