Две вещи, которые эмбеддер не вытянет одним вектором

Эмбеддер сжимает запрос в один вектор и ищет ближайшие тексты. На фактоидных вопросах вроде «кто подписывает акт приемки» это работает отлично. Но есть две ситуации, где одного вектора не хватает, и под каждую мы сделали свое решение.

1. Многошаговые вопросы
«В каком году основали компанию, которая купила X?» Чтобы ответить, сначала нужно найти покупателя и только потом год его основания. Во втором документе нет ни слова из вопроса, и остается только надеяться, что он случайно попадет в топ-k.

Здесь нужен не один поиск, а цепочка: найти, прочитать, переформулировать, искать дальше. Для этого мы сделали поискового агента SMITH. На многошаговом бенчмарке MuSiQue один поиск эмбеддером дает nDCG@10 0.333, а SMITH делает в среднем 5–6 поисков на вопрос и доходит до 0.766.

Фронтирные LLM решают эту задачу так же, через ReAct: подумать, поискать, прочитать, поискать снова. Но SMITH в 8 раз дешевле того же DeepSeek V3.2. Какие проблемы он решает, я подробно рассказывал в выступлении на AI R&D Day.

2. Разные задачи требуют разной «похожести»
Для поиска похожи вопрос и абзац с ответом. Для дедупликации похожи два пересказа одного текста. Для классификации похожи тексты одной темы, даже если они про разное. Один и тот же вектор не может быть хорош во всем сразу.

Поэтому у FRIDA есть префиксы: search_query: и search_document: для поиска, paraphrase: для дублей и перефразов, categorize_topic: для группировки по темам и еще несколько. Модель одна, а поведение переключается словом в начале текста. Забыть префикс или перепутать его — одна из самых частых причин, почему «модель ищет хуже, чем на бенчмарке». Как это оценивать и развивать, я рассказывал в докладе «Оценка и развитие инструктивных способностей эмбеддинг-моделей».

Итого, если поиск не находит то, что точно есть в базе, проверьте две вещи: не многошаговый ли вопрос и тем ли префиксом/инструкцией закодированы тексты.

А как вы решаете многошаговый поиск? И используете ли один эмбеддер для разных задач?