Cohere сохраняет 98,4% качества поиска при быстрых запросах

У RAG-систем есть знакомая инженерная проблема: быстрый векторный поиск хорошо собирает кандидатов, но регулярно поднимает наверх фрагменты, которые похожи по словам, а не по смыслу вопроса. Если сразу передать их языковой модели, она получит лишний контекст, потратит больше токенов и с большей вероятностью выдаст уверенный, но неверный ответ.

Cohere выпустила Embed 5 и Rerank 5 в OpenRouter. Практический смысл релиза не в появлении ещё двух названий в каталоге моделей. Теперь через один API можно построить полный конвейер поиска: создать векторный индекс, найти кандидатов, точнее пересортировать их и только затем вызвать LLM. Отдельные аккаунты и SDK для Cohere не нужны.

Как разделяется работа

Индексирование происходит один раз для всего корпуса документов. Текст разбивается на фрагменты, после чего Embed 5 Pro превращает каждый фрагмент в вектор. Для документов указывается режим search_document, а векторы нормализуются, чтобы близость можно было считать обычным скалярным произведением.

При пользовательском запросе работает Embed 5 Fast в режиме search_query. Pro и Fast используют общее векторное пространство, поэтому индекс не приходится строить второй раз. По данным Cohere, запросы через Fast к индексу, созданному Pro, сохранили 98,4% качества полностью Pro-конфигурации на 40 наборах данных. Если использовать Fast и при индексировании, и при поиске, показатель снижается до 96,6%.

Представим базу документации с инструкциями по созданию, отзыву и замене API-ключей. Пользователь спрашивает, как сменить ключ без остановки сервиса. Векторный поиск находит правильную инструкцию, но рядом могут оказаться страницы про создание ключей, секреты вебхуков и ротацию логов. Они семантически близки, хотя не отвечают на вопрос.

Зачем нужен второй этап

Rerank 5 получает вопрос и примерно 10–20 найденных фрагментов, читает каждую пару целиком и возвращает более точный порядок. В примере Cohere правильная инструкция получила оценку 0,808, а два близких, но бесполезных результата не прошли порог 0,3. В языковую модель отправляется только очищенная подборка из трёх–пяти фрагментов.

Такое разделение разумно: первичный поиск отвечает за полноту, а реранкер — за точность. Запускать тяжёлое сравнение по всему индексу слишком дорого, зато перечитать короткий список кандидатов вполне реально. Если после фильтрации ничего не осталось, вызов LLM можно вообще пропустить и честно сообщить, что ответа в документах нет.

Cohere отдельно заявляет, что оценки Rerank 5 откалиброваны между запросами и предметными областями. Это позволяет использовать единый порог релевантности. Но воспринимать 0,3 как универсальную настройку не стоит: порог из демонстрации необходимо проверить на своих данных.

Что учитывать перед внедрением

Демонстрация использует NumPy как хранилище, поэтому подходит для прототипа, а не для промышленной нагрузки. В рабочей системе понадобятся pgvector, Qdrant, Pinecone, Weaviate или другая векторная база, контроль версий индекса и наблюдаемость по задержке, стоимости и качеству выдачи.

Размер фрагментов тоже влияет на результат. Слишком короткие теряют контекст, слишком длинные увеличивают стоимость реранжирования. Указанные в примере 1500 символов — лишь стартовая точка. Rerank 5 поддерживает до 32 тысяч токенов для пары запроса и фрагмента, но большой допустимый контекст не делает большие фрагменты автоматически полезными.

Практический следующий шаг — взять несколько десятков реальных вопросов пользователей, вручную отметить правильные документы и сравнить долю попаданий в первую пятёрку до и после реранжирования. Одновременно стоит измерить дополнительную задержку и стоимость. Если качество заметно растёт, схема Pro для индекса, Fast для запросов и Rerank для финального отбора даёт понятный способ ускорить RAG без полной перестройки системы.