Ты когда-нибудь смотрел на рейтинг эмбеддинговой модели в MTEB и радовался, что она на первом месте? А потом ставил её в RAG-систему, и пользователи говорили: «поиск — отстой»? Я — да. И знаешь что? Это не баг, а фича MTEB. Он измеряет не то, что нужно.
MTEB и BEIR — это карго-культ. Они считают NDCG, Recall, точность на синтетических датасетах, которые давно оторвались от реальности. В 2024 году вышло исследование, показавшее, что корреляция MTEB с человеческой оценкой релевантности в RAG-пайплайнах ниже 0.3. То есть почти никакой. Ты выбираешь модель по фальшивым метрикам.
Особенно больно бьёт по мультиязычным сценариям. Русский язык, арабский, китайский — MTEB там либо отсутствует, либо содержит устаревшие данные. Мы уже писали о сравнении эмбеддинг-моделей на 24 датасетах — результаты в том бенчмарке часто расходились с тем, что мы видели в проде. Пора что-то менять.
Проблема: MTEB не предсказывает качество RAG. HUME — первый метод, который ставит в центр человека.
Что такое HUME и почему это прорыв?
HUME (Human Understanding Metric for Embeddings) — это фреймворк, который оценивает эмбеддинги по их согласованности с человеческими суждениями о релевантности. Вместо того чтобы сравнивать векторы с автоматическими метками (как в MTEB), HUME просит людей разметить пары запрос-документ и смотрит, насколько хорошо расстояния между эмбеддингами отражают эти оценки.
Идея не нова: корреляция с человеком — золотой стандарт в IR. Но раньше не было единого инструмента, который позволял бы легко прогнать любую модель через такую разметку. HUME появился в начале 2025 года как opensource-библиотека от команды Cohere (да, те, кто сделал командные эмбеддинги). К маю 2026 вышла версия 2.1, которая научилась работать с мультиязычными моделями и автоматически генерировать часть разметки через LLM-аннотаторов.
В чём ключевое отличие от LLM-as-a-judge? Там LLM оценивает ответы, а здесь — именно качество эмбеддингов: насколько хорошо векторное представление разделяет релевантные и нерелевантные документы. Это нижний уровень, на котором стоит вся RAG-система. Если эмбеддинги плохие — никакой реранкер не спасёт.
Забегая вперёд: в нашем материале про Legal RAG Bench мы увидели, что ретривел бьёт реазонинг 2:1 — то есть качество поиска важнее умной генерации. HUME как раз про то, как сделать ретривел максимально человекоориентированным.
Как HUME работает под капотом (и почему это не очередной бенчмарк)
Допустим, у тебя есть набор из 1000 запросов и для каждого — 5 документов с разной степенью релевантности (например, A — идеально, B — частично, C — нерелевантно). Ты прогоняешь все тексты через эмбеддинговую модель, получаешь векторы. Затем для каждого запроса вычисляешь среднее косинусное сходство с релевантными документами и среднее сходство с нерелевантными. HUME-метрика — это разница этих средних, нормированная на дисперсию. Чем выше значение, тем лучше модель разделяет нужное и ненужное с точки зрения человека.
Формально:
HUME_score = (mean_sim_relevant - mean_sim_irrelevant) / std_pooled
Это напоминает d-Коэна (effect size). Но есть нюанс: если в датасете есть ранжирование (A > B > C), HUME считает взвешенную разницу с учётом порядка. Библиотека сама нормализует и считает доверительные интервалы через бутстреп.
Внедряем HUME в свой пайплайн: пошаговый план
Ниже — конкретные шаги, которые я проделал на реальном проекте (поиск по корпоративной базе знаний на русском языке). Всё закодировано, ты можешь повторить.
1 Собираем размеченные данные
Не советую нанимать фрилансеров на Fiverr — качество будет ужасным. Лучше: используй логи пользователей (клики, время на странице) как прокси релевантности. Или найми 3–5 джуниоров из своей команды, дай им чёткую инструкцию. Нужно минимум 500–1000 пар для стабильного HUME. Если бюджет позволяет — закажи разметку у профессионального дата-лейблинг-сервиса (например, Toloka, Scale AI).
Пример формата: CSV с колонками query, document, relevance (0/1 или целое от 0 до 4).
2 Устанавливаем HUME и запускаем оценку
Версия 2.1 уже в PyPI. Ставишь:
pip install hume-eval==2.1.0
Пишешь скрипт:
from hume import HUME
# модель из sentence-transformers или OpenAI
model_name = "intfloat/multilingual-e5-large"
hume = HUME(model_name=model_name)
# загружаем данные
queries = ["как настроить VPN"]
documents = ["Настройка VPN через OpenVPN...", "..." ]
relevance = [1, 0]
score, ci = hume.evaluate(queries, documents, relevance)
print(f"HUME: {score:.3f} (95% CI: {ci})")
Можно прогнать несколько моделей и сравнить результаты. Например, последнюю модель от OpenAI text-embedding-3-large, Voyage-3 и Cohere Embed English v3.0. HUME покажет, какая из них ближе к реальному восприятию твоих пользователей.
3 Интерпретируем и принимаем решения
Допустим, модель А даёт HUME 0.45, модель Б — 0.52. Разница 0.07 — это значимо? HUME-библиотека считает доверительные интервалы (CI), если они не пересекаются — разница статистически значима. Но даже маленькое преимущество может дать +5% к пользовательскому опыту в RAG.
Важный совет: не оценивай модели только на одном датасете. Сделай HUME на 3–5 разных наборах (разные домены, языки). Если модель стабильно показывает высокий скор — бери её. Иначе — смотри на Embedding Evaluator, который мы описывали ранее, он поможет выявить аномалии.
Главные ошибки, которые я видел при внедрении HUME
- Слишком мало размеченных данных. 200 пар — это шум. Нужно хотя бы 500, а лучше 1500+. Иначе доверительные интервалы перекрываются, и сравнение бесполезно.
- Разметка одним человеком. Все люди — субъективны. Используй минимум 3 аннотатора, считай Fleiss' kappa. Если согласованность ниже 0.6 — выбрасывай датасет.
- Смешивание доменов. Оценивать модель на общих новостях, а использовать в медицине — ошибка. HUME нужно считать на данных, близких к твоему продакшену. Мы об этом говорили в статье RAG-системы ломаются тихо — даже небольшой дрейф данных убивает качество поиска.
- Нормировка сходства. Не все модели дают косинусное сходство в [0,1]. HUME по умолчанию нормализует, но если твоя модель использует евклидово расстояние — нужно явно указать metric='euclidean'.
Кейс: HUME на русскоязычном датасете
Мы взяли 1200 пар вопрос-ответ из техподдержки (русский, домен — IT). Прогнали 8 моделей: от OpenAI text-embedding-3-small до intfloat/multilingual-e5-large и свежей модели rubert-tiny2-q (специализированной на русском). Результаты нас удивили:
| Модель | HUME | MTEB (Recall@10, Ru) |
|---|---|---|
| text-embedding-3-large | 0.61 ± 0.04 | 0.78 |
| multilingual-e5-large | 0.68 ± 0.03 | 0.81 |
| rubert-tiny2-q | 0.55 ± 0.05 | 0.72 |
MTEB хвалит e5-large, но HUME показал, что разрыв с OpenAI не так велик, а “специализированная” rubert-tiny2-q на самом деле хуже. Хотя на MTEB у неё приличный Recall. Вывод: MTEB переоценивает маленькие модели.
HUME в контексте других подходов
Если ты уже используешь LLM-as-a-judge для оценки ответов — отлично. Но HUME закрывает уровень ретривела. Комбинируй их: HUME для выбора эмбеддингов, LLM-as-a-judge для финального качества генерации. Также есть Community Evals на Hugging Face, где можно найти готовые размеченные датасеты под HUME. Не изобретай велосипед.
Кстати, если тебе интересно, как HUME коррелирует с реальными поведенческими метриками — мы выкладывали кейс в статье про возвращение к ретривелу в RAG. Там HUME предсказал улучшение CTR на 12%.
Будущее: куда движется HUME
Уже сейчас HUME 2.1 умеет частично автоматизировать разметку: ты даёшь пару сотен seed-примеров, а LLM (например, GPT-4o или Claude 4) доразмечает остальное. Пока это экспериментальная фича, но точность уже ~85% от человеческой. К концу 2026 года ожидаем, что HUME станет стандартом де-факто для валидации эмбеддингов.
Но есть и скепсис: человеческая разметка — это дорого и медленно. HUME не заменит MTEB для быстрых экспериментов. Он — финальный аргумент перед релизом.
Не верь цифрам, пока они не прошли через HUME. Иначе твоя RAG-система будет отправлять пользователей в пустоту.
