怎么让大模型同时给意图节点打分

摘要 ：在智能客服、任务型对话系统（Task-Oriented Dialogue）、智能体工作流（Agent Routing）以及复杂问答路由场景中，用户输入往往具有多意图混合、表述模糊、隐含诉求等特点。传统的单分类模型或串行单一意图匹配，不仅难以应对意图重叠，还会带来巨大的延迟与 Token 开销。

本文将系统拆解如何通过单次请求让大语言模型对候选意图节点池同时进行多维度打分。内容涵盖：为什么需要矩阵式同时打分、大模型评分通胀与注意力衰减机制、结构化标准打分尺（Scoring Rubric）设计、Pydantic 结构化输出与端到端代码实战、应对上百个意图节点的"向量粗筛 + LLM 精排打分"两阶段架构，以及生产环境中的阈值与冲突消解策略。

一、 为什么需要让大模型"同时给多个意图打分"？

1.1 传统单意图分类与串行匹配的局限

在构建智能路由或对话流转引擎时，最常见的做法有两种：

1. 单意图分类器（Single-label Classifier） ：直接让分类模型（如 BERT 或传统分类 Prompt）输出一个最可能的 Intent 标签（如 REFUND_APPLY）。

   • 缺陷 ：现实场景中用户的输入经常混合多个意图。例如用户说："你们这衣服掉色严重，我刚穿一天，赶紧给我退货，顺便把运费赔给我，另外你们客服怎么半天不理人？" 这句话同时包含了 质量投诉 (0.95)、申请退货 (0.90)、申请运费赔付 (0.85) 和 服务态度投诉 (0.70)。单分类器会强行抹杀次要意图，导致下游业务无法并行处理。

2. 串行逐个询问大模型（Sequential Prompting）：遍历 10 个意图节点，分别调用 10 次大模型询问："这条文本符合意图 A 吗？符合意图 B 吗？"

   • 缺陷：耗时呈 O(N) 线性暴增，单次用户交互需要等待数秒，且 Token 费用翻了 N 倍，不可接受。

   【低效串行架构】
   用户 Query ──┬──> [LLM 调用 1] ──> 意图 A 得分: 0.1
   ├──> [LLM 调用 2] ──> 意图 B 得分: 0.8
   └──> [LLM 调用 N] ──> 意图 N 得分: 0.3
   (网络延迟 = N × 单次延迟，Token 费用 = N × 输入)

   【高效单次矩阵打分】
   用户 Query + [候选意图列表] ──> [LLM 单次推理] ──> JSON 矩阵:
   {
   "意图A": 0.1,
   "意图B": 0.8,
   "意图N": 0.3
   }
   (网络延迟 = 1次延迟，Token 消耗压缩至 1/N 级别)

1.2 同时打分（Multi-Intent Scoring）的核心价值

让大模型在单次推理中对一组意图节点进行打分，具有以下核心优势：

• 全局注意力感知（Global Context Attention）：大模型可以在同一上下文内权衡不同意图之间的强弱对比与互斥关系。

• 支持多意图并行触发与优先级排队：根据置信度分数设定主意图、次要意图以及辅助意图，支持复合业务流。

• 平滑降级与人工转接（Fallback） ：当所有候选意图的最高得分均低于置信度阈值（如所有得分 < 0.5）时，系统可精准触发"澄清反问"或"转人工客服"。

二、 核心挑战：为什么让大模型直接打分容易"失真"？

在实际工程中，如果只是简单地告诉大模型"请给以下意图打 0 到 1 分"，你会发现模型打出的分数通常不可用，主要存在以下四大核心挑战：

2.1 评分通胀（Score Inflation）与过度自信

大模型通常具有"迎合心理"与过度自信倾向。如果不做严格约束，模型倾向于给任何稍微沾边的意图都打出 0.8 或 0.9 的高分，导致分数失去区分度。

2.2 注意力衰减与位置偏见（Position Bias）

当一次性提交 15~30 个意图节点供模型评估时，位于列表头部 和尾部的意图更容易被大模型分配更高的注意力权重，而排在中间的意图容易被忽略或草率打低分。

2.3 评分标准不一致（Lack of Grounded Rubric）

"0.7 分"代表什么？在没有明确打分标尺的情况下，模型在面对第 1 个意图时可能把 0.7 视为"稍微相关"，但在评估第 5 个意图时又把 0.7 视为"高度吻合"。

