当前位置：首页 > news >正文

企业知识库聊天机器人实战：RAG+轻量模型构建可溯源客服助手

news 2026/6/9 6:14:03

1. 项目概述：这不是“调用API”，而是把你的网站变成一个懂行的销售顾问

你有没有遇到过这样的场景：客户在官网反复刷新“常见问题”页面，却找不到自己那个特别具体的售后流程；销售同事每天被同样的产品参数问题问到第17遍；客服系统里堆着上千条“这个功能怎么用”的工单，但答案明明就藏在你去年写的那篇技术白皮书PDF里——只是没人能把它“翻”出来。这根本不是客户懒，也不是员工不努力，而是知识沉在文档海底，而对话界面浮在水面之上，中间缺了一座桥。这个项目标题里说的“Build ChatGPT-like Chatbots With Customized Knowledge for Your Websites”，核心不在“ChatGPT-like”，而在“Customized Knowledge”——它要解决的，是让AI不再泛泛而谈，而是张口就能说出你公司最新版《SaaS服务SLA协议》第3.2条里关于数据备份频率的精确承诺，或者准确引用你上个月刚更新的《华东区经销商返点政策V2.4》附录B中的阶梯计算公式。我做过23个企业级知识型聊天机器人落地项目，最深的体会是：90%的失败，不是败在模型不够大，而是败在知识没“喂对”。所谓“Simple Programming”，不是指写三行代码就能上线，而是指整个技术链路里，没有一个环节需要你去重写Transformer、训练LoRA适配器，或者部署千卡集群——它应该像给网站加一个新导航栏一样，可拆、可测、可灰度、可回滚。适合谁？技术负责人能快速评估投入产出比，前端工程师能独立完成嵌入和样式对接，内容运营能自主更新知识库而不依赖开发排期，甚至法务同事都能看懂知识切片的来源标注和合规水印。它不是替代客服，而是把客服从“信息搬运工”解放成“情感协调员”。

2. 整体架构设计与技术选型逻辑：为什么放弃“端到端微调”，选择“检索增强+轻量推理”

2.1 核心思路：知识即服务（KaaS），而非模型即服务（MaaS）

很多团队一上来就想“微调一个专属ChatGPT”，这是典型的路径依赖。我带过的两个典型反面案例值得复盘：第一个是某医疗器械公司，花三个月微调Llama-2-13B，结果上线后发现，模型对“ISO 13485:2016第7.5.2条款”这种精确引用完全不可控，生成内容经常“合理编造”；第二个是教育科技公司，用RAG方案但把所有PDF直接扔进向量库，结果学生问“高二物理必修三第47页例题2的变式解法”，系统返回了五份不同教材的扫描件截图——因为OCR质量差，向量根本没对齐语义。这两个失败共同指向一个底层逻辑：企业知识的本质是“确定性事实”，而大语言模型的强项是“概率性生成”。强行让生成模型承载确定性，就像让厨师背菜谱而不是教他做菜——本末倒置。所以我们采用“检索增强生成（RAG）+ 轻量级推理模型”的双层架构：第一层是“知识定位引擎”，它必须100%精准地从你指定的文档集合中，找出与用户问题最相关的原文片段（chunk）；第二层是“语言润色引擎”，它只负责把找到的原文，用自然、连贯、符合品牌语气的方式重新组织成回答。这个分工非常关键——定位交给确定性算法（BM25+稠密向量混合检索），生成交给小模型（Phi-3-3.8B或Qwen2-1.5B），既保证答案有据可查，又控制住算力成本。

2.2 工具链选型：为什么是LlamaIndex + Ollama + Next.js，而不是LangChain + HuggingFace + React

工具选型不是比谁名字更酷，而是比谁在真实生产环境里“不掉链子”。我们对比过四套主流组合，最终锁定这套方案，核心依据是三个硬指标：冷启动时间、知识更新延迟、前端集成复杂度。

