搜索智能体的难点通常不在“会不会调用搜索工具”，而在于它能否连续做对几件事：理解问题、构造查询、判断结果是否充分、必要时改写查询，并基于证据给出答案。通过在 Amazon SageMaker AI 上进行多轮强化学习（Multi-Turn Reinforcement Learning，MTRL）微调，可以让较小的模型熟悉特定工具和运行环境，以更低的延迟与成本获得更稳定的领域表现。
需要注意的是，这里的目标并不是让小模型在所有任务上取代前沿模型，而是把它训练成一个边界清晰、工具固定、评价标准明确的专用搜索智能体。
为什么单轮微调不够
传统监督微调往往把一个样本表示为“输入问题—目标答案”。但搜索智能体面对的是一条轨迹：
- 用户提出问题；
- 模型选择搜索工具并生成参数；
- 环境返回搜索结果；
- 模型判断证据是否充分；
- 模型继续搜索，或者生成最终答案。
如果只监督最终答案，模型可能碰巧答对，却使用了错误查询或引用了不相关文档。相反，一个搜索过程也可能在前几步失败，经过查询改写后成功找回正确内容。多轮强化学习关注整条轨迹，让最终任务结果、检索质量、工具调用合法性和执行成本共同影响训练信号。
可以把一条训练轨迹抽象为：
用户问题
-> search(query="...")
<- 文档列表
-> search(query="改写后的查询")
<- 更相关的文档
-> 带证据的最终答案
这种表示方式尤其适合企业内部搜索，因为模型需要学习的不只是自然语言，还包括索引字段、过滤条件、工具参数以及“什么时候应该停止搜索”。
奖励函数决定智能体真正学到什么
MTRL 的关键并不是简单地给正确答案打 1 分，而是设计一组能反映业务目标的奖励。一个实用的奖励函数通常包含以下部分：
- 任务成功率：最终答案是否解决了用户问题；
- 检索相关性：返回结果是否包含支持答案的文档；
- 证据一致性：答案中的结论能否由检索内容支撑；
- 工具合法性：工具名称、参数结构和过滤条件是否有效；
- 交互效率：是否存在重复搜索、无意义改写或过多轮次；
- 安全约束：是否访问了不允许的数据域，或暴露了敏感信息。
下面是一个可直接运行的本地奖励计算示例。它不是特定 MTRL 框架的完整训练器，而是一个可用于数据检查、离线评估或奖励服务原型的最小实现。
将其保存为 reward_demo.py，然后运行 python reward_demo.py：
from dataclasses import dataclass
from typing import List
@dataclass
class RetrievedDocument:
document_id: str
relevance: float # 约定为 0.0 到 1.0
@dataclass
class SearchTrajectory:
tool_calls: int
invalid_tool_calls: int
answer_supported: bool
documents: List[RetrievedDocument]
def calculate_reward(trajectory: SearchTrajectory) -> dict:
best_relevance = max(
(doc.relevance for doc in trajectory.documents),
default=0.0,
)
task_reward = 1.0 if trajectory.answer_supported else 0.0
tool_reward = 1.0 if trajectory.invalid_tool_calls == 0 else 0.0
extra_call_penalty = 0.05 * max(0, trajectory.tool_calls - 3)
total = (
0.45 * task_reward
+ 0.35 * best_relevance
+ 0.20 * tool_reward
- extra_call_penalty
)
return {
"total": round(total, 4),
"task_reward": task_reward,
"retrieval_reward": best_relevance,
"tool_reward": tool_reward,
"extra_call_penalty": extra_call_penalty,
}
if __name__ == "__main__":
sample = SearchTrajectory(
tool_calls=2,
invalid_tool_calls=0,
answer_supported=True,
documents=[
RetrievedDocument("doc-17", 0.42),
RetrievedDocument("doc-23", 0.91),
],
)
print(calculate_reward(sample))
生产环境中不应直接把人工标注分数当作唯一事实。可以组合搜索相关性标注、确定性规则、答案验证器和人工抽检，并分别记录每个奖励分量。否则，一旦只优化总分，就很难发现模型是在提升真实质量，还是学会了利用奖励函数的漏洞。
在 SageMaker AI 中组织训练任务
一种可行的工程结构是把轨迹生成、奖励计算、策略训练和离线评估拆开：
search-agent-mtrl/
├── src/
│ ├── train.py
│ ├── reward.py
│ └── tools.py
├── data/
│ ├── train.jsonl
│ └── validation.jsonl
├── launch_training.py
└── requirements.txt
每条 JSONL 数据可以保存问题、每轮动作、工具观察结果和最终评价。例如：
{"episode_id":"ep-001","question":"如何重置某服务的访问令牌？","turns":[{"action":"search","arguments":{"query":"服务 访问令牌 重置"},"observation":["doc-23","doc-42"]},{"action":"answer","text":"根据 doc-23，需要先撤销旧令牌，再创建新令牌。"}],"labels":{"supported":true,"relevant_document_ids":["doc-23"]}}
当自定义训练镜像和 train.py 已经准备好后，可以通过 SageMaker Python SDK 提交训练任务。下面的启动脚本是可改造的通用骨架，并不假设某个特定的强化学习库：
# launch_training.py
import os
from sagemaker.estimator import Estimator
role = os.environ["SAGEMAKER_ROLE_ARN"]
image_uri = os.environ["TRAINING_IMAGE_URI"]
training_data = os.environ["TRAINING_DATA_S3_URI"]
output_path = os.environ["MODEL_OUTPUT_S3_URI"]
estimator = Estimator(
image_uri=image_uri,
role=role,
instance_count=1,
instance_type=os.getenv("INSTANCE_TYPE", "ml.g5.2xlarge"),
entry_point="train.py",
source_dir="src",
output_path=output_path,
hyperparameters={
"learning-rate": 1e-6,
"episodes-per-batch": 32,
"max-turns": 6,
"kl-coefficient": 0.02,
},
environment={
"TOKENIZERS_PARALLELISM": "false",
},
)
estimator.fit({"train": training_data})
运行前需要安装并配置 AWS 与 SageMaker SDK，再替换以下环境变量：
python -m pip install sagemaker boto3
export AWS_DEFAULT_REGION=us-east-1
export SAGEMAKER_ROLE_ARN='arn:aws:iam::123456789012:role/SageMakerExecutionRole'
export TRAINING_IMAGE_URI='123456789012.dkr.ecr.us-east-1.amazonaws.com/search-agent-mtrl:latest'
export TRAINING_DATA_S3_URI='s3://my-bucket/search-agent/train/'
export MODEL_OUTPUT_S3_URI='s3://my-bucket/search-agent/models/'
python launch_training.py
train.py 应从 SageMaker 提供的训练通道读取数据，并将最终模型写入模型目录。具体策略优化算法、分布式配置和模型加载方式取决于所选基础模型及 RL 框架，因此不宜把它们硬编码进通用示例。
评估时不要只看最终答案
来源摘要提到，微调后在检索质量和可靠性方面获得了提升，但没有提供可复述的具体数值。实际复现时，应该同时建立基线模型、固定评测集和分层指标，而不是只比较几个演示问题。
建议至少记录：
| 维度 | 指标示例 |
|---|---|
| 检索质量 | Recall@K、MRR、nDCG、关键文档命中率 |
| 答案质量 | 正确率、证据支持率、拒答准确率 |
| 工具可靠性 | 合法调用率、参数错误率、超时率 |
| 交互效率 | 平均搜索轮数、重复查询率、每任务 token 数 |
| 系统成本 | 单任务推理成本、P50/P95 延迟 |
评测集还应该覆盖无答案问题、工具超时、空搜索结果、权限不足、互相矛盾的文档和恶意提示。一个只在“搜索一定成功”的环境中训练出来的智能体，进入生产环境后往往会过度自信。
上线前的取舍与检查清单
多轮强化学习适合工具固定、任务重复、反馈可衡量的搜索场景。若工具接口经常变化、奖励难以验证，或者任务本身高度开放，先改善检索索引、提示词和监督数据，通常比直接引入 RL 更稳妥。
上线前可以逐项确认：
- 训练集、验证集与测试集是否按问题或文档来源隔离，避免泄漏；
- 奖励函数是否同时约束答案正确性、证据质量和调用成本；
- 是否保留每轮动作、观察结果和奖励分量，便于回放故障；
- 是否限制最大轮数、工具权限和可访问的数据范围；
- 是否与基础模型、监督微调模型和更大模型基线进行同集比较；
- 是否设置质量下降时的回滚机制，以及复杂问题转交更强模型的路由策略。
较小搜索智能体的价值来自“专用”和“可控”。SageMaker AI 提供训练任务所需的计算、数据通道和模型产物管理基础，而 MTRL 则把多轮工具交互纳入优化目标。两者结合的重点不是追求更长的推理轨迹，而是让每一次搜索、改写和停止决策都更可靠、更便宜，也更容易评估。