Amazon SageMaker AI донавчила Qwen3.6-27B працювати пошуковим агентом методом multi-turn RL з двома інструментами: лексичним BM25 і векторним пошуком.
Пошуковий агент сам вирішує, що шукати, який інструмент викликати і коли зупинитися, уточнюючи запит за вже отриманими результатами. Промпт маленької моделі рідко дає стабільну багатоходову поведінку, а промпт frontier-моделі зазвичай працює — і тоді платимо за кожен запит у затримці та ціні. За даними блогу AWS Machine Learning, донавчання малої моделі дає швидкість і вартість малого агента з надійністю, яка інакше вимагала б frontier-моделі.
Чому SFT і одноходовий RL не дають потрібної поведінки?
Донавчання з учителем (SFT) спирається на експертні демонстрації ідеальних багатоходових траєкторій. Для конкретного пошукового середовища таких прикладів зазвичай немає, а зібрати їх дорого.
Одноходове RL із верифікованими винагородами (RLVR) оцінює одну відповідь за раз. Пошуковий агент ухвалює взаємозалежні рішення протягом кількох ходів, тож оптимізація одного кроку ігнорує залежності між ними.
Як влаштовано багатоходове RL у SageMaker AI?
Amazon SageMaker AI MTRL подає завдання агента як послідовність рішень, збирає багатоходові прогони (rollouts) для навчання й оптимізує політику градієнтними алгоритмами. Винагорода має відображати лише якість фінального результату — цього достатньо, щоб навчити агента приймати рішення послідовно.
Сервіс пропонує модульний інтерфейс між агентом і середовищем: власні винагороди, власні цикли інструментів і власні форми багатоходових розмов. Набір алгоритмів включає функції втрат PPO, CISPO та importance sampling (IS), а також групові оцінки переваги GRPO, GRPO pass@k і RLOO.
Навчання виконується в serverless-режимі з оплатою за токени, без розгортання й супроводу власних GPU-кластерів. Генерація й оновлення градієнтів ідуть паралельно, довгі запуски можна розбити на кілька робіт, а кроки агента та винагороди видно в MLflow, керованому через Amazon SageMaker AI. Окремі оцінювальні роботи показують винагороду, pass@k і метрики траєкторій перед деплоєм на endpoint Amazon SageMaker AI або в Amazon Bedrock.
Що змінюється для пошуку з BM25 і векторним пошуком?
У цьому експерименті Amazon донавчив Qwen3.6-27B у регіоні us-west-2 (US West, Oregon) і дав агенту два інструменти. Лексичний пошук BM25 знаходить точні збіги за ключовими словами через підрахунок частоти слів і краще працює на запитах із конкретними термінами чи ідентифікаторами.
Векторний пошук перетворює запити й документи на ембедінг-вектори та рахує схожість. Його рекомендують для семантичних запитів, де точних ключових слів немає.
Кількість ходів обмежено, щоб агент не розтягував відповідь і поводився ефективніше. Середовище для прогонів живиться з розгорнутого агентного endpoint, який відкриває BM25 і векторний пошук. Навчальні та валідаційні набори завантажено в Amazon Simple Storage Service (Amazon S3) у форматі, який очікує MTRL, причому 5% тренувальних прикладів усередині кожного набору відкладено на валідацію. Головна метрика винагороди — nDCG@10 (Normalized Discounted Cumulative Gain на позиції 10).
Що зробити на своєму пошуковому агенті
- Опишіть пошук як середовище: список інструментів, формат виклику, ліміт ходів і правило зупинки.
- Оберіть одну підсумкову метрику якості видачі — наприклад nDCG@10 — і заміряйте базового агента на ній до навчання, щоб мати точку для порівняння.
- Зберіть датасет у форматі MTRL, завантажте його в Amazon S3 і закрийте середовище endpoint-ом, який відкриває потрібні пошукові інструменти.
- Перед деплоєм на endpoint Amazon SageMaker AI або в Amazon Bedrock запустіть оцінювальну роботу і перегляньте траєкторії ходів у MLflow.
- Паралельно перевірте, чи вистачає вам обох пошукових стратегій: у тестовому наборі мають бути і запити з точними термінами, і семантичні запити без ключових слів.
