意图识别置信度和检索重排的分数

意图识别的置信度：LLM 在"思考"

它需要阅读用户的自然语言问题，理解其背后的真实意图。例如，用户问"我的订单到哪了？"，LLM 需要判断出这属于"查询物流"这个意图。

置信度来源：这个分数是 LLM 在内部进行多轮计算后，对自己判断的"自信程度"的量化。它回答的是："我有多大把握认为用户是这个意思？" 这个过程涉及复杂的语义理解和逻辑推理，是 LLM 的核心能力。

检索 (Retrieval) 分数：向量模型在"计算"

• 角色：负责检索的向量模型（Embedding Model）
• 过程：它不"理解"文本的含义。它的工作是把问题和知识库里的文本片段都转换成向量。然后，它通过数学公式（比如计算两个向量在多维空间中的距离或夹角）来得出一个相似度分数。
• 分数来源：这个分数纯粹是数学计算的结果，衡量的是两个向量在空间上的"远近"，而不是语义上的"对错"。整个过程非常快，但缺乏深层的理解能力。

重排 (Rerank) 分数：交叉编码器在"精算"

• 角色：负责重排的模型（通常是 Cross-Encoder）
• 过程：它比检索模型更精细。它会把"问题"和"待排序的文本片段"拼在一起，作为一个整体输入，然后进行更深度的交互计算，以判断它们的相关性。
• 分数来源：虽然它比检索模型更"聪明"，能捕捉更细微的关联，但其本质仍然是一个经过专门训练的、用于相关性打分的模型，而不是一个通用的、能进行复杂推理的 LLM。

总结：

• 意图识别 是 LLM 在**"想"**，然后告诉你它有多确定。
• 检索和重排 是专门的模型在**"算"**，然后告诉你它们有多匹配。

Retriever 与 Rerank 的职责边界

1. Retriever 只负责"找"

底层向量检索器（Vector Retriever）的职责非常纯粹，它只需要知道：

• query：用户问了什么
• collection：去哪个知识库（集合）里找
• topK：最多返回多少条候选
• vector search：执行向量相似度搜索
• vector metadata recovery：把检索到的元数据（如文档ID、分块序号等）一起带回来

它返回的最小信息集是：

• chunkId：文本块的ID
• content：文本内容
• retrievalScore：检索相似度分数
• documentId：所属文档ID
• collectionName：所属知识库名称
• chunkIndex：在文档中的位置序号

2. Retriever 不应该知道"业务逻辑"

这段话强调，Retriever 不应该知道以下信息：

• RoutingDecision / AllowedRoute / routeId：这是路由决策，属于上层业务逻辑------决定"走哪条路去检索"。
• intentId / subQuestion：这是意图识别的结果------知道"用户想干什么"。
• retrievalChannel：这是检索渠道------知道"通过什么方式检索"。

为什么？ 因为这些信息属于"业务层"的判断，而 Retriever 是一个"工具层"的组件。它只负责"给定一个 query，去指定的集合里找出最相似的 TopK 条文本"，至于这个 query 是从哪个意图来的、为什么要检索、走的是哪条路由，它完全不关心，也不应该关心。

3. "这些信息必须在更高层绑定"

意思是：intentId、routeId、retrievalChannel 这些业务信息，应该在 更上层的业务逻辑层（比如 bootstrap 层） 与 Retriever 返回的结果进行"绑定"或"关联"。