用 LLM + 语义聚类，把海量用户评论提炼成四级 VOC 标签体系

摘要：本文讲清楚一套把非结构化用户评论提炼成层级标签体系的 pipeline 是怎么设计的， 并在每个设计点交代对应的可调参数：它控制什么、往哪个方向调、对输出有何影响。 示例数据用公开的中文电商评论数据集（online_shopping_10_cats 手机类，2323 条），不涉及任何客户的私有数据。

1. 背景：为什么需要 VOC 标签树

任何一个有规模的产品，都会积累海量的用户声音——电商评论、应用商店评价、客服会话、问卷反馈。这些文本有两个共同特点：量大，非结构化。想从里面回答”用户到底在抱怨什么、夸什么、哪个维度问题最集中”，传统做法要么靠人工逐条打标（不可行），要么把评论直接丢给 LLM 让它”总结一下”（结果很快失控）。

直接让 LLM 自由生成标签，会遇到三个绕不开的问题：

1. 标签乱——同一个意思，模型这次叫”续航差”、下次叫”电池不耐用”、再下次叫”待机时间短”；
2. 标签重——几千条评论会生出几千个近义标签，没有收敛；
3. 跨批次不可比——今天这批数据的标签体系，和下周那批对不上，无法做趋势分析。

我们想要的，是一套满足以下性质的标签体系（VOC = Voice of Customer，客户之声）：

• 层级清晰：从”用户旅程阶段”到”具体评价指标”逐层细化；
• 同层互斥：同一层的标签之间不重叠，不会一条评论既能挂 A 又能挂 B；
• 可复用：顶层框架固定，不同批次数据打出来的标签能对齐比较；
• 可量化：每个标签带频次，能直接出”哪个维度被提及最多”的报表。

本文用一套四级标签体系（L1-L4）来实现这个目标，并把整条生成 pipeline 拆开讲清楚。

数据说明：全文示例均取自公开数据集，不涉及任何客户的私有数据。公开数据集的评论原文中会自然出现一些消费电子品牌名，那是数据集自带的公开内容，与本文所服务的客户无关。

2. 整体方法：三阶段 Pipeline

整套流程分三个阶段，从”搭骨架”到”逐条填充”再到”精炼收敛”：

• Stage1 — 建 L1-L2 标签体系：先从数据里提炼出一套稳定的两级标签框架（用户旅程 → 任务维度）。
• Stage2 — 逐条打标 + 生成 L3-L4：拿这套框架给每条评论打上 L1-L2，再为每条评论生成更细的 L3-L4。
• Stage3 — 精炼收敛：把 Stage2 产出的成千上万个细标签归并、去重、过滤、对齐，收敛成一棵干净的标签树。

展开成具体步骤，一共 11 步（括号内是实现手段）：

这里有个贯穿全文的视角：每一步背后都有若干可调参数，它们共同决定了最终标签树”长什么样”——有多宽、有多深、多干净。文章后面每讲到一个设计点，就会把对应的旋钮拎出来单独说明。文末附一张参数速查表，可以随时回查。

3. 关键设计一：四级结构 + L1 固定框架

3.1 四级的语义分工

四个层级不是随意分的，而是对应”用户旅程 → 越来越具体”的递进：

• L1 用户旅程阶段：用户与产品互动的大环节。本文固定为 购买 / 物流 / 产品 / 使用 / 售后。
• L2 任务维度：某个旅程阶段下的属性类别。如”使用”下的”屏幕显示””通话质量”。
• L3 评估维度：L2 下更细的子维度。如”屏幕显示”下的”显示清晰度””色彩表现”。
• L4 具体指标：最细粒度，格式为”标签名: 一句话解释”，可带情感。如”屏幕画面清晰度: 文字与画面显示是否清晰细腻”。

一层比一层具体，同层之间互斥。这个结构让最终报表既能看宏观（L1 各阶段占比），也能钻取到具体指标（某个 L4 被提及多少次）。

3.2 为什么 L1 要固定、且禁止 LLM 创新

L1 是整棵树的锚。如果让模型每批数据都自由生成顶层类别，就会出现”这批叫’使用体验’、那批叫’日常使用'”的漂移，跨批次彻底没法比。所以我们把 L1 定成一个预定义的固定列表，并在代码层面用 JSON Schema 的 enum 把它锁死——模型只能从这个列表里选，选不出列表外的值：