2.4 幻觉与格式漂移（Schema Drift）

模型可能会自行创造出列表中根本不存在的意图名称，或者输出包含Markdown解释性文字的非标准格式，破坏后端解析引擎。

三、 解决方案体系：构建高精度意图矩阵打分器

要实现稳定、高可用的大模型同时打分，需要建立一套包含 "打分标尺（Rubric）+ 锚点示例 + 结构化约束 + 后处理校准" 的完整方案体系。

┌─────────────────────────────────────────────────────────────┐
│                    1. 意图节点元数据准备                     │
│  - 意图唯一编码 (Intent Key)                                 │
│  - 严格正向匹配定义 (Definition)                             │
│  - 严格负向排除边界 (Negative Boundaries)                    │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                    2. 标尺量化 (Scoring Rubric)             │
│  - 0.0: 完全无关 / 无事实依据                                │
│  - 0.3: 提及弱相关词汇但无明确意图诉求                       │
│  - 0.6: 存在直接诉求但缺少必要上下文                         │
│  - 0.9+: 核心诉求明确、语义完全闭合                          │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                 3. 结构化输出与强制 JSON 约束                │
│  - 使用 Pydantic 模型限定输出 Schema                         │
│  - 强制包含 reasoning（思维链简述）提升打分准确率            │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│                 4. 后处理校准与动态决策                      │
│  - 置信度阈值过滤 (Dynamic Thresholding)                     │
│  - 互斥意图抑制 (Mutual Exclusion Suppression)               │
└─────────────────────────────────────────────────────────────┘

3.1 评分标尺（Rubric）的五级量化设计

永远不要让大模型在无规则的状态下打分。 必须在 System Prompt 中为模型提供标准化的打分标尺：

分数区间	判定标准	典型特征
0.0 ~ 0.1	完全不相关	文本中未提及与该意图相关的任何动词、名词或上下文。
0.2 ~ 0.4	弱相关 / 仅提及关键词	出现了该领域的词汇，但没有表达行动诉求（例如："你们有退货政策吗"之于"申请退货"意图）。
0.5 ~ 0.7	中度相关 / 疑似意图	用户表达了相关诉求，但信息模糊、隐含，或属于从属从句中的附带表述。
0.8 ~ 0.9	强相关 / 核心意图	意图动词明确、主谓宾完整，是用户当次对话的主要诉求之一。
1.0	绝对吻合 / 触发关键词精准闭环	措辞极度直白、毫无二义性（例如："我现在立刻要退货，订单号 12345"）。

3.2 意图节点元数据的"正负边界"定义

单纯给出一个意图名称（如 REFUND）是远远不够的。每个意图节点必须包含三个字段：

• intent_id：机器识别的唯一标识符。

• description：该意图命中的核心业务动作。

• negative_examples / exclude_rule ：排除规则（最关键），告诉模型在什么情况下绝对不能打高分。

四、 生产级 Prompt 模板工程设计

下面是一份在实际生产业务中验证过的高稳定性、抗注意力衰减的打分 Prompt 模板：

<system_instruction>
你是一个高精度的意图识别与置信度打分引擎。你的任务是根据用户的输入文本，对提供的【候选意图列表】中的每一个意图节点进行独立、客观的置信度评分（0.0 到 1.0）。

【打分标尺 (Scoring Rubric)】
- 0.0: 完全无关。文本未涉及该意图的任何语义。
- 0.3: 弱相关。用户仅提到了相关名词，但并没有发起该动作的主观意愿。
- 0.6: 中度相关。用户表达了潜在诉求，但缺乏明确指示词，或属于复合句中的次要背景。
- 0.9: 强相关。用户的核心诉求明确指向该操作，语义清晰无二义性。
- 1.0: 完全精准吻合。

【严格约束】
1. 必须对候选列表中的【每一个】意图进行评估，不得遗漏，也不得添加列表中不存在的意图。
2. 保持评分客观独立，避免随意打出 0.8 以上的高分。若无确凿语义支撑，请压低分数（0.0~0.2）。
3. 必须输出严格的 JSON 格式，不得包含任何 Markdown 代码块外的闲聊。
4. 先给出 1 句极简的打分理由（reasoning），再给出置信度数值（score），这有助于提升推理准确性。
</system_instruction>

<candidate_intents>
1. [ID: INTENT_REFUND_APPLY]
   - 名称: 申请退货退款
   - 描述: 用户希望退掉已购买的商品并拿回货款。
   - 负向排除: 若用户只是咨询退货规则或查询退款进度，严禁打分超过 0.4。

