Тесты Rerank в Obsidian на 64 и 500 заметках
Разработчик добавил Rerank в плагин для Obsidian и проверил, оправдана ли вторая модель при каждом поиске. На малой базе выигрыш оказался редким, на большой — оценка целых документов скрывала различия фрагментов.
Разработчик плагина Veynrel для Obsidian (ранее Vault Audit AI) добавил в него функцию Rerank — второй этап поиска, при котором специальная модель переоценивает релевантность уже найденных заметок. Идея простая: сначала обычный семантический поиск находит близкие по смыслу фрагменты, а затем cross-encoder получает вопрос и документы вместе и расставляет их по полезности. Автор решил проверить, насколько часто такой второй этап реально улучшает выдачу и оправдывает расходы на внешние запросы.
Для теста он собрал синтетическое хранилище из 64 Markdown-заметок, которые разбились на 80 фрагментов, и подготовил 28 поисковых запросов. Для 24 вопросов в корпусе существовал релевантный ответ, ещё четыре были заведомо без ответа. Сравнивались три Rerank-модели, но основной эксперимент проводился на Voyage Rerank 3 Lite — она прошла проверку адаптера и оказалась достаточно дешёвой.
Результаты на 64 заметках оказались неожиданными: Rerank улучшил nDCG@10 в 11 случаях, ухудшил в двух и оставил без изменений ещё 11. При этом обычный семантический поиск уже ставил релевантную заметку первой в 23 из 24 случаев, а Rerank смог исправить первый результат только однажды. Иными словами, на небольшом корпусе вторая модель почти не давала выигрыша, но добавляла задержку и стоимость запроса.
Отдельный тест на демонстрационном хранилище из 500 заметок выявил другую проблему: оценка целых документов скрывала различия между выбранными фрагментами. Даже если документ в целом релевантен, конкретный фрагмент, попавший в выдачу, мог не содержать ответа. Это ограничение архитектуры: Rerank работает только с кандидатами первого этапа и не может найти заметку, которую семантический поиск не включил в топ-30.
Автор также отмечает вопросы приватности и стоимости. Для Rerank нужен читаемый текст документов, поэтому при использовании облачной модели фрагменты заметок отправляются внешнему провайдеру при каждом уточнении. С облачными embeddings ситуация похожая, но там передача происходит только при построении индекса, а не при каждом поиске. В тесте на четырёх коротких вопросах Voyage оказалась примерно в 392 раза дешевле Cohere при сопоставимой задержке, однако тарификация у моделей разная, и на других объёмах соотношение может измениться.
По итогам экспериментов разработчик отказался от автоматического запуска Rerank при каждом поиске. Вместо этого в Veynrel появилась отдельная кнопка уточнения, которую пользователь может нажать, если не удовлетворён первоначальной выдачей. Такой подход позволяет сохранить контроль над расходами и задержкой, не отказываясь от потенциальной пользы второго этапа в сложных случаях. Плагин остаётся open-source и доступен на GitHub и в Obsidian Community Plugins.
Материал подготовлен ИИ-редакцией «Сигнала» как пересказ публикации первоисточника. Фактическую точность и подробности проверяйте по оригиналу.