基于大模型的聊天助手案例：企业知识库与智能客服实践
随着大语言模型（LLM）技术的成熟，越来越多的企业开始探索将 LLM 与业务场景结合。LLM 强大的语义理解能力使其非常适合应用于聊天机器人和智能客服场景。然而，在实际落地过程中，如何保证回答的准确性、安全性以及上下文的一致性，是技术团队面临的主要挑战。
本文以某知名数据库厂商的智能客服机器人项目为例，深入剖析在构建企业专属知识库聊天助手时遇到的核心问题及解决方案，涵盖向量检索优化、毒性检测、意图理解及持续运营策略。
1. 企业专属知识库智能客服的核心需求
期望通过 LLM 实现的典型需求包括：
- 多轮对话理解：采取多轮对话形式，准确理解用户的提问并给出回答。LLM 在此方面表现优异，能够完美实现自然语言交互。
- 领域知识准确性：在回答内容中，关于特定产品或技术栈（如 TiDB、TiDB Cloud）的知识点要求准确无误。这通常需要通过检索增强生成（RAG）技术，利用向量数据库来满足。
- 边界控制：不能回答与业务范围无关的内容。这需要引入毒性检验（Toxicity Check）机制来过滤越界请求。
1.1 实践中遇到的主要问题
在项目实施初期，团队遇到了以下典型问题：
- 不准确的不良内容识别：一些与公司业务相关的问题被模型误判并拒绝回答。例如，"dumpling"实际上是某个数据导出工具的代号，但当用户直接提问 "dumpling 是什么？"时，通用模型容易将其误认为是食物词汇，从而拒绝回答并建议咨询美食专家。
- 上下文理解失误：在执行多轮对话时，用户常会对之前的对话内容进行追问，此时他们通常只会简洁地描述，如：'这个参数的默认值是多少？'如果系统仅使用用户的原始问题进行语义搜索，往往无法得到有意义的答案。这样一来，即使将问题输入到 LLM，也无法根据官方文档给出正确的答案。
- 语义搜索结果不精确：有时候，用户的问题非常明确，但是由于向量数据库搜索出的内容排序有误，导致在排名前 N 的答案中无法找到能正确回答问题的文档内容。
- 文档信息不足或过时：有些情况下，尽管用户的问题表述得很清楚，但由于官方文档不够完整或过时，没有包含相关内容，导致 LLM 在回答时只能凭借猜测，因此很多时候其给出的答案是错误的。
2. 技术方案详解
2.1 向量数据库补充专业知识
在用户发起一次对话时，系统会将用户的对话输入 Embedding 模型中生成向量，再将这个向量放到向量数据库中和原有的语料进行查询。
针对'用户的提问很清楚，但是向量数据库搜索出的 Top N 中无法看到对应的文档内容'这一问题，想要稳定地提升语义搜索的产出质量，有两个直接、有效且快速实现的方法：
- 调整领域内容和提问之间的向量距离：通过微调 Embedding 模型，使其更关注特定领域的语义特征。
- 额外召回特定内容的示例：在召回领域知识的内容之外，额外召回特定内容的示例作为参考。
实施步骤
- 第一步：先用类似'毒性检测的漏网之鱼'的方法，额外针对易错点补充示例，并将这些示例也随系统提示词一同提供给 LLM 模型，提高准确率。
- 第二步：在示例积累到一定数量后，将示例内容作为训练数据，去训练 Embedding 模型。让 Embedding 模型能更好地理解提问和领域知识之间的相似关系，产出更合适的向量数据结果。这种方法被称为领域自适应（Domain Adaptation）。
2.2 毒性检验与安全对齐
2.2.1 毒性回答的预训练
LLM 会努力让其回答符合人类的价值观，这一工作在模型训练中叫做'对齐'（Align），旨在让 LLM 拒绝回答仇恨、暴力相关的问题。如果 LLM 未按照设定回答了仇恨、暴力相关问题，我们就称之为检测出了毒性（Toxicity）。
对于企业级机器人，其毒性的范围实际上增加了，即所有回答了非公司业务的内容都可以称之为存在毒性。需要使用 Few-Shot（少样本学习）的方法去构建毒性检测的提示词，让 LLM 在拥有多个示例的情况下，判断用户的提问是否符合企业服务的范围。
代码示例：毒性检测 Prompt 结构
const toxicCheckPrompt = ;
