Агентам дали писать базу Perplexity, но не запускать её

Сотни кодовых агентов участвовали в разработке базы данных, которая сейчас держит часть боевого поиска Perplexity, и ни один из них не получил доступ к продакшену. Как пишет Thenewstack, два инженера с помощью этих агентов за два месяца собрали CobbleDB, хранилище ключ-значение на Rust примерно на 40 000 строк.

Коротко

• CobbleDB уже обслуживает часть боевого поискового трафика Perplexity, компания ждёт от неё экономии минимум 20% относительно DynamoDB и обещает когда-нибудь открыть исходный код.
• Медианное пакетное чтение после переезда составило 5,6 мс против 31,4 мс на DynamoDB, на p99 цифры упали со 123 до 24,2 мс, замеры сняты примерно на 200 000 запросов в секунду.
• Сравнение не лобовое: показатели DynamoDB записаны до переключения, а CobbleDB после, и в оценку экономии не заложены зарплаты инженеров, которые эту базу будут поддерживать.

Если вы не следили: обработанные страницы Perplexity писала прямо в DynamoDB, поэтому крупная переобработка корпуса, скажем при смене чанкера или модели эмбеддингов, конкурировала с живым поисковым трафиком. DynamoDB берёт деньги за объём чтений и записей, а система, которая не перестаёт краулить и пересчитывать индекс, наращивает счёт вместе с корпусом. В какой-то момент эти расходы стало трудно оправдывать.

Один вызов Search API тянет 100–120 ключей

Каждый поисковый запрос заставляет слой выдачи доставать заранее нарезанные куски текста и векторные эмбеддинги. Один вызов Search API забирает от 100 до 120 ключей страниц, разбитых на пачки по 10–20, а средний элемент весит около 50 КБ.

DynamoDB почти не давала Perplexity рычагов над тем, как обслуживаются чтения: ни выбора реплики, ни контроля над кэшем и размещением данных. Одна медленная реплика или лишний переход между зонами доступности растягивали всю пачку. К этому добавлялся счёт за ровный поток крупных чтений и записей, который порождают поиск, краулинг и переобработка. Отсюда решение развести долговременное хранение документов и ту базу, что обслуживает живой поиск.

Медиана пакетного чтения: 5,6 мс против 31,4 мс

Цифры сняты на нагрузке примерно в 200 000 запросов в секунду. Медианное пакетное чтение на CobbleDB заняло 5,6 мс против 31,4 мс, записанных на DynamoDB, на p99 разрыв похожий: 24,2 мс против 123 мс. По данным AIM, p90 при этом снизилась с 56,7 до 9,77 мс.

В более поздних нагрузочных тестах CobbleDB дошла до 500 000 запросов в секунду, после чего производительность начала проседать. Отдельно Perplexity гоняла синтетические бенчмарки на пачках по 10–15 ключей со значениями от 100 байт до 100 КиБ. Модель расходов даёт минимум 20% экономии относительно DynamoDB по всем рассмотренным вариантам обязательств.

Три яруса: Pillar, Lorry и сама CobbleDB

Долговременное состояние документов лежит в Pillar: версионированные метаданные, куски текста и эмбеддинги в YTsaurus на жёстких дисках. Lorry собирает обновления в пачки под конкретную партицию и прогоняет их через S3 до CobbleDB, где каждая реплика применяет их самостоятельно.

Работает это как склад и магазин: тяжёлый товар лежит на складе, в торговый зал он приезжает коробками по расписанию, и если одна касса задержалась с выкладкой, остальные не ждут. Обработанные страницы разложены по трём репликам на партицию, ключами служат хешированные URL, RocksDB держит горячее в памяти, остальное остаётся на локальных NVMe. Чтение по возможности не выходит за пределы своей зоны доступности, а если реплика отвечает медленно, роутер пробует другую вместо того, чтобы тормозить всю пачку.

Агенты тащили контекст между сессиями, но не запускали базу

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

Профессор CMU Энди Павло в этом году на Percona Live говорил, что базы данных — самая трудная и самая важная задача для ИИ-агентов, в том числе потому, что ошибки с боевыми данными бывает трудно или невозможно откатить. По данным daily.dev, он относит к неподъёмным местам оптимизатор запросов и описывает подход Agent Boosting, который, по его оценке, мог бы сократить оптимизацию базы с 12 часов до 15 минут. Похожим путём шли Shopify и Ramp: они оставили чужие модели, но построили вокруг них собственных кодовых агентов.

Главная оговорка в измерениях: DynamoDB и CobbleDB не гоняли бок о бок на одинаковом трафике, цифры сняты в разное время и на разных системах. По данным remio, Perplexity не публиковала ни аудированного сравнения стоимости, ни полной модели операционных расходов, ни исходного кода. На наш взгляд, самая слабая часть здесь именно оценка в 20%: она честно не включает инженеров, которые будут чинить базу в три часа ночи, а это и есть настоящая цена владения.

Когда откроют код CobbleDB

Дату публикации исходников Perplexity не называет, сказано лишь, что открыть код планируют. Гендиректор Аравинд Шринивас утверждает, что переход на собственную инфраструктуру вроде CobbleDB может сэкономить компании до ста миллионов долларов в год. Проверить это со стороны пока не на чем: ни развёрнутой модели расходов, ни данных о том, какая доля поискового трафика уже переехала, Perplexity не приводит.