2. [ID: INTENT_LOGISTICS_URGE]
   - 名称: 物流催单
   - 描述: 用户催促进度、抱怨快递太慢、要求尽快发货或配送。
   - 负向排除: 用户单纯询问发货快递公司名称时不适用。

3. [ID: INTENT_COMPLAINT_AGENT]
   - 名称: 投诉人工客服
   - 描述: 用户对客服态度、回复速度表达强烈不满，或扬言向 12315、消协投诉。
   - 负向排除: 用户正常请求"转人工"而无抱怨情绪时打分不超过 0.3。

4. [ID: INTENT_PRODUCT_CONSULT]
   - 名称: 商品售前咨询
   - 描述: 咨询商品的尺码、颜色、参数、使用方法等。
   - 负向排除: 已经购买后的质量问题投诉不适用。
</candidate_intents>

<user_query>
{user_query}
</user_query>

五、 端到端代码实战：基于 Pydantic + 异步并发打分引擎

在 Python 生产环境中，推荐使用 Pydantic 进行结构化类型约束，并结合带有 JSON Schema 约束的模型接口（如 OpenAI / DeepSeek 的 Structured Outputs）。

5.1 环境安装

pip install openai pydantic instructor

5.2 完整工程级代码实现

import os
import json
import asyncio
from typing import List, Dict
from pydantic import BaseModel, Field
from openai import AsyncOpenAI

# ==================== 1. 数据结构定义 ====================

class IntentDefinition(BaseModel):
    intent_id: str = Field(description="意图唯一标识符")
    name: str = Field(description="意图业务名称")
    description: str = Field(description="意图触发条件描述")
    negative_rules: str = Field(description="必须排除的负向规则")

class SingleIntentScore(BaseModel):
    intent_id: str = Field(description="被评估的意图 ID")
    reasoning: str = Field(description="简短的打分事实依据（不超过 30 字）")
    score: float = Field(ge=0.0, le=1.0, description="置信度得分，范围 0.0 到 1.0")

class MultiIntentScoringResponse(BaseModel):
    scores: List[SingleIntentScore] = Field(description="所有候选意图的评分列表")

# ==================== 2. 意图打分引擎封装 ====================

class MultiIntentScorer:
    def __init__(self, api_key: str, base_url: str = "https://api.openai.com/v1", model: str = "gpt-4o-mini"):
        self.client = AsyncOpenAI(api_key=api_key, base_url=base_url)
        self.model = model

    def _build_system_prompt(self, candidate_intents: List[IntentDefinition]) -> str:
        intents_text = ""
        for idx, item in enumerate(candidate_intents, 1):
            intents_text += f"{idx}. [ID: {item.intent_id}]\n"
            intents_text += f"   - 业务名称: {item.name}\n"
            intents_text += f"   - 正向定义: {item.description}\n"
            intents_text += f"   - 负向排除: {item.negative_rules}\n\n"

        prompt = f"""你是一个工业级对话系统的意图识别与打分中枢。
请评估用户的输入文本，并针对候选意图池中的【每一个】意图给出 0.0 ~ 1.0 的置信度分数。

【评分标尺 (Rubric)】
- 0.0: 完全无关，未体现任何意图。
- 0.3: 仅包含边缘关键词，无实际诉求。
- 0.6: 存在次要诉求或表达模糊。
- 0.9: 核心意图明确，主谓宾完备。
- 1.0: 毫无二义性的极强诉求。

【候选意图清单】
{intents_text}

【严格要求】
1. 必须对清单中的每个 intent_id 输出对应项，禁止漏评。
2. 严格输出符合 JSON Schema 的对象。
3. 充分考虑负向排除规则，严禁滥发高分。"""
        return prompt

    async def score_intents(
        self, 
        user_query: str, 
        candidate_intents: List[IntentDefinition]
    ) -> List[SingleIntentScore]:
        """单次调用大模型，返回所有候选意图的得分列表"""
        system_prompt = self._build_system_prompt(candidate_intents)
        
        try:
            response = await self.client.beta.chat.completions.parse(
                model=self.model,
                messages=[
                    {"role": "system", "content": system_prompt},
                    {"role": "user", "content": f"用户输入文本: '''{user_query}'''"}
                ],
                response_format=MultiIntentScoringResponse,
                temperature=0.0  # 打分任务严格设置为 0.0 以保障确定性
            )
            
            parsed_result: MultiIntentScoringResponse = response.choices[0].message.parsed
            return parsed_result.scores
            
        except Exception as e:
            print(f"[Error] 大模型打分执行异常: {e}")
            return []