"Level_1": {
    "type": "string",
    "description": "一级标签",
    "enum": LEVEL1_TAGS   # 模型只能从固定的一级标签列表中选
}

这样从生成源头就杜绝了模型发明非法一级标签（这一点在 §6 讲 Structured Output 时还会再提）。

3.3 【参数】L1 框架的粒度

参数：LEVEL1_TAGS（固定标签列表，本文 12 类）

• 控制什么：顶层分成多少类，以及每一类下面还能细分多少层。
• 影响方向：L1 拆得越细，顶层类别越多，每一类天然覆盖的语义范围越窄，容易产生大量粒度接近、彼此重叠的顶层分支；反过来，L1 拆得越粗，同类内容归拢在一起，顶层更精简、冗余更少。
• 举例：同样是”使用”，可以拆成”屏幕/通话/续航/性能/拍照/功能”6 个细类，也可以收敛成”硬件体验/影像体验/软件体验”3 个大类。前者把使用相关的评价摊在 6 个顶层分支上，后者归拢到 3 个。

下面是同一批数据在两种 L1 框架下、Stage1 产出的 L2 分布对比：

框架 A：使用拆成 6 个细类（L1 共 15 类，L2 共 76 个）

框架 B：使用收敛成 3 个大类（L1 共 12 类，L2 共 53 个）

对比看点：每个 L1 下的 L2 数量基本不变（都在 3-5 区间，见 §4 的配额约束），真正变化的是”使用”相关的顶层分支从 6 个降到 3 个，使用类 L2 总数从 30 收敛到 14，整体 L2 从 76 精简到 53。也就是说，粗化 L1 的直接收益是削减顶层冗余、让结构更精简，而不是让单个类容纳更多维度（单类容量由 L2 配额锁定，见 §4）。

• 诚实边界：L1 粒度主要影响的是标签体系的顶层精简度与结构均衡度，但它不是决定标签树最终能有多深的唯一因素。一棵树的 L3/L4 能不能充分展开，更多取决于后面 §5 的聚合阈值和 §8 的数据丰富度。不要把 L1 粒度当成万能开关。

4. 关键设计二：Map-Reduce 式标签生成与归并

Stage1 要从几千条评论里提炼出一套稳定的 L2 体系。评论太多，没法一次性喂给模型，于是采用经典的 Map-Reduce 思路。

4.1 Map：分片并行提取

把评论切成若干片，每片独立送给 LLM，让它在固定的 L1 框架下提取候选 L2。因为每片只看到局部数据，产出的 L2 会有大量重复和近义——这是预期内的，交给 Reduce 收拾。

4.2 Reduce：多轮归并去重

把所有分片的候选 L2 汇总，多轮送回 LLM 做归并：合并语义重复的、统一命名、频次相加。多轮是为了让归并充分收敛，避免”一轮没并干净”。这一步之后，L2 从”几百个杂乱候选”收敛成”几十个规整维度”。

4.3 few-shot 示例只做”格式样板”

Map 阶段会给模型几个 few-shot 示例。这里有个容易踩的设计选择：示例应该极简，只示范”格式和粒度长什么样”，而不是喂具体的标签内容。如果示例里塞满了具体标签，模型会倾向于照抄示例、而不是从真实数据里发现维度。把生成空间交还给数据，示例只当”格式模板”。

4.4 【参数】每个 L1 下的 L2 配额

参数：S1_MAP_TAGS_PER_LEVEL1_MIN / S1_MAP_TAGS_PER_LEVEL1_MAX（本文 3-5）

• 控制什么：引导模型在每个 L1 下大约生成多少个 L2。
• 影响方向：这是写进 prompt 的软约束——不是硬性截断，模型大体遵守，但会因为后续的拆分/合并而上下浮动。调高上限，给下层更多细分空间；调低，标签更聚拢。
• 注意：因为是软约束，实际产出的每类 L2 数量会在设定区间附近浮动，个别类会略微超出，这是正常现象。要严格控制数量需要在代码层再加后处理裁剪。

下面是一次实际运行中，各 L1 下的 L2 数量分布（配额设为 3-5）：

可以看到：绝大多数 L1 落在 3-5 区间内，模型基本遵守了软约束；有 1 类顶到 6 个（略超），也有 1 类收到下限 3 个。这印证了”软约束”的性质——它是有效的引导，但不是硬性截断。

4.5 【参数】生成温度

参数：*_TEMPERATURE（生成类阶段 0.5，去重/归并/打标类阶段 0.2）

