知识库构建时，为什么要清楚用户与场景？

🎯 一、 为什么必须先搞清楚“用户与场景”？

大模型很聪明，但向量数据库很“笨”。知识库的本质是为了抹平**“用户提问的语言”**与**“专业文档的语言”**之间的巨大鸿沟。

1、 认知错位：

你的用户可能连专业名词都叫不上来。比如，买衣服的顾客会问“这个裙子起球吗？”，而你的质检文档里写的是“抗起毛起球等级为 3 级”。如果不了解用户，直接把文档切了扔进去，顾客永远搜不到答案。

2、耐心错位：

客服人员需要 2 秒内得到答案，哪怕短一点；而法务人员愿意等 15 秒，但要求必须把前因后果和条款原文一字不落地列出来。

3、权限错位：

老板、主管、一线业务员能看的数据级别是完全不一样的。

⚖️ 二、 知道用户后，知识库构建会有哪些“决定性差异”？

明确了用户群体后，你在构建知识库的每一步（数据处理、分块、检索、生成）都会发生剧变。我们通过一个横向对比来看看差距有多大：

💡 三、 真实案例：同一份《产品说明书》的两种命运

假设你们公司有一份关于亚马逊运营的《账户防封号指南》，如果交给两个不同的团队去用，你的系统建设将完全是两个方向：

1、给“资深店铺运营”用：

他们是遇到具体封号邮件来找对策的。你的知识库需要保留冗长的申诉信模板、亚马逊原文条款。你需要把不同违规类型的“违规代码（如 Section 3）”作为极其重要的**元数据（Metadata）**打在切片上，方便他们精准过滤。

2、给“新入职的跨境小白”做培训用：

新员工根本看不懂亚马逊的官方术语。你在建库前，得先写个脚本，让大模型把指南总结成“10个绝对不能踩的红线”，并且用“通俗的总结”去建立摘要索引。检索召回后，大模型的 Prompt 里要写：“请用对待新手的耐心语气，用大白话解释，并举一个生活中的例子”。

三、总结

知识库不是一个标准化的“储物柜”，它是一件**“高级定制的西装”**。只有量了用户的体型（需求、术语习惯、权限），你裁剪出来的分块大小、检索策略和路由逻辑才能严丝合缝。

理清了这层产品逻辑，回头审视你现在正在操盘的这个项目：你最终打算把这个“亚马逊风控系统”交付给谁去使用？他们在使用这个系统时，最典型的场景是怎样的？