# ==================== 3. 生产级决策与后处理过滤器 ====================

class IntentDecisionEngine:
    def __init__(self, primary_threshold: float = 0.75, secondary_threshold: float = 0.50):
        self.primary_threshold = primary_threshold
        self.secondary_threshold = secondary_threshold

    def route(self, scores: List[SingleIntentScore]) -> Dict[str, any]:
        """根据评分矩阵进行路由决策"""
        if not scores:
            return {"action": "FALLBACK", "message": "打分失败，触发降级策略"}

        # 按照分数降序排列
        sorted_scores = sorted(scores, key=lambda x: x.score, reverse=True)
        top_1 = sorted_scores[0]

        # 场景 1: 最高分仍然很低 -> 触发兜底/澄清
        if top_1.score < self.secondary_threshold:
            return {
                "action": "UNCERTAIN_CLARIFY",
                "top_intent": None,
                "confidence": top_1.score,
                "reason": "未检测到明确置信的意图，需向用户发起澄清"
            }

        # 场景 2: 命中主要意图，并提取潜在的并发次要意图
        primary_intents = [s for s in sorted_scores if s.score >= self.primary_threshold]
        secondary_intents = [
            s for s in sorted_scores 
            if self.secondary_threshold <= s.score < self.primary_threshold
        ]

        return {
            "action": "EXECUTE_INTENTS",
            "primary_intents": [
                {"id": p.intent_id, "score": p.score, "reason": p.reasoning} for p in primary_intents
            ],
            "secondary_intents": [
                {"id": s.intent_id, "score": s.score, "reason": s.reasoning} for s in secondary_intents
            ],
            "raw_scores": {s.intent_id: s.score for s in sorted_scores}
        }

# ==================== 4. 运行验证 ====================

async def main():
    # 初始化候选意图池（模拟电商售后场景）
    intent_pool = [
        IntentDefinition(
            intent_id="INTENT_REFUND",
            name="申请退款",
            description="用户希望退回商品并获得退款",
            negative_rules="仅咨询退款到账时间或退货地址时不适用"
        ),
        IntentDefinition(
            intent_id="INTENT_SHIPPING_COMPLAINT",
            name="催促发货/物流抱怨",
            description="用户抱怨配送太慢，催促尽快更新物流或发货",
            negative_rules="修改收货地址不适用"
        ),
        IntentDefinition(
            intent_id="INTENT_AGENT_COMPLAINT",
            name="投诉人工态度",
            description="用户对客服人员的服务质量表达愤怒并扬言投诉",
            negative_rules="礼貌地请求转接人工客服不适用"
        ),
        IntentDefinition(
            intent_id="INTENT_INVOICE_ISSUE",
            name="开具发票",
            description="用户索要电子发票、修改发票抬头或报销凭证",
            negative_rules="询问商品价格是否含税不适用"
        )
    ]

    api_key = os.getenv("OPENAI_API_KEY", "your-api-key")
    scorer = MultiIntentScorer(api_key=api_key, model="gpt-4o-mini")
    engine = IntentDecisionEngine(primary_threshold=0.75, secondary_threshold=0.50)

    # 复杂复合意图测试 Query
    test_query = "我都等了五天了鞋子还没发货，你们客服刚才态度还极其恶劣！立刻给我退款，顺便把发票也给我开了我要去消协举报！"
    print(f"【测试用户 Query】\n{test_query}\n")

    # 执行打分
    scores = await scorer.score_intents(test_query, intent_pool)

    print("=== 大模型单次评分结果 (Raw Scores) ===")
    for item in scores:
        print(f"[{item.intent_id}] 得分: {item.score:.2f} | 理由: {item.reasoning}")

    # 执行路由决策
    decision = engine.route(scores)
    print("\n=== 路由决策引擎输出 ===")
    print(json.dumps(decision, indent=2, ensure_ascii=False))

if __name__ == "__main__":
    asyncio.run(main())

六、 应对上百个意图节点的超级扩展方案（Hierarchical Scoring）

如果你的系统里只有 5~10 个意图节点，单次全量打分效果极佳。但如果你的业务沉淀了 50~200 个细分意图节点，直接将全部节点丢进 Prompt 会面临两大障碍：