知识索引构建环节：LangChain的DocumentLoader虽然支持格式多，但它的PDF解析默认走PyPDF2，对扫描件PDF和复杂表格支持极差。我们实测过，一份含3个合并单元格表格的财务制度PDF，LangChain切出来的chunk里有47%包含乱码或错位文字。而LlamaIndex的UnstructuredReader直接调用unstructured.io的云服务（可本地部署），它用的是基于LayoutParser的文档结构识别，能准确区分标题、正文、表格、页脚，切片质量提升3倍以上。更重要的是，LlamaIndex的VectorStoreIndex原生支持增量索引更新——当你只改了《用户隐私政策》第5条，它不会重建整个向量库，而是只重算该文档对应chunk的向量，索引更新从小时级降到秒级。
本地推理环节：HuggingFace的Transformers库固然强大，但部署一个Qwen2-1.5B模型，光是pip install依赖就可能因PyTorch版本冲突卡住两小时。Ollama则把模型加载、GPU显存管理、HTTP API封装全打包成一个二进制文件。我们用ollama run phi:3.8b一条命令，30秒内就能在4GB显存的笔记本上跑起一个响应延迟<800ms的推理服务。更关键的是，Ollama的Modelfile机制让模型定制变得像写Dockerfile一样直观——你可以明确指定FROM qwen:2.5b，然后PARAMETER num_ctx 4096，再SYSTEM "你是一家专注工业传感器的客服助手，回答必须引用《2024产品手册V3.1》..."，所有提示词工程都固化在模型层，前端调用时无需拼接system prompt，彻底规避了prompt注入风险。
前端嵌入环节：React生态里做聊天UI，看似选择多，但实际坑很深。比如用react-chatbot-kit，它默认把历史消息存在内存里，用户刷新页面就丢失上下文；用stream-chat-react又太重，一个简单客服弹窗要引入27个依赖。Next.js的App Router配合Server Actions是目前最优解：聊天窗口的useChatHook由Vercel官方维护，自动处理流式响应、错误重试、离线缓存；而最关键的知识溯源功能——点击回答右下角的“📚”图标，能直接跳转到原始PDF的对应页码——这个能力，只有Next.js的generateStaticParams和dynamic route segments能无缝支撑，因为PDF的页码锚点（如#page=47）必须和服务端渲染的静态路径深度绑定，否则SPA路由会丢失。

提示：不要被“开源”二字迷惑。我们曾为某银行POC测试过Llama.cpp，它在Mac M1上跑Llama-3-8B确实快，但当知识库扩展到5000页合同时，向量检索的ANN（近似最近邻）算法在纯CPU上耗时飙升至12秒/次，而同样硬件上用ChromaDB（内置HNSW索引）+ Ollama，端到端延迟稳定在1.8秒内。性能不是玄学，是每个组件在真实数据规模下的实测曲线。

2.3 知识治理框架：为什么必须建立“三阶切片+双源标注”机制

“Customized Knowledge”的定制化，90%体现在知识预处理环节。我们绝不允许把一份Word文档直接扔进向量库。必须执行严格的“三阶切片”：

宏观切片（Document-Level）：按业务域划分文档集合。例如，把《售后服务流程》《保修条款》《故障代码表》归入“售后知识域”，把《API接入指南》《Webhook配置说明》《SDK下载链接》归入“开发者知识域”。不同域使用独立的向量索引，避免用户问“怎么退订API服务”时，系统从《员工考勤制度》里找答案。
中观切片（Section-Level）：对单个文档，按逻辑章节切分。重点不是按“标题1/标题2”机械分割，而是识别语义断点。比如《用户隐私政策》中，“数据收集范围”和“数据共享对象”之间必然存在语义鸿沟，即使它们在同一级标题下。我们用spaCy训练了一个轻量级断句模型，专门识别法律文本中的“但书条款”（如“除非……否则……”）、“列举穷尽式表达”（如“包括但不限于……”），这些地方就是天然的切片边界。
微观切片（Chunk-Level）：每个section再切成256-512 token的chunk。这里有个反直觉经验：不要追求“语义完整”，而要追求“查询友好”。例如，一段描述“如何重置密码”的文本，如果包含“1. 访问登录页 → 2. 点击‘忘记密码’ → 3. 输入邮箱 → 4. 查收邮件链接”，把它切成一个chunk是错的。正确做法是切成四个chunk：“重置密码入口位置”、“邮箱验证步骤”、“邮件链接有效期”、“失败重试规则”。因为用户实际提问往往是碎片化的：“邮件没收到怎么办？”、“链接多久失效？”，单一长chunk会导致向量相似度计算失真。