• 控制什么：某个阶段的 LLM 是偏”发散探索”还是偏”确定一致”。
• 影响方向：
  • 生成类（map、generate_l3l4）用较高温度 0.5——希望模型多发现一些维度，宁可发散一点；
  • 确定类（reduce、merge、assign、evaluate）用较低温度 0.2——去重、打标、归并是确定性任务，低温保证结果稳定、可复现，同一条输入多次跑结果一致。
• 权衡：温度高产出更丰富，但也更容易冒出噪声标签；温度低产出稳定，但可能错过一些边缘维度。按”这一步是要发散还是要收敛”来定。

5. 关键设计三：语义聚合（技术核心）

Stage2 是逐条评论生成 L3-L4 的——每条评论独立走一遍 LLM，产出自己的细标签。这意味着 2000 多条评论会生出上万个 L3-L4 标签，其中绝大多数是高度重复的近义表达：”系统流畅””运行顺滑””操作不卡顿”其实是一回事。不收敛，标签树就没法看。

收敛这一步不用 LLM，而是用向量 + 聚类：

1. 用中文 Embedding 模型（BAAI/bge-large-zh-v1.5）把标签编码成向量；
2. 计算余弦相似度，转成距离矩阵；
3. 用 DBSCAN 聚类，每个簇选最高频成员作代表，其余归并进来、频次相加。

为什么用向量而不是继续用 LLM？因为”判断几千个标签里哪些语义重复”是个两两相似度问题，向量算一次矩阵就解决，又快又稳；让 LLM 去读几千个标签互相比对，既慢又不可靠。LLM 管生成和判断，向量管去重和聚类——各干各擅长的（这个分工 §6 再展开）。

5.1 分层聚合：先归一化 L3，再聚合 L4

聚合不是一把梭，而是按 (L1,L2) 分组、分两层做

• 先 L3 归一化：在每个 (L1,L2) 组内，对 L3 名称聚类，把”核心功能完整性 / 核心功能满足度”这类变体归并到一个代表名。这一步先把 L3 这层的碎片理干净。
• 再 L4 聚合：在归一化后的 L3 路径下，对 L4 聚类去重。

分层的意义在于：L3 和 L4 是两个不同粒度的层，各自需要不同的合并力度，分开处理才能分别调优（下面两个阈值就是干这个的）。

聚类实现（L3 归一化这一层，L4 同理）：

sim_matrix = cosine_similarity(l3_embeddings)
dist_matrix = np.maximum(1 - sim_matrix, 0)

clustering = DBSCAN(
    eps=1 - AGGREGATE_L3_SIMILARITY_THRESHOLD,  # 距离阈值 = 1 - 相似度阈值
    min_samples=1,                               # 每个点都自成或加入一个簇，不丢弃孤立标签
    metric='precomputed',                        # 直接喂距离矩阵
    n_jobs=-1
)
labels = clustering.fit_predict(dist_matrix)

注意 eps = 1 – 相似度阈值 这个换算：相似度阈值越高，eps 越小，聚类越严格（只有几乎相同的才并到一起）。这就引出了两个最关键的旋钮。

5.2 【参数】L3 归一化阈值

参数：AGGREGATE_L3_SIMILARITY_THRESHOLD（本文 0.80）

• 控制什么：两个 L3 名称相似到什么程度会被合并成一个。
• 影响方向：阈值越低 → 合并越激进 → L3 越少、越粗；阈值越高 → 只并几乎相同的 → 保留越多细碎 L3。
• 作用：这一步专门治”L3 层碎片化”——同一个子维度被模型用好几种说法表达，靠它归一。

5.3 【参数】L4 聚合阈值

参数：AGGREGATE_L4_SIMILARITY_THRESHOLD（本文 0.80）

• 控制什么：两个 L4 相似到什么程度会被聚成一个。
• 影响方向：阈值越高 → 只合并几乎相同的 → 保留更多 L4 → 每个 L3 下能挂更多 L4；阈值越低 → 聚得越狠 → L4 数量塌缩，逼近”一个 L3 只对应一个 L4″。
• 为什么它最关键：它直接决定标签树的宽度——也就是 L3:L4 比例。如果 L4 被聚合得太狠，每个 L3 下只剩一个 L4，那 L3 和 L4 就退化成一对一，L3 这一层失去了”归类多个具体指标”的意义。

5.4 设计要点：两个阈值方向相反地配合

L3 阈值和 L4 阈值不是同向调的，而是相反配合：

