T-Search: как открытый агент ищет доказательства для сложных запросов
T-Search — открытый агентный ретривер Т-Банка. Он ищет доказательства в несколько раундов и отдаёт ранжированные сниппеты, но требует собственного backend и генератора.
По состоянию на 17 июля 2026 года T-Search — открытый агент-ретривер Т-Банка для сложного многошагового поиска на русском и английском языках. Он не пишет финальный ответ: модель формулирует запросы, изучает найденные сниппеты и возвращает ранжированный набор доказательств для следующего компонента системы.
Новый ретривер заменяет один поисковый запрос управляемой серией шагов. Но готового поисковика здесь нет. Для запуска нужны собственный корпус, поисковый backend, официальный harness и отдельная модель, которая превратит найденные фрагменты в ответ.
Что такое T-Search и где его место в RAG
Модель построена на Qwen3.6-35B-A3B и дообучена именно как агентный ретривер. Её задача заканчивается там, где у обычного чат-бота начинается генерация: на выходе остаются сниппеты, их порядок, исходный поисковый запрос и оценка релевантности из подключённого backend.
Такое разделение полезно в корпоративном RAG-конвейере. Ретривер можно оценивать по полноте доказательств, а генератор — по точности ответа и цитатам. Если итоговый текст ошибся, команда видит, на каком этапе потерялся факт.
| Компонент | Что получает | Что возвращает | Источник |
|---|---|---|---|
| Одношаговый retrieval | Один запрос к корпусу | Топ найденных фрагментов | анонс Т-Банка |
| T-Search | Вопрос, поисковый backend и состояние прошлых раундов | Ранжированный набор evidence-сниппетов | model card |
| Генератор ответа | Ранжирование ретривера или полные документы после дополнительной загрузки | Ответ в нужном продукту формате | README harness |
Как агентный ретривер работает по раундам
Одна поисковая сессия содержит до пяти раундов. Каждый раунд начинается с чистого контекста, куда попадают исходный вопрос, ранее сохранённые сниппеты и компактное состояние: какие части задачи уже подтверждены, что осталось проверить, какие попытки не сработали и куда двигаться дальше.
Внутри раунда агенту доступны три инструмента. search_corpus обращается к поисковому backend, save_and_advance сохраняет полезные фрагменты и открывает новый раунд, а finalize_ranking завершает работу и собирает итоговое ранжирование. Полная история вызовов между раундами не переносится.
Бюджет контекста на раунд составляет 32 768 токенов. Когда занято 75%, новые поисковые запросы блокируются: агент должен сохранить память или завершить ранжирование. Эта механика близка к подходу со структурированной памятью AI-агентов, где между длинными этапами переносят не весь диалог, а проверенное рабочее состояние.
Поиск не растёт бесконтрольно до заполнения окна. Решение агента сохранить конкретный чанк становится частью трассировки: разработчик видит, почему документ пережил смену раунда и попал в финальный список.
Бенчмарки агентного поиска и цена качества
Авторы оценивают модель по Recall@10 на фиксированных индексах. По их данным, T-Search с одним запуском получил в среднем 55,96, а режим N=3 — 61,33. Базовая Qwen3.6-35B-A3B в той же таблице набрала 41,54. Разница составляет 14,42 и 19,79 пункта соответственно.
Цифры получила команда модели с опубликованным harness; Toolarium не проводил независимый прогон. Режим N=3 запускает три траектории параллельно и объединяет ранжирования методом reciprocal rank fusion. Шанс найти пропущенный фрагмент растёт вместе с вычислительной нагрузкой.
Второй график показывает цену дополнительных раундов. Переход от одного раунда к трём и пяти увеличивает среднюю полноту, но одновременно сдвигает систему вправо по оси задержки. Тот же эффект виден у N=3: качество выше, однако один запрос занимает больше времени.
Продуктовой команде поэтому нужен собственный тест на реальном корпусе. Для офлайн-исследования минута ожидания может быть приемлемой, а для поддержки клиента — нет. Сравнивать стоит не только Recall@10, но и задержку, число вызовов поиска, стоимость генерации и долю ответов, которые действительно получили нужные доказательства.
Авторы model card не увидели заметного отличия от базовой Qwen3.6-35B-A3B на общих бенчмарках. Универсального апгрейда языковой модели здесь нет: выигрыш относится к специализированному поисковому режиму.
Интеграция с корпоративным поиском и RAG
Официальный harness написан на Python 3.10 и новее. Модель разворачивается за OpenAI-совместимым endpoint, а поисковый слой подключается через один метод search(query, top_k). Backend должен вернуть JSON со списком объектов docid, snippet и score.
- Разверните
t-tech/T-Searchи проверьте совместимость с OpenAI API. - Подключите свой BM25, векторную базу или поисковый сервис к контракту harness.
- Передайте результат
agent.retrieve(query)генератору, переранжировщику или загрузчику полных документов.
Последний шаг принципиален: harness возвращает те сниппеты, которые увидел во время поиска, но не загружает полные документы. Если генератору нужен расширенный контекст, приложение должно получить исходные тексты по идентификаторам чанков.
README допускает запуск других моделей, но устойчивый режим авторы обещают только для официальной связки модели и harness. Промпты, схемы инструментов и пороги входят в обученную конфигурацию. Их замена влияет на результаты.
Ограничения и подходящие сценарии
Агент полезен там, где вопрос нельзя закрыть одним документом: во внутреннем поиске по регламентам, сборе доказательств для аналитика, исследовании связей между сущностями или подготовке контекста для отчёта. Он особенно интересен командам, у которых обычный RAG уже работает, но теряет факты на многошаговых запросах.
Для короткого FAQ или поиска по небольшому справочнику такая схема может оказаться тяжелее задачи. Пять раундов, отдельная модель и несколько обращений к индексу добавляют задержку и вычислительную стоимость. Готового веб-поиска, пользовательского интерфейса и механизма цитирования в поставке тоже нет.
Отдельно нужно измерять ошибки траектории. В материале про агентный поиск и галлюцинации LLM мы разбирали, как длинная цепочка ссылок создаёт убедительный, но неверный ответ. Новый ретривер снижает часть риска за счёт ранжирования доказательств и явного состояния покрытия, однако не проверяет истинность финального текста.
Главный критерий пилота прост: система должна находить больше нужных доказательств на вашем корпусе, а рост задержки должен укладываться в продуктовый сценарий. Если этот обмен не измерен, красивый многораундовый график мало что говорит о рабочем RAG.
Источники и дата проверки
Факты и изображения проверены 17 июля 2026 года. Бенчмарки приведены как результаты авторов модели; Toolarium не проводил независимый прогон.
- Т-Банк: T-Search — как мы обучали агента многошаговому поиску, 17 июля 2026 года.
- Официальная карточка модели t-tech/T-Search.
- Официальный T-Search harness.