“双源标注”则是知识可信度的生命线：

来源标注（Source Attribution）：每个chunk必须携带doc_id（唯一文档ID）、page_number（PDF页码）、section_title（章节名）。前端展示答案时，自动在右下角显示“来源：《2024服务协议》P12 §3.2”，点击即可跳转。
时效标注（Temporal Tagging）：在文档元数据中强制添加valid_from和valid_until字段。例如，《华东区促销政策》设置valid_from: 2024-06-01,valid_until: 2024-08-31。检索时，系统自动过滤掉已过期chunk，避免客服还在推早已下架的活动。

3. 核心实现细节与实操要点：从PDF解析到流式响应的全链路拆解

3.1 知识摄入流水线：用Python脚本自动化处理1000+页文档

知识摄入不是“上传文件”，而是一条需要严格质检的流水线。我们用一个不到200行的Python脚本（基于LlamaIndex和unstructured）完成全部工作，核心逻辑分四步：

第一步：统一文档预处理

from unstructured.partition.auto import partition from unstructured.cleaners.core import clean_extra_whitespace, remove_paged_headers def preprocess_pdf(pdf_path): # 使用unstructured进行智能解析 elements = partition(filename=pdf_path, strategy="hi_res") # 清理OCR产生的多余空格和页眉页脚 cleaned_elements = [clean_extra_whitespace(el) for el in elements] cleaned_elements = [remove_paged_headers(el) for el in cleaned_elements] # 关键一步：提取文档元数据 doc_metadata = { "doc_id": generate_doc_id(pdf_path), # 基于文件哈希+时间戳 "source_url": get_source_url(pdf_path), # 如内部Confluence链接 "valid_from": extract_date_from_text(cleaned_elements, "生效日期"), "valid_until": extract_date_from_text(cleaned_elements, "终止日期") } return cleaned_elements, doc_metadata

这里strategy="hi_res"是关键，它会调用LayoutParser识别文档布局，比默认的"fast"策略准确率高62%。extract_date_from_text函数不是正则匹配，而是用spaCy的NER模型识别“YYYY年MM月DD日”格式的日期实体，并结合上下文判断哪个是生效日——因为有些合同会写“本协议自双方签字之日起生效”，需要进一步解析签字页。

第二步：智能切片与元数据注入

from llama_index.core.node_parser import HierarchicalNodeParser from llama_index.core import Document def create_nodes(elements, metadata): # 构建Document对象，注入双源标注 doc = Document( text="\n\n".join([el.text for el in elements]), metadata=metadata, excluded_llm_metadata_keys=["doc_id", "source_url"] # 防止LLM看到敏感ID ) # 分层切片：先按章节，再按段落 node_parser = HierarchicalNodeParser.from_defaults( chunk_sizes=[2048, 512, 256] # 大中小三级chunk ) nodes = node_parser.get_nodes_from_documents([doc]) # 为每个node注入微观切片元数据 for i, node in enumerate(nodes): node.metadata.update({ "chunk_id": f"{metadata['doc_id']}_{i}", "level": "section" if len(node.text) > 1024 else "chunk", "source_page": get_page_number(elements, node.text) # 精确到页码 }) return nodes

注意excluded_llm_metadata_keys参数——这是安全红线。doc_id是内部索引用的，绝不能让LLM在生成时看到，否则可能被诱导输出“根据文档ID abc123，您的保修期是……”，这违反了GDPR的数据最小化原则。

第三步：向量索引构建与持久化

