用RAG做了个智能客服，上线第一天就被使用者骂了——我的7天实战复盘

开场的观点是。需求来得比外卖还快

周一早上九点，我刚坐下还没来得及打开工位的加湿器，产品经理老王就搬着笔记本坐到了我旁边。

"badhope。老板要个智能客服程序，两周内上线，目标是替代掉现在3个客服的人力成本。"

我差点把咖啡喷到键盘上。3个客服，每天处理大概800条咨询。涵盖退换货、物流、支付、会员等十几个业务线。现在两周之内要用AI把这事儿干了？按理说，

"不就是RAG嘛。检索+生成，我已经看过不少demo了。"我当时心里是这么想的，LangChain拉一把，向量库存一下文档。 调一下GPT的接口，一个下午就能跑起来。

实际来看，我太天真了。Demo和生产之间，隔着的不是一道墙，是一片海。

第一版我花了两天就搭完了——FAISS存了200条FAQ文档。ada-002做embedding，GPT-4做生成。自己测了几条觉得还行，兴冲冲部署上去给产品体验。

结果老王问了句"我买的耳机能不能退货"。程序返回了一段关于"耳机保修政策"的内容，完全答非所问。他又问"怎么申请退款"，程序回了句"您可以联系客服处理"。 一个智能客服让使用者去找人工客服，这就很尴尬了。那天下午，我开始了真正的RAG实战。下面是我这一周踩过的所有坑，和每个坑对应的方法。

再看文档预处理，分块策略踩坑

第一个大坑就在文档分块上。不过，

看起来没什么问题对吧？但使用者问 ",程序返回了一段话：

注意到了吗？不过，返回的是半截回答. "以下商品不支持退换" 后面直接断了。使用者看到这个只会更困惑。

问题就出在固定长度分块上——它不管语义边界,硬生生在一个列表中间把文本切断了。政策文档里"以下商品不支持退换" 后面跟着6条具体商品。结果前3条在这个chunk,后3条在下一个chunk,向量检索只召回了前一个。

我开始研究不同的分块策略,对比了三种主流方案：

Chroma低<1万5-2s免费开发/测试Pinecone否1亿+-5ms按量付费生产Milvus高1亿+-ms服务器成本生产

实际来说,如果团队没有专职运维,Pinecone是最省心的选择——完全托管,

按照使用情况付费.但我们的数据涉及隐私安全,

最终选中Chroma做开发环境,Milvus做生产环境. Chroma好处在于可以嵌入式运行,

在Python环境中直接import使用起来方便. Milvus虽然部署麻烦些。

支持持久化存储和多机

对应于生产场景使用.

v lang=v hljs lang=v language-v lang-v
class=v

import chromadb from chromadb.config import Settings chromaclient = chromadb.PersistentClient collection = chromaclient.getorcreatecollection( name="customerservice_kb" metadata={"hnsw:space" "cosine" )

Milvus === from pymilvus import connections Collection FieldSchema CollectionSchema DataType connections.connect

fields = [ FieldSchema FieldSchema FieldSchema FieldSchema

schema = CollectionSchema

collection.createindex( fieldname="embedding indexparams={ "indextype &qoutIVFFLAT metrictype &qoutCOSINE params {&qoutnlist }

向量库解决之后

召回率还是难以提高.

接下来遇到的是Embedding模型上的挑战.

from langchain.text_splitter import RecursiveCharacterTextSplitter
# 自定义分隔符：按语义层级递归切分
separators = [
"
",# 段落
"
",# 单行换行
"。",# 中文句号
"，",# 感叹号
"？",# 问号
"，",# 分号
" ",# 空格
"" # 兜底：逐字符
splitter = RecursiveCharacterTextSplitter(
separators=separators,chunk_size=512,chunk_overlap=128。length_function=lambda x: len # 按字符数而非token
# 分块并附带元数据chunks = splitter.split_documents
print(f"原始文档数:
{len}")
print(f"分块后chunk数:
{len}")
print(f"平均chunk长度:
{sum for c in chunks) / len:.0f} 字符")
改完之后,"退换货政策"
这个问题终于返回了完整的政策说明。但新的问题来了——文档量一大,FAISS开始撑不住了。

向量数据库选型：别选花眼 
一开始我用FAISS在本地跑,200条FAQ没问题,响应很快.
但当我把完整知识库
灌进去之后,内存直接飙到8G,接下来OOM.
而且FAISS有个致命问题——它是纯内存的,每次重启都要重新加载全部向量.
我的服务每次启动要等4秒加载索引,


向量数据库 
是否需运维 
支持文档量 
查询延迟 
成本 
适用阶段