• L3 要合得相对狠（阈值偏低）——减少同层碎片，让 L3 数量收敛；
• L4 要留得相对松（阈值偏高）——保住细分，让每个 L3 下能挂住多个不同的 L4。

二者共同决定了标签树是”层次分明”（少而精的 L3，每个下面挂若干 L4）还是”L3≈L4 退化”（L3 和 L4 一样多，一一对应）。调这套阈值，本质是在调标签树的形状。

6. 关键设计四：LLM 与向量模型的分工 ⭐ Structured Output

整条 pipeline 里，两种模型各司其职、不可互相替代：

前面反复出现的一个模式是：让 LLM 干”读懂语义并产出结构”的活，让向量干”批量比对相似度”的活。硬让 LLM 去做几千个标签的两两去重，既慢又不稳；硬让向量去理解一条评论该打什么标签，它又没有生成能力。分工是刻意的。

6.1 Structured Output：让 LLM 直接吐合法 JSON

LLM 生成结构化数据最头疼的是”输出格式不稳”——多一句解释、少一个引号、JSON 截断，后处理正则写到崩溃。这套 pipeline 用 Bedrock Converse 的 Structured Output（outputConfig）从根上解决：给定一个 JSON Schema，模型被约束只能产出符合 schema 的 JSON，拿到手直接 json.loads，不需要任何正则清洗。

if output_schema:
    kwargs["outputConfig"] = {
        "textFormat": {
            "type": "json_schema",
            "structure": {
                "jsonSchema": {
                    "schema": json.dumps(output_schema),
                    "name": "tag_output",
                    "description": "标签输出结构"
                }
            }
        }
}
# 拿到响应后直接解析，无需正则后处理
return json.loads(text)

这带来三个实打实的好处：

1. 免后处理——不用写”提取第一个 [ 到最后一个 ]”这类脆弱的正则；
2. retry 友好——万一还是解析失败，可以带着 schema 直接重试，而不是猜模型这次又哪里跑偏了；
3. 可靠性高——输出结构由 schema 保证，跨批次稳定一致。

6.2 schema 顺手锁死 L1

Structured Output 还有个衍生好处，正好呼应 §3：把 L1 的取值用 schema 的 enum 限死，模型连”发明一个新一级标签”的可能性都没有了——不是靠 prompt 求它别乱来，而是从输出协议层堵死：

"Level_1": {
    "type": "string",
    "enum": LEVEL1_TAGS   # 只能从固定列表里选
}

prompt 约束是”软”的（模型可能不听），schema enum 是”硬”的（输出协议不允许）。能用 schema 约束的，就不要只靠 prompt。

7. 关键设计五：精炼与收敛

聚合之后，标签树已经初具形状，但还要再过 Stage3 的几道精炼，才能交付：

• reduce_l4：多轮 LLM 归并残余的重复 L3-L4；
• filter_freq：按频次过滤低频标签；
• evaluate_l4：LLM 评估优化三四级标签（允许拆分/重命名/调整层级），但一、二级标签固定不可改——用代码层的 L1-L2 白名单兜底过滤，防止模型串改上层标签；
• merge_l4：向量去重，把结果对齐到人工维护的标签上。

整体效果是”从上万个散乱细标签，收敛到一棵几十到上百节点的干净树”（脱敏起见只讲数量级）。这里重点讲两个旋钮。

7.1 【参数】低频过滤门槛

参数：filter_freq（本文保留 frequency > 1）

• 控制什么：出现次数低于门槛的标签被直接丢弃。
• 影响方向：门槛越高 → 砍掉越多长尾 → 标签树越干净，但会连带删掉那些”低频但语义独特”的细分 L4；门槛越低（或关闭）→ 保留长尾 → 标签更全，但混入只出现一两次的一次性噪声。
• 本质：这是一个典型的按用途取舍的旋钮——要一份干净的高层视图，就过滤；要尽可能全的细分明细，就放宽。

下面是保留 vs 跳过低频过滤的实测对比（同一批数据）：

对比看点：跳过过滤后 L4 总数从 80 涨到 185，L3:L4 比从 1.07 升到 1.28，含多个 L4 的 L3 桶占比翻倍（6% → 15%）——标签树更”宽”、细分更丰富了。代价是多出来的标签里含大量只出现一次的长尾（”某型号独有的装饰灯设计”这类），干净度下降。要宽还是要干净，取决于这份标签树给谁用、用来干嘛。

7.2 【参数】分块大小