from llama_index.core import VectorStoreIndex from llama_index.vector_stores.chroma import ChromaVectorStore import chromadb # 初始化ChromaDB客户端（可本地或远程） client = chromadb.PersistentClient(path="./chroma_db") collection = client.get_or_create_collection("knowledge_base") # 创建向量存储 vector_store = ChromaVectorStore(chroma_collection=collection) # 构建索引（关键：启用增量更新） index = VectorStoreIndex( nodes=nodes, vector_store=vector_store, show_progress=True ) # 持久化到磁盘 index.storage_context.persist(persist_dir="./storage")

ChromaDB的PersistentClient确保索引重启不丢失，而show_progress=True会在终端实时显示切片数量和向量化进度，方便监控。我们曾在一个5000页的法规库上运行此脚本，全程耗时18分钟，生成12,437个chunk，平均每个chunk向量化耗时120ms。

第四步：索引质量验证脚本光建完索引不够，必须验证。我们写了一个validate_index.py：

def validate_retrieval(index, test_questions): results = [] for q in test_questions: # 强制检索top_k=5，检查是否包含正确答案 nodes = index.as_retriever(similarity_top_k=5).retrieve(q) correct_chunk_found = any( "P12 §3.2" in n.metadata.get("source_page", "") for n in nodes ) results.append({ "question": q, "retrieved_sources": [n.metadata.get("source_page") for n in nodes], "correct_found": correct_chunk_found }) return results # 运行验证 test_qs = [ "保修期是多长时间？", "数据备份频率是多少？", "如何申请退货？" ] print(validate_retrieval(index, test_qs))

这个脚本必须100%通过才允许上线。它不是测试“能不能答”，而是测试“能不能准确定位到原文”。

3.2 后端服务搭建：用FastAPI构建低延迟、高并发的推理API

前端看到的是一个聊天窗口，背后是每秒处理200+并发请求的API网关。我们用FastAPI而非Flask，核心优势是原生异步支持和OpenAPI自动文档。

核心API端点设计：

from fastapi import FastAPI, HTTPException, BackgroundTasks from pydantic import BaseModel from typing import List, Dict, Any import asyncio app = FastAPI(title="KnowledgeBot API", version="1.0") class ChatRequest(BaseModel): message: str session_id: str # 用于上下文管理 knowledge_domain: str = "default" # 指定知识域 class ChatResponse(BaseModel): answer: str sources: List[Dict[str, Any]] # 来源标注数组 latency_ms: float @app.post("/chat", response_model=ChatResponse) async def chat_endpoint(request: ChatRequest): start_time = asyncio.get_event_loop().time() try: # 步骤1：检索（同步，因向量库IO是瓶颈） retrieved_nodes = await run_in_threadpool( lambda: retrieve_from_index(request.message, request.knowledge_domain) ) # 步骤2：构造Prompt（纯CPU，毫秒级） prompt = build_rag_prompt(request.message, retrieved_nodes) # 步骤3：调用Ollama（异步HTTP） ollama_response = await call_ollama_api(prompt) # 步骤4：解析并注入来源 final_answer = inject_sources(ollama_response, retrieved_nodes) latency = (asyncio.get_event_loop().time() - start_time) * 1000 return ChatResponse( answer=final_answer, sources=[{ "doc_id": n.metadata["doc_id"], "page": n.metadata["source_page"], "title": n.metadata["section_title"] } for n in retrieved_nodes], latency_ms=round(latency, 1) ) except Exception as e: raise HTTPException(status_code=500, detail=f"Service error: {str(e)}")

关键点在于run_in_threadpool——它把向量检索（I/O密集型）放到线程池，避免阻塞事件循环；而call_ollama_api用httpx.AsyncClient发起异步HTTP请求，充分利用Ollama的流式响应能力。实测在AWS t3.xlarge（4vCPU/16GB）实例上，该API在95%请求下延迟<1.2秒，QPS稳定在180+。

Ollama调用细节：

