Почему все бенчмарки врут (и как это исправить)
Заходишь на GitHub очередного memory system проекта — видишь красивые графики с "accuracy 95%" и "latency under 100ms". Загружаешь, пробуешь на своих данных — работает как черепаха в смоле, а точность ниже плинтуса. Знакомо?
Проблема в том, что большинство бенчмарков создают сами разработчики этих систем. Они оптимизируют под свои тестовые наборы, используют идеальные условия и сравнивают с устаревшими базами. Результат — красивые цифры, которые не имеют ничего общего с реальностью.
Когда я тестировал разные конфигурации железа для локального RAG, то столкнулся с тем, что одни и те же системы показывали разную производительность на разных наборах документов. Оказалось, что ключевая метрика — не точность поиска, а контекстуальная релевантность.
Главная ошибка: сравнивать системы памяти по одной метрике. Точность поиска векторов ≠ качество ответа LLM. Можно иметь идеальный recall и получить абсолютно нерелевантный ответ из-за плохого chunking.
Graphiti: архитектура, которая всех бесит (и почему она работает)
Graphiti на январь 2026 года — это не просто очередная векторная база. Это гибридная система, которая использует графовые структуры поверх векторных эмбеддингов. Разработчики заявляют, что она понимает связи между документами лучше, чем традиционные RAG.
Но вот что интересно: когда я тестировал её на наборе технической документации (помните тот случай с кодингом на RTX 3060?), Graphiti показывала странные результаты. На простых запросах — медленнее конкурентов. На сложных, где нужно понимать контекст между разными документами — в разы лучше.
1 Как НЕ надо тестировать Graphiti
Не используйте стандартные датасеты вроде HotpotQA или Natural Questions. Они созданы для тестирования фактоидных вопросов, а Graphiti заточена под сложные, многоуровневые запросы. Вы получите заниженные результаты и решите, что система плохая.
Вместо этого возьмите:
- Техническую документацию с перекрестными ссылками (например, API docs)
- Набор юридических документов, где один параграф ссылается на другой
- Историю чата поддержки с цепочками вопросов и ответов
2 Какие метрики считать для Graphiti
| Метрика | Что измеряет | Целевое значение |
|---|---|---|
| Cross-document recall | Находит ли связи между разными документами | >70% для сложных запросов |
| Context precision | Точность контекста для LLM (не просто поиск) | >80% |
| Graph traversal time | Время обхода графа связей | < 200ms на 1000 узлов |
MemGPT: когда контекстное окно — это не приговор
MemGPT на текущий момент (январь 2026) использует совершенно другой подход. Вместо того чтобы пытаться уместить всё в один промпт, система создаёт иерархическую память с разными уровнями доступа. Краткосрочная память для текущего диалога, долгосрочная — для важных фактов, архивная — для всего остального.
Когда я тестировал её на длинных диалогах (представьте чат поддержки на 1000 сообщений), MemGPT показывала интересный паттерн. Первые 50-100 запросов — медленно, потому что система строит иерархию. Дальше — ускоряется, потому что научилась эффективно переключаться между уровнями памяти.
3 Бенчмарки для MemGPT, которые имеют смысл
Забудьте про стандартные RAG бенчмарки. MemGPT нужно тестировать на:
- Long dialogue consistency — насколько последовательны ответы в длинном диалоге (100+ сообщений)
- Memory retention over time — как система сохраняет информацию через час, через день виртуального времени
- Context switching cost — сколько времени тратится на переключение между уровнями памяти
- Compression efficiency — насколько эффективно сжимается старая информация
Самый жестокий тест, который я проводил — дать MemGPT техническую документацию на 500 страниц, потом через 1000 сообщений в чате спросить детали из страницы 47. Хорошие системы справляются, плохие — начинают галлюцинировать.
Традиционные RAG системы: вектора, вектора, и ещё раз вектора
Chroma, Weaviate, Pinecone — все они построены вокруг векторного поиска. И здесь работает простое правило: чем лучше эмбеддинг модель, тем лучше работает вся система. Но есть нюанс, о котором почти никто не говорит.
Когда я настраивал RAG для работы с документами на чистом CPU (вспоминаем статью про Minimax на CPU), то обнаружил интересную закономерность. Самый большой bottleneck — не поиск по векторам, а создание этих самых векторов. Если у вас слабое железо, то 90% времени уходит на инференс эмбеддинг модели.
4 Что на самом деле важно в RAG бенчмарках
| Параметр | Почему важен | Как измерять |
|---|---|---|
| Chunking strategy | Определяет качество контекста больше, чем модель эмбеддингов | Сравнивать precision/recall для разных стратегий |
| Re-ranking time | Часто скрытый bottleneck в production | Время от поиска до финального ответа |
| Memory footprint | Критично для локальных инсталляций | Пиковое использование RAM/VRAM |
Создаём свой бенчмарк: от идеи до реализации
Готовые бенчмарки врут. Значит, нужно делать свои. Вот пошаговый план, который работает:
5 Шаг 1: Определяем use case
Не пытайтесь сделать универсальный бенчмарк. Определите конкретную задачу:
- Чат поддержки с историей на 10к сообщений
- Поиск по технической документации с cross-references
- Многосессионный диалог с персонализированными ответами
Для каждого use case — свой набор метрик. Чат поддержки измеряем по consistency, техническую документацию — по cross-document recall.
6 Шаг 2: Собираем реалистичные данные
Никаких синтетических данных. Берём реальные:
- Документацию популярных open-source проектов (GitHub)
- Публичные чаты поддержки (с соблюдением GDPR, конечно)
- Научные статьи с перекрестными ссылками
Объём данных должен быть репрезентативным. 100 документов — мало. 10000 — уже ближе к реальности.
7 Шаг 3: Определяем ground truth
Самый сложный этап. Нужно вручную разметить, какие ответы считать правильными. Делаем так:
- Берём 100 случайных запросов из реального use case
- 3 разных человека (эксперта в теме) размечают ожидаемые ответы
- Устраняем расхождения через обсуждение
- Получаем ground truth dataset
8 Шаг 4: Запускаем тесты на реальном железе
Тестируем на железе, которое будет в production. Если планируете запускать на RTX 5060 Ti — тестируйте на нём. Если на CPU с большим RAM — как в случае с 64 ГБ RAM и чистой CPU.
Измеряем не только точность, но и:
- Latency на 50-й, 90-й и 99-й персентиле
- Потребление памяти при росте размера базы знаний
- Время cold start (первый запрос после запуска)
- Время warm start (последующие запросы)
Ошибки, которые совершают все (и как их избежать)
Ошибка №1: Тестировать на маленьких датасетах. Системы памяти показывают реальную производительность только на объёмах от 10ГБ текста. На 100МБ все работают хорошо.
Ошибка №2: Игнорировать hardware constraints. Graphiti может быть точнее, но если она требует 128ГБ RAM, а у вас 32ГБ — выбирайте что-то другое. Помните статью про GB10 vs RTX vs Mac Studio? Железо определяет всё.
Ошибка №3: Тестировать только accuracy. Производительность в production — это баланс accuracy, latency и resource usage. Система с accuracy 95% и latency 5 секунд бесполезна в реальном чате.
Что выбрать в 2026 году: практические рекомендации
Исходя из последних тестов на январь 2026:
| Задача | Рекомендация | Почему |
|---|---|---|
| Техническая документация с cross-refs | Graphiti | Лучше понимает связи между документами |
| Длинные диалоги (чат поддержки) | MemGPT | Иерархическая память для сессий |
| Простой фактоидный поиск | Традиционный RAG (Chroma) | Проще, быстрее, достаточно точно |
| Ограниченные ресурсы (мало RAM) | Pinecone или Qdrant cloud | Вынос индекса в облако экономит ресурсы |
Но есть один важный нюанс: лучшая система памяти — та, которую вы можете поддерживать. Graphiti сложнее в настройке, требует больше экспертизы. MemGPT проще, но у неё свои причуды с управлением памятью.
Будущее систем памяти: что ждёт нас в 2027
Тренды на январь 2026 уже ясны:
- Гибридные подходы — комбинация графов, векторов и реляционных баз в одной системе
- Аппаратное ускорение — специализированные процессоры для работы с памятью LLM
- Распределённые системы — когда память распределена между несколькими узлами, как в статье про выделение памяти для AMD iGPU
- Adaptive memory management — системы, которые сами решают, что хранить, а что забывать
Мой прогноз: к концу 2026 мы увидим появление стандартных бенчмарков для систем памяти, которые будут учитывать не только точность, но и energy efficiency, cost per query и maintenance complexity.
А пока — делайте свои тесты. Не доверяйте красивым графикам. И помните: лучшая система памяти та, которая решает вашу конкретную задачу, а не выигрывает в абстрактных бенчмарках.
P.S. Если тестируете на слабом железе — посмотрите статью про модели, которые работают с промптами как у Claude Code. Там есть полезные insights про оптимизацию памяти.
