Bad CaRMa: нейросеть «квартет» показала на 31 млрд записей, почему не повторит крах Vision

Название Bad CaRMa, каламбур на CRM и «карму», отсылает к истории из книги Розенберга. В 1993 году компания Upstart запустила CRM-систему Vision: архитектор сложил все 150 с лишним бизнес-сущностей в одну таблицу DATA с 240 колонками вроде string82 и numeric31. Простой поиск клиента требовал от 6 до 10 рекурсивных соединений таблицы с самой собой, 50 ГБ данных за год обросли ещё 250 ГБ индексов, и система встала. По данным книги, убыток составил около 10 млн долларов, а Upstart вскоре продали. Авторы «квартета» строят похожую на первый взгляд архитектуру для памяти ИИ-агента и в новой публикации объясняют, почему их путь не ведёт к тому же тупику.

Четыре проблемы Vision и как их решает «квартет»

Авторы выделяют четыре «грабли», которые превращают любую обобщённую модель (EAV, то есть «сущность, атрибут, значение», подход, где строка хранит не запись целиком, а одно свойство) в «плохую карму»:

• Нет типов, всё хранится как строка. В Vision дата вроде «2026-13-99» ложилась в базу без ошибки. В «квартете» базовые типы (число, дата, текст, ссылка) зашиты в ядро. Всё, что выходит за их пределы, становится пользовательским типом-термином, а ссылка хранится как настоящая связь, а не как текст.
• Невозможно запросить без десятков соединений. У Vision простой отчёт превращался в SQL-запрос, который планировщик базы не хотел выполнять. В «квартете» контроллер (промежуточный программный слой) сам собирает строки, таблицы и отчёты, компилируя их в SQL с нативной рекурсией. Разработчик не пишет соединения руками.
• Индексы деградируют, производительность падает. Vision встал, когда данные выросли. «Квартет» использует композитные покрывающие индексы (по типу и значению, по родителю и типу, отдельные рёберные индексы для связей), доступ идёт по индексному пути, а не полным сканированием.
• Inner-platform effect (своя СУБД поверх СУБД, только хуже). Vision фактически изобретал базу данных заново. Контроллер «квартета» не заменяет СУБД, а транслирует запросы в стандартный SQL.

Замеры на живой базе, а не теория

Публикация приводит две группы цифр.

Первая, внешний проект: 31 млрд записей-«квартетов», 4,5 ТБ данных, партиции (разделение таблицы на части) по диапазонам, разнесённые по физическим дискам. Точное совпадение отдаётся за 0,77 секунды, поиск по маске за 1,57 секунды, сбор всех реквизитов записи за 0,95 секунды.

Вторая, собственная база памяти ИИ-агента (корпус тикетов ydb-platform/ydb): 133 731 «квартет», 418 типов, 168 МБ данных и 40 МБ индексов. Ноутбучный PostgreSQL без партиций. Результат: на полностью прогретом кэше запросы укладываются в десятые доли секунды, скрипт замера печатает план запроса вместе со временем.

Соотношение данных к индексам тоже показательно: 168 МБ данных и 40 МБ индексов, а не 50 ГБ данных и 250 ГБ индексов, как у Vision. Индексы занимают около четверти объёма данных, а не пятикратный размер.

Зачем это памяти ИИ-агента?

Память агента из предыдущих публикаций авторов устроена как граф: узлы (заметки, тикеты, решения) и типизированные рёбра между ними («из-за этого», «исправлено вот этим»). Весь причинный recall (способность находить прошлое решение по цепочке причин и следствий), который, по данным авторов, поднял точность поиска прошлого решения с 38% до 87%, работает через обход этого графа.

Граф лежит не в графовой СУБД и не в векторном движке, а в той самой таблице из четырёх колонок: id записи, up (родитель), t (тип), val (значение). Если обобщённая модель обречена на деградацию, обход графа станет невозможным при росте базы, и все метрики превратятся в лабораторный курьёз.

Публикация Bad CaRMa, по сути, отвечает на этот вопрос замерами: нет, не обречена, если добавить типы, контроллер и индексы.

Как попробовать

1. Прочитайте полную публикацию Bad CaRMa на сайте авторов, ссылка дана в оригинальном материале.
2. Посмотрите предыдущие статьи серии: там описан корпус тикетов ydb-platform/ydb и методика замера recall (38% против 87%).
3. Если вы работаете с PostgreSQL, обратите внимание на описанную схему индексов: композитные покрывающие индексы по (t, val) и (up, t), они применимы и вне модели «квартет».

Есть ли аналоги в России?

Прямого аналога модели «квартет» среди массовых российских инструментов нет. YandexGPT и GigaChat решают другую задачу: генерация текста, а не хранение структурированной памяти агента. Для тех, кто строит ИИ-агентов на российском стеке, публикация полезна как инженерный шаблон: PostgreSQL доступен в РФ, описанная архитектура не завязана на зарубежные облака.

Что с этого вам, по ролям

Автору Дзена. Bad CaRMa нейросеть и память агента, тема, на которой можно объяснить аудитории разницу между «ИИ запомнил» и «ИИ нашёл причину». Публикация даёт конкретный кейс с цифрами для разбора.

Разработчику и техническому предпринимателю. Если вы проектируете память для ИИ-агента и рассматриваете EAV-подход, здесь описана работающая схема: квартет плюс контроллер плюс индексы. Главный урок: голый EAV без типов и контроллера действительно «плохая карма», но это лечится инженерией, а не отказом от обобщённой модели.

Маркетологу. Тема Bad CaRMa нейросеть хорошо ложится в контент про «как не повторить чужие ошибки». История Vision (10 млн долларов убытка, 13 месяцев жизни) цепляет даже нетехническую аудиторию.

Частые вопросы

Bad CaRMa это нейросеть?

Нет. Bad CaRMa это название технического разбора, каламбур на CRM и «карму». Речь идёт об архитектуре хранения данных для памяти ИИ-агента, а не о нейросетевой модели. Нейросеть (агент) использует эту архитектуру как внешнюю память, но сама архитектура, обычная реляционная база данных.

Можно ли применить этот подход без глубоких знаний в базах данных?

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

Модель «квартет» существует только в экспериментах?

По данным авторов, модели больше двадцати лет. Идея оформилась в 2002 году, в веб-архиве сохранились сайты 2003 и 2005 годов на IDEAV, в производстве она с 2006-го, текущая структура устоялась к 2008 году. С 2015-го на ней ведётся разработка в разных проектах. Это не стартап-эксперимент, а зрелая, проверенная временем архитектура.