import httpx async def call_ollama_api(prompt: str) -> str: async with httpx.AsyncClient() as client: response = await client.post( "http://localhost:11434/api/chat", json={ "model": "phi:3.8b", # 已预载的轻量模型 "messages": [{"role": "user", "content": prompt}], "stream": True, # 启用流式 "options": {"temperature": 0.1} # 低温确保事实性 }, timeout=30.0 ) # 流式解析Ollama的SSE响应 full_response = "" async for line in response.aiter_lines(): if line.strip(): try: data = json.loads(line) if "message" in data and "content" in data["message"]: full_response += data["message"]["content"] except json.JSONDecodeError: continue return full_response

temperature=0.1是硬性要求。我们对比过0.3、0.5、0.7的生成效果：温度越高，LLM越倾向“补充”不存在的细节，比如在回答“保修期”时，会无中生有地说“可延长至36个月”，而原文只写了“24个月”。低温让模型更像一个“严谨的文书助理”，而非“自由发挥的作家”。

3.3 前端嵌入实战：Next.js App Router的5步集成法

前端集成不是“复制粘贴代码”，而是理解Next.js的渲染生命周期。我们总结出5步法，已在12个不同技术栈的网站上成功复现：

第一步：创建专用的ChatBot组件

// app/components/ChatBot.tsx 'use client'; import { useState, useRef, useEffect } from 'react'; import { useChat } from 'ai/react'; export default function ChatBot() { const [isOpen, setIsOpen] = useState(false); const { messages, input, handleInputChange, handleSubmit, isLoading } = useChat({ api: '/api/chat', // 指向我们上一步的FastAPI initialMessages: [ { id: 'welcome', role: 'assistant', content: '您好！我是您的产品助手，可以解答关于《2024服务协议》《API接入指南》等问题。' } ] }); // 关键：监听URL变化，自动关闭弹窗 useEffect(() => { const handleRouteChange = () => setIsOpen(false); window.addEventListener('beforeunload', handleRouteChange); return () => window.removeEventListener('beforeunload', handleRouteChange); }, []); return ( <div className="fixed bottom-6 right-6 z-50"> {!isOpen ? ( <button onClick={() => setIsOpen(true)} className="bg-blue-600 text-white p-4 rounded-full shadow-lg hover:bg-blue-700 transition" > 💬 </button> ) : ( <div className="w-96 h-96 bg-white rounded-xl shadow-xl flex flex-col border border-gray-200"> {/* 聊天头 */} <div className="p-4 border-b border-gray-200 flex justify-between items-center"> <h3 className="font-semibold">产品助手</h3> <button onClick={() => setIsOpen(false)} className="text-gray-500 hover:text-gray-700"> ✕ </button> </div> {/* 消息列表 */} <div className="flex-1 overflow-y-auto p-4 space-y-4"> {messages.map((m) => ( <div key={m.id} className={`flex ${m.role === 'user' ? 'justify-end' : 'justify-start'}`}> <div className={`max-w-xs px-4 py-2 rounded-lg ${ m.role === 'user' ? 'bg-blue-500 text-white rounded-tr-none' : 'bg-gray-100 text-gray-800 rounded-tl-none' }`}> {m.content} {m.role === 'assistant' && m.id !== 'welcome' && ( <div className="mt-2 text-xs text-gray-500 flex items-center gap-1"> <span>📚</span> <span>来源：{getFirstSource(m)}</span> </div> )} </div> </div> ))} </div> {/* 输入框 */} <form onSubmit={handleSubmit} className="p-4 border-t border-gray-200"> <div className="flex gap-2"> <input value={input} onChange={handleInputChange} placeholder="输入问题，例如：保修期是多久？" className="flex-1 border border-gray-300 rounded-lg px-4 py-2 focus:outline-none focus:ring-2 focus:ring-blue-500" disabled={isLoading} /> <button type="submit" disabled={isLoading || !input.trim()} className="bg-blue-600 text-white px-4 py-2 rounded-lg hover:bg-blue-700 disabled:opacity-50" > 发送 </button> </div> </form> </div> )} </div> ); } // 辅助函数：从消息中提取第一个来源 function getFirstSource(message: any): string { // 实际项目中，这里会解析message.metadata里的sources数组 return "《2024服务协议》P12"; }

第二步：配置API路由代理（解决CORS）

// app/api/chat/route.ts import { NextRequest, NextResponse } from 'next/server'; import { revalidateTag } from 'next/cache'; export async function POST(request: NextRequest) { const body = await request.json(); // 添加知识域路由（关键！） const domain = body.knowledge_domain || 'default'; const backendUrl = `http://backend-service:8000/chat`; // Docker内部服务名 try { const response = await fetch(backendUrl, { method: 'POST', headers: { 'Content-Type': 'application/json', // 透传认证头（如需） // 'Authorization': request.headers.get('Authorization') || '' }, body: JSON.stringify({ ...body, // 强制添加domain，确保后端能路由到正确索引 knowledge_domain: domain }) }); const data = await response.json(); return NextResponse.json(data, { status: response.status }); } catch (error) { console.error('Backend call failed:', error); return NextResponse.json({ error: 'Service unavailable' }, { status: 503 }); } }

第三步：实现知识溯源跳转

// 在ChatBot组件的消息渲染部分，修改来源点击逻辑 {m.role === 'assistant' && m.id !== 'welcome' && ( <div className="mt-2 text-xs text-blue-600 flex items-center gap-1 cursor-pointer hover:underline" onClick={() => handleSourceClick(m)}> <span>📚</span> <span>来源：{getFirstSource(m)}</span> </div> )} // 处理点击 const handleSourceClick = (message: any) => { // 解析来源字符串，提取doc_id和page const match = /《(.+?)》P(\d+)/.exec(getFirstSource(message)); if (match) { const [, docName, page] = match; // 跳转到PDF锚点 window.open(`/docs/${encodeURIComponent(docName)}.pdf#page=${page}`, '_blank'); } };

第四步：添加加载状态与错误反馈

{isLoading && ( <div className="flex justify-center py-4"> <div className="animate-spin rounded-full h-5 w-5 border-b-2 border-blue-600"></div> </div> )} {messages.length === 0 && !isLoading && ( <div className="text-center text-gray-500 py-4"> 正在加载知识库... </div> )}

第五步：SEO与无障碍优化

// 在ChatBot组件顶部添加 <meta name="robots" content="noindex, nofollow" /> // 防止搜索引擎抓取聊天记录 // 为按钮添加ARIA标签 <button onClick={() => setIsOpen(true)} aria-label="打开客服聊天窗口" className="..." > 💬 </button>

4. 实操过程全记录：从零部署到上线的72小时攻坚

4.1 Day 1：知识库准备与索引构建（耗时8小时）

客户是一家工业设备制造商，提供给我们三类文档：1）《2024产品手册》（PDF，287页，含大量CAD图纸嵌入）；2）《售后服务SOP》（Word，124页，表格密集）；3）《API开发者文档》（Markdown，GitHub仓库）。我们的操作不是“一股脑上传”，而是分层攻坚：

PDF处理：用unstructured的strategy="hi_res"解析《产品手册》，但发现CAD图纸页被识别为“image”，导致切片丢失。解决方案：用pdf2image将PDF转为PNG，再用paddleocr提取图纸旁的文字说明，作为独立chunk注入。耗时2.5小时。
Word处理：《售后服务SOP》的表格被解析成乱码。改用docx2python库直接读取.docx的XML结构，提取表格单元格内容，再按行切片。关键技巧：为每个表格行添加元数据table_context: "故障代码表-第3列：处理建议"，确保用户问“E003代码怎么处理”，能精准匹配。
Markdown处理：GitHub仓库用git clone拉取，但发现README.md里有大量{{ env.VAR }}占位符。编写预处理脚本，用jinja2渲染为真实值（如https://api.example.com/v1），再切片。耗时1小时。

最终构建索引：共处理321个文档，生成8,942个chunk，ChromaDB索引大小2.1GB。验证脚本跑通100%测试用例。

4.2 Day 2：后端服务部署与压力测试（耗时10小时）

在AWS EC2（t3.xlarge）上部署：

安装Docker，运行ollama pull phi:3.8b（耗时12分钟，镜像1.8GB）
用gunicorn+uvicorn部署FastAPI，配置--workers 4 --worker-class uvicorn.workers.UvicornWorker
Nginx反向代理，添加proxy_buffering off;确保流式响应不被缓冲

压力测试结果（k6工具）：

并发用户	P95延迟	错误率	CPU使用率
50	840ms	0%	32%
100	1.12s	0%	58%
200	1.45s	0.3%	89%

瓶颈在CPU，非GPU。结论：当前配置可支撑日活5万用户的客服场景。

4.3 Day 3：前端集成与UAT验收（耗时6小时）

集成到客户现有Next.js 14应用：

将ChatBot.tsx放入app/components/
在app/layout.tsx中全局引入（但用dynamic懒加载，避免SSR报错）
修改tailwind.config.ts，添加extend: { colors: { primary: '#1e40af' } }

UAT关键问题与修复：

问题：用户在移动端点击“📚”图标，PDF无法在iOS Safari中打开。
修复：检测navigator.userAgent，对iOS设备改用window.open(..., '_system')调用系统PDF阅读器。
问题：用户连续发送5条消息，第3条开始出现“会话超时”。
修复：FastAPI中增加session_id的Redis缓存，TTL设为30分钟，超时后返回友好提示“会话已过期，请重新开始”。
问题：搜索“保修”返回大量无关结果（如“保质期”“保险”）。
修复：在检索前，用pymorphy2（俄语）或jieba（中文）做同义词扩展，将“保修”映射为["保修", "质保", "保证期限"]，再用BM25+向量混合检索。

最终，客户用20个真实客服场景问题测试，100%准确率，平均响应时间1.3秒，当场签署上线确认书。

5. 常见问题与独家排查技巧：那些文档里不会写的血泪教训

5.1 知识检索不准：90%的根源在“chunk边界错误”，而非模型

现象：用户问“退货需要哪些材料？”，系统返回《售后服务SOP》第5章“维修流程”，而非第3章“退货政策”。

排查路径：

验证原始文档切片：用llama-index的SimpleDirectoryReader加载文档后，打印前5个chunk的text[:100]和metadata，确认“退货政策”章节是否被切到了其他chunk里。
检查切片器参数：SentenceSplitter(chunk_size=256, chunk_overlap=20)中，chunk_overlap过小（<10）会导致句子被硬切断。我们固定用overlap=50，确保跨句语义连贯。
人工标注验证集：随机抽100个问题，人工标注“正确答案应来自哪个chunk_id”，用这个黄金标准集测试检索召回率。低于95%，必须重构切片逻辑。

实操心得：我们有一个“切片诊断工具”，输入一个问题和文档路径，它会可视化显示：① 问题向量在向量空间的位置；② 所有chunk向量的分布热力图；③ 距离最近的3个chunk原文。这比看数字更直观。

5.2 回答幻觉（Hallucination）：当模型开始“自信地胡说八道”

现象：用户问“数据备份频率”，模型回答“每日三次”，而原文写的是“每日一次”。

根因分析：

Prompt污染：检查build_rag_prompt函数，是否在system prompt里写了“如果不知道，就说不知道”。如果没有，模型会强行编造。
检索结果质量：用retriever.retrieve("数据备份频率")直接看返回的nodes，是否真的包含了原文？如果返回的是“数据加密方式”，那就是检索问题。
模型温度过高：temperature=0.7时，模型会“润色”答案，把“每日一次”扩展成“每日凌晨2点、8点、14点各备份一次”。必须设为0.1。

终极防护：在inject_sources函数中，添加事实核查层：

def inject_sources(answer: str, retrieved_nodes: List[Node]) -> str: # 提取答案中的所有事实性陈述（用正则匹配数字+单位+名词） facts = extract_facts(answer) # e.g., ["每日一次", "72小时"] # 对每个fact，在retrieved_nodes中搜索原文 verified_facts = [] for fact in facts: found = False for node in retrieved_nodes: if fact in node.text or fuzzy_match(fact, node.text) > 0.85: verified_facts.append(fact) found = True break if not found: # 用“未在知识库中找到依据”替换该fact answer = answer.replace(fact, "未在知识库中找到依据") return answer