Langchain-Chatchat问答系统灰度效果评估：AB测试设计与结果分析

Langchain-Chatchat问答系统灰度效果评估：AB测试设计与结果分析

在企业数字化转型加速的今天，员工每天面对的信息量呈指数级增长——制度文件藏在共享盘深处、产品参数分散在几十份PDF中、客户常见问题依赖老员工口口相传。这种“知识可见但难用”的困境，正成为组织效率提升的关键瓶颈。

而更棘手的是，在引入AI助手时，许多企业陷入了两难：使用公有云服务担心数据泄露；自建系统又受限于技术门槛和成本。正是在这种背景下，像Langchain-Chatchat这样的开源本地化问答系统脱颖而出。它不追求通用世界的博学多识，而是专注于把企业的“私有知识”变成可对话的智能资产。

这套系统的核心思路很清晰：用你自己的文档训练一个专属AI，所有处理都在内网完成，既安全又精准。其背后融合了LangChain 框架的流程编排能力、高效的向量检索机制以及可在消费级GPU上运行的大语言模型（LLM），形成了一个闭环的知识服务引擎。

但问题随之而来：当我们在这样一个系统中上线新功能——比如更换更强的嵌入模型或优化分块策略——如何判断它真的变好了？是用户反馈更满意了，还是回答更准确了？这就引出了我们必须面对的实际课题：如何科学地评估一次迭代的真实影响？

要回答这个问题，不能靠主观感受，也不能只看单次测试的结果。我们需要一套严谨的方法论，其中最有效的就是AB测试。但在本地部署场景下做AB测试，和互联网产品的线上灰度发布有很大不同——没有海量用户流量可供分流，也无法轻易实现服务热切换。因此，整个评估体系必须从底层架构开始就具备可比性与可观测性。

先来看一看这个系统的运作逻辑。当你问出“年假怎么休？”这个问题时，系统并不会直接让大模型凭空作答，而是走完一整套精密协作的流程：

首先，你的问题会被同一个嵌入模型转换成向量，然后在本地构建的向量数据库（如FAISS或Chroma）中搜索语义最接近的几个文档片段。这些片段可能是《人力资源管理制度》中的某一段，也可能是去年发布的政策补充说明。接着，系统将原始问题和这些相关段落拼接成一条结构化提示（prompt），送入本地部署的LLM——比如ChatGLM或Qwen。最终生成的回答不仅基于模型自身的知识，更重要的是“引用”了真实存在的内部资料。

这个过程叫做检索增强生成（RAG），它是整个系统可靠性的基石。相比纯生成模式容易“一本正经地胡说八道”，RAG确保每一条回答都有据可依。我们甚至可以在前端展示答案的同时列出来源页码，极大增强了可信度。

为了实现这一点，LangChain 提供了一套高度模块化的编程接口。你可以像搭积木一样组合不同的组件：

from langchain.chains import RetrievalQA from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS from langchain.llms import ChatGLM # 初始化嵌入模型 embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-small-en") # 加载向量数据库 vectorstore = FAISS.load_local("knowledge_db", embeddings) # 初始化LLM（以ChatGLM为例） llm = ChatGLM( endpoint_url="http://localhost:8000", model_kwargs={"temperature": 0.7} ) # 构建检索问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(search_kwargs={"k": 3}), return_source_documents=True ) # 执行查询 query = "公司年假政策是如何规定的？" result = qa_chain({"query": query}) print(result["result"]) print("来源文档：", [doc.metadata for doc in result["source_documents"]])

这段代码看似简单，实则暗藏多个关键决策点。例如，k=3表示每次检索返回三个最相关的文本块，太少可能遗漏重要信息，太多则会引入噪声干扰LLM判断。再如，embedding模型必须与知识库构建时一致，否则语义空间错位会导致检索失效——这就像用中文提问却用英文索引去查，注定徒劳无功。

而这一切的前提，是高质量的知识库构建。文档加载后并非原封不动存入数据库，而是经历了解析、分块、向量化三步处理。特别是文本分割环节，直接影响后续检索的粒度与完整性。