1. Prompt 超长，推理延迟大幅上升，Token 成本剧增。

2. 上下文注意力稀释，大模型极易在海量选项中迷失，导致判断精度下降。

此时必须引入 两阶段分层打分架构（Two-Stage Hierarchical Scoring）。

               ┌─────────────────────────────────────────┐
               │         用户 Query (自然语言输入)       │
               └────────────────────┬────────────────────┘
                                    │
                                    ▼
               ┌─────────────────────────────────────────┐
               │    阶段一：语义检索粗筛 (Dense Retrieval)│
               │  - 使用向量数据库 (Qdrant / Milvus)     │
               │  - 从 200+ 意图池中召回 Top-8 候选意图  │
               └────────────────────┬────────────────────┘
                                    │ Top-8 候选意图子集
                                    ▼
               ┌─────────────────────────────────────────┐
               │   阶段二：LLM 矩阵精排打分 (LLM Scoring) │
               │  - 仅针对 Top-8 候选进行单次精细化打分  │
               │  - 输出严格量化的置信度矩阵             │
               └────────────────────┬────────────────────┘
                                    │
                                    ▼
               ┌─────────────────────────────────────────┐
               │       决策路由器 (Decision Engine)      │
               │  - 主/次意图分流、互斥过滤、澄清拦截    │
               └─────────────────────────────────────────┘

6.1 阶段一：向量化语义粗筛（Top-K Intent Retrieval）

• 将系统中的 200 个意图节点的 name + description + standard_queries 预先计算并存入向量数据库。

• 用户输入 Query 后，首先通过轻量级 Embedding 模型（如 text-embedding-3-small 或 bge-m3）进行毫秒级向量近似检索（ANN），召回相关度最高的 Top-K（通常取 6~10 个） 候选意图。

6.2 阶段二：LLM 局部精排打分（In-Context Scoring）

• 将这 6~10 个最具竞争力的候选意图注入 Prompt 模板。

• LLM 在极度精简的候选集合内完成细粒度语义推导，给出最终精准的 0.0~1.0 打分。

性能收益：

• 相比直接将 200 个节点送给大模型，Token 消耗降低 85% 以上。

• 首字响应延迟（TTFT）缩短至 300ms 以内。

• 准确率比纯向量检索提升 30%~40%（因为 LLM 能够精准识别否定句、反讽与多意图复合句）。

七、 生产环境避坑指南与调优技巧

1. 为什么必须将 temperature 设为 0.0？

意图打分属于确定性分类任务 而非创意写作。任何高于 0.0 的 temperature 都会引入随机性采样，导致相同的用户输入在两次调用中出现 0.85 与 0.65 的评分波动，破坏下游路由的稳定性。

2. 强制模型"先输出理由，再输出分数"

在 Pydantic 模型设计中，务必将 reasoning（推理说明）字段放在 score 字段前面：

# 推荐写法（让模型先思考再下结论，符合 CoT 原理）
class SingleIntentScore(BaseModel):
    intent_id: str
    reasoning: str  # 模型在生成此字段时进行了自我推导
    score: float    # 随后生成的 score 质量大幅提升

# 不推荐写法（模型直接预测概率，容易拍脑门给分）
class SingleIntentScore(BaseModel):
    intent_id: str
    score: float
    reasoning: str

这一微小的字段顺序调整，能够显著降低大模型的盲目打分概率。

3. 互斥意图的消解矩阵（Conflict Resolution）

部分意图在业务逻辑上是完全互斥的（例如 人工服务_好评 与 人工服务_投诉）。

如果大模型由于用户表述矛盾同时给两者打出了 0.8 的高分，决策引擎层必须配置互斥压制规则（Suppression Rule），根据业务优先级保留最紧急的意图（如优先走投诉通道）。

八、 总结

让大模型单次对多个意图节点进行打分，是构建现代化、高并发、多意图并行智能体工作流的核心技术。

• 相比传统的单意图分类，它保留了完整的置信度分布与次要意图感知；

• 相比低效的串行遍历，它在延迟与成本上取得了数量级的优势；

• 通过引入五级量化打分标尺（Rubric） 、结构化输出约束（Pydantic） 、先思考后给分机制 ，以及在大规模场景下的两阶段分层召回架构，开发者可以彻底解决大模型评分失真与注意力衰减的难题，打造出兼具高准确率与工业级稳定性的意图决策引擎。