PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря В PostgreSQL уже хранятся пользователи, заказы и платежи, а потом стек начинает расти сам собой, когда рядом появляются Redis для очереди задач, отдельный Python-скрипт для дедупликации событий, Go-цикл, который считает интервалы между статусами заказа, свой поисковик вместо простого поиска по тексту и самодельная таблица locks для координации воркеров. Большая часть этой инфраструктуры дублирует то, что PostgreSQL умеет делать сам, причём атомарно, транзакционно и с индексами, без лишней сетевой болтовни между приложением и базой. Механизм, который снимает необходимость в отдельном брокере задач, живёт в PostgreSQL ещё с версии 9.5, просто про него редко вспоминают. Та же история с оконными функциями, полнотекстовым поиском и блокировками на уровне базы, где задачи, ради которых обычно поднимают отдельный сервис, часто закрываются прямо в таблице. Обсудим, сколько из этой цепочки сервисов держится просто на привычке.

Сегодня разбирал paper про память для AI агентов решил собрать инфу в пост Из чего состоит любая такая память (4 части) Первое — как хранить: просто текстом, деревом (от общего к деталям) или графом (факты связаны стрелками — кто с кем и когда связан). Второе — что записывать: вытаскивать из разговора отдельные факты или сохранять всё подряд. Третье — как искать нужное: по смыслу, по ключевым словам, по связям в графе или дать самому ИИ решить, что искать. Четвёртое — как поддерживать порядок: обновлять факты, удалять устаревшее, сжимать лишнее. Главные выводы: 1. Идеальной системы нет — каждая хороша под свою задачу. Для обычных диалогов лучше «гибридные» (MemOS , MemoryOS ), для поиска конкретных фактов — графовые (Zep , Cognee ). Но графовые плохо отвечают на вопросы вида «что было раньше, а что позже». 2. Чем старее нужный факт, тем хуже его находят. Если что-то было сказано много сообщений назад, система часто это упускает. 3. Обновления фактов лучше всего держат графовые системы. Простые системы, которые только «дописывают» новое, плохо умеют заменять старый факт на новый — и потом выдают устаревшую информацию (авторы называют это «галлюцинациями прошлого»). 4. На длинных историях простые системы часто ломаются. Причём для вопросов, где важен порядок во времени, иногда выгоднее вообще не мудрить с памятью, а скормить модели весь текст целиком — потому что «умное сжатие» стирает подсказки о том, что за чем шло. 5. Дороже — не значит лучше. Навороченные системы тратят в разы (иногда в сотни раз) больше времени, но точность не всегда выше. Часто выгоднее что-то лёгкое (LightMem , MemTree). Ещё пара наблюдений: лучше сохранять исходный текст разговора, чем агрессивно его сжимать; и не стоит слишком сильно фильтровать факты при записи — потом их может не хватить для рассуждений. Итог: готовой «идеальной» памяти для агентов пока нет, и систему нужно подбирать под конкретную задачу. Плюс можно еще посмотреть в сторону провайдеров памяти для Hermes, сам хочу покопать в сторону OpenViking(понравился core-concept ) и Hindsight - is the most accurate agent memory system (но аккуратный не всегда значит, что полезный для работы)

Пока мир сходит немного с ума с нейронками по паспорту и опенсорс суверенными моделями, я решил начать читать настоящую базу - книгу Эванса по DDD. По ощущениям я снова оказался в той ситуации, где мне нужно разъяснение, а как код то писать надо. Первый раз меня подтолкнула книга "Чистая архитектура", где я понял, зачем интерфейсы вообще нужны. Пока что, прочитав 1 главу, которая посвящена тому, как говорить заказчиком про ТЗ, буквально. Мне этой проблемы не понять, может ранее программисты напрямую общались с заказчиком, а не через менеджеров, и им реально приходилось вытаскивать адекватные требования из людей. Да и не понял я момента, где он говорит, что должен быть поток обратной информации от разработчика. Однако довольно интересный момент в 1 главе есть. А именно замечание о том, что какие-либо правила системы не надо прятать в операциях, а надо выносить на уровень хотя бы методов. И делать это надо не ради расширяемости или чего-то еще, а что бы просто ментально было понятно, что тут не просто домножение на10 или деление на 3, а специальная операция для определенной цели.