from langchain.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.vectorstores import Chroma # 加载PDF文档 loader = PyPDFLoader("policy_manual.pdf") pages = loader.load() # 分割文本 text_splitter = RecursiveCharacterTextSplitter( chunk_size=300, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", " ", ""] ) docs = text_splitter.split_documents(pages) # 创建向量数据库 vectorstore = Chroma.from_documents( documents=docs, embedding=embeddings, persist_directory="knowledge_db" ) vectorstore.persist()

这里的chunk_size=300是个经验值。太小可能导致上下文断裂（比如一句话被切成两半），太大则超出LLM的上下文窗口限制，造成信息截断。重叠字段chunk_overlap则用于缓解边界信息丢失的问题。实际项目中，我们发现对于政策类文档，保留约50个token的重叠能显著提升跨段落问题的回答质量。

至于大模型本身，则通常通过本地API服务形式部署。以通义千问Qwen-7B为例，利用lmdeploy工具可以快速启动一个支持INT4量化的推理服务，在24GB显存的GPU上稳定运行：

lmdeploy serve api_server \ /models/Qwen-7B-Chat \ --model-name qwen \ --quant-policy 4 \ --cache-max-entry-count 0.8

客户端通过标准HTTP协议调用即可集成到主程序中。这种方式解耦了前端交互与后端推理，也为AB测试创造了条件——我们可以同时运行两个版本的LLM服务，根据路由规则分配请求。

说到这里，终于可以切入核心议题：如何设计这场灰度实验？

假设我们要评估新版知识库（采用BGE-base-zh-v1.5嵌入模型 + 更优分块策略）相比旧版是否提升了整体表现。理想情况下，我们会希望对比以下几个维度：

• 准确性：回答是否正确引用了相关政策条款；
• 相关性：检索出的上下文是否紧扣问题主题；
• 响应时间：端到端延迟是否有明显变化；
• 用户体验：用户是否会重复提问同一问题（间接反映满意度）。

但由于缺乏大规模真实用户行为数据，我们转而采用“种子问题集 + 人工评分”的方式。具体做法是：

1. 收集过去一个月内高频提问的50个典型问题，涵盖人事、财务、IT支持等类别；
2. 将这些问题分别提交给A组（旧系统）和B组（新系统），记录各自的输出结果；
3. 邀请三位业务专家对每条回答进行盲评打分（满分5分），重点关注事实准确性和信息完整性；
4. 同步采集技术指标：检索耗时、生成耗时、命中文档数量等。

测试结果显示，B组在平均得分上高出0.6分（4.1 vs 3.5），尤其在涉及复合条件的问题（如“外派员工年假如何计算？”）上优势明显。进一步分析发现，新嵌入模型在长句语义匹配上的表现更好，且优化后的分块策略减少了关键信息被切分的情况。

但我们也注意到，B组的平均响应时间增加了约800ms，主要来自向量编码阶段。这提示我们在未来迭代中需权衡性能与精度——有时候轻微的准确率提升并不值得付出显著的延迟代价。

在整个过程中，日志记录起到了决定性作用。我们为每次查询添加了唯一trace_id，并持久化存储输入、输出、检索上下文及各阶段耗时。这不仅便于事后复盘，也为自动化评估提供了数据基础。例如，可以通过计算BLEU或ROUGE分数初步筛选异常结果，再交由人工复核。

当然，这套系统仍有改进空间。目前的知识更新仍需手动触发重建流程，未来可探索增量索引机制，做到“文档一上传，知识即生效”。另外，当前评估依赖人工打分，成本较高。随着小型裁判模型（judge model）的发展，有望实现自动评分闭环。

回到最初的问题：什么样的升级才算真正有效？答案不是某个单一指标的提升，而是在安全性、准确性、性能和可维护性之间找到新的平衡点。Langchain-Chatchat的价值，恰恰在于它提供了一个足够灵活又足够稳定的试验场，让我们能一次次验证想法、收集反馈、持续进化。

这类本地智能系统不会取代大型AI平台，但它正在重新定义“企业智能”的边界——不再依赖云端黑盒服务，而是扎根于组织自身的知识土壤，生长出真正属于自己的数字大脑。