参数：*_MAX_CHUNK_TOKENS（本文 32000）

• 控制什么：当待处理的标签量超过单次上下文预算时，切成多大的块分批送 LLM。
• 影响方向：块越大 → 单次能看到的上下文越全、跨标签归并越充分，但越接近输出上限、越容易触发超长输出或重复退化（模型开始复读）；块越小 → 每次更稳，但跨块的标签就没机会互相归并了。
• 实践：本文取 32000，是在”归并充分”和”输出稳定”之间的折中。数据量大时，与其冒险调大分块，不如靠多轮归并来弥补跨块合并的不足。

8. 成果、适用边界与优化方向 ⭐ Prompt Cache

8.1 成果

跑完整条 pipeline，得到的是一棵 L1-L4 四级标签树：顶层是固定的用户旅程阶段，逐层细化到带解释的具体评价指标，每个节点带频次，可以直接出”哪个维度被提及最多”的量化报表。

下面是一段标签树片段（选取几个通用评测维度，展示 L1→L4 的层级结构与频次）：

每个叶子节点都是”标签名: 一句话解释 (频次)”的形式——既能看层级归属，也能直接按频次排出”哪个维度被提及最多”。

8.2 适用边界

方法通用，但效果依赖数据。两条边界要讲清楚：

1. 短文本效果好，其他数据类型需调整。 电商评论这类”短、直接、观点密集”的文本最适合这套流程。换成客服会话（长、多轮、噪声多）等数据类型，Stage1 的分片方式、prompt、few-shot 都要相应调整。

2. 数据丰富度决定标签树的深度上限——这是调参突破不了的天花板。 这一点最容易被误解，要讲透

• 某个评估维度下能不能聚出多个 L4，取决于用户是否从多个角度反复评价这个维度。比如”低光拍摄”，如果用户分别谈到了”夜景””弱光对焦””全彩夜视”，那 L3″低光表现”下面自然能挂住多个 L4；
• 反过来，如果这个维度用户只是零星、单一地提一句，那无论 L4 阈值调多松、低频过滤怎么放宽，L3 底下也就一个 L4——巧妇难为无米之炊；
• 所以当你发现某棵标签树 L3 普遍无法展开、L3≈L4，先别急着调参，要先判断：是参数把它压塌了，还是数据本身就没那么多话可说。前者调阈值能救，后者调什么都没用。

一句话：参数决定你能不能把数据里的结构充分提取出来，但数据里有多少结构，是数据本身决定的。

8.3 优化方向

• Prompt Cache（重点）：generate_l3l4 是逐条评论调用的，而每次调用都重发了一段完全相同的长 system prompt（包含 L1-L4 层级定义、few-shot 示例、生成规则）。这部分固定内容对 2000 多条评论重复了 2000 多遍。给 system 部分加 cachePoint，让这段固定前缀命中缓存，可以显著降低 input token 消耗和延迟——这也正好缓解”逐条串行、跑得慢”的体感。
• 并发加速：generate_l3l4 和 assign_l1l2 都是逐条串行的，天然可以用线程池并发。注意配合 Bedrock 的限流，加退避重试。

9. 附一：示例数据、配置与完整代码

完整代码、配置与示例数据已开源，可直接运行复现：

GitHub：https://github.com/successzy/voc-tag-tree-pipeline

仓库结构：

数据来源：公开数据集 online_shopping_10_cats（手机类，2323 条），不涉及任何客户私有数据。

环境依赖

• Python 3.12
• boto3（Amazon Bedrock，默认 region us-west-2；LLM 用 Qwen3-235B）
• sentence-transformers / scikit-learn（语义聚合，中文向量模型 BAAI/bge-large-zh-v1.5）

运行

bash run_phone_coarse_l1.sh          # 端到端跑完 Stage1-3
# 或按 --stage 单独调用某一步，见脚本内各阶段命令

10. 附二：参数速查表

相关链接

➡️ 下一步行动：

相关产品：

• Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台

相关文章：

• Amazon Bedrock模型推理的Serverless 异步架构 – 处理在线多模态高负载案例
• 基于 Prowler 与 GenAI 构建金融行业智能合规中枢
• 用 Strands Agents SDK 构建确定性数据分析：语义层 + VQR 在 Amazon Bedrock 上的实践
• 在 Amazon Bedrock 上为 Claude 应用设计稳健的 Prompt Cache 策略
• 利用AWS Firewall Manager统一部署Network Firewall (二) 集中式架构

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用