基于 RAG检索增强生成的智能家电客服助手支持自定义语气风格适配不同品牌调性让 AI 学习产品知识为用户提供专业、准确的咨询服务。项目能做什么先看效果 —— 在终端里直接和AI对话核心能力有五条智能问答回答用户关于智能家电的各种问题精准回复基于产品知识库避免 AI 随意编造风格统一始终保持专业的客服语气提升用户体验数据安全所有知识库存储在本地不上传云端定制能力通过替换知识库数据可适配不同品牌、不同场景的沟通风格为什么会做这个项目说来也巧本来就是突然想到之前看过的一个视频里面展示的是模拟朋友语气的AI聊天器好奇心驱动下就查了查怎么实现的。没想到一查还就陷进去了想着与其看一百篇理论文章不如自己动手写一个就简单搭建了一个模拟器还真成了再联想到前几天和某平台客服交流的经历一下子恍然大悟于是这个项目就应运而生了。关于项目的具体介绍可前往 Github 基于 RAG 的智能家电客服助手 查看 README相关代码也已经**开源到 Github ** 里面详细介绍了项目内容本地部署方法等等。下面的内容主要是关于本项目用到的技术踩坑经历以及后续计划等等希望对大家有帮助各位大佬如果有任何建议或者指正都可以提出来任何反馈都感激不尽一. 项目技术技术选型组件技术为什么选它开发语言Python 3.9AI生态最成熟代码简洁向量数据库ChromaDB轻量、本地存储不需要单独部署服务Embedding模型BAAI/bge-m3中文语义理解强性价比高大语言模型DeepSeek-V3中文能力突出响应速度极快API服务硅基流动提供稳定的模型 API 服务关于RAG vs 微调的选择最开始我也想过要不要做微调Fine-tuning但仔细分析后发现对比项RAG微调知识更新改chat.txt即可需要重新训练模型硬件要求普通电脑足够需要GPU至少10GB显存成本API按量付费几块钱能用很久训练成本高可控性完全控制知识来源知识被写进模型难以调试对于个人项目来说RAG是更务实的选择。核心流程整个程序的核心流程可以拆成五步用户输入 ↓ ① 读取知识库chat.txt ↓ ② 向量化存储ChromaDB ↓ ③ 检索最相似的3条话术 ↓ ④ 拼接System Prompt Context ↓ ⑤ 大模型生成回复 ↓ 返回结果关键代码解析知识入库先把chat.txt里的客服话术读进来withopen(chat.txt,r,encodingutf-8-sig)asf:lines[line.strip()forlineinf.readlines()ifline.strip()]然后调用硅基流动的 Embedding API把每条话术转成向量存入 ChromaDBdefget_embeddings_batch(texts):urlf{BASE_URL}/embeddingsheaders{Authorization:fBearer{API_KEY}}data{model:EMBEDDING_MODEL,input:texts}responserequests.post(url,jsondata,headersheaders)return[item[embedding]foriteminresponse.json()[data]]#批量向量化一次搞定比逐条快10-50倍embeddingsget_embeddings_batch(lines)# 存入向量数据库collection.add(documentslines,embeddingsembeddings,ids[fid_{i}foriinrange(len(lines))])检索 生成用户提问时先检索最相似的话术再让大模型参考这些话术生成回复defchat(user_input):# 第一步把用户问题转成向量检索最相似的3条vecget_embeddings_batch([user_input])[0]resultscollection.query(query_embeddings[vec],n_results3)context\n.join(results[documents][0])# 第二步构造System Prompt把检索结果作为参考system_promptf 你是一个专业的客服助手。参考以下话术回答用户 ---话术参考---{context}---参考结束--- # 第三步调用大模型生成回复responseclient.chat.completions.create(modeldeepseek-ai/DeepSeek-V3,messages[{role:system,content:system_prompt},{role:user,content:user_input}])returnresponse.choices[0].message.content整个核心逻辑就这两块入库和检索生成加起来总共几十行代码二. 踩坑记录1. Windows 编码问题BOM 头现象AI 回复出现乱码原因Windows 记事本保存 UTF-8 文件时默认添加 BOM 头\ufeff解决方案# 使用 utf-8-sig 自动跳过 BOM 头withopen(chat.txt,r,encodingutf-8-sig)asf:linesf.readlines()2. 角色边界混淆现象AI 把“用户”的话也当成参考内容原因chat.txt中混入了“用户”前缀解决方案知识库只保留“客服”开头的标准话术System Prompt 中明确“你只需模仿客服角色”3. 日常寒暄无法处理现象说“再见”时 AI 回复“抱歉暂时无法回答”原因chat.txt中没有告别语触发“不知道就说不知道”规则解决方案在知识库中补充日常用语或在 System Prompt 中设置例外规则4. 向量检索不准确现象用户问的问题AI 检索到的 context 完全不相关原因知识库中的数据太短或太分散解决方案合并相关话术为更完整的段落增加n_results参数检索更多条使用更好的 Embedding 模型三 .成本分析这也是我做项目时很关心的问题。硅基流动我的实际使用情况是模型用途价格参考BAAI/bge-m3向量化≈ 0.07元 / 1M tokensDeepSeek-V3对话生成输入 ≈ 2元 / 1M tokens输出 ≈ 8元 / 1M tokens单次对话约500 tokens输入 100 tokens输出≈ 0.001-0.003元也就是说1块钱能对话300-1000次个人学习和测试成本很小。四 .后续计划这部分的话是我的一些后续计划如果条件允许我会慢慢迭代并上传在这里也欢迎大家提建议您的建议对项目迭代意义非凡□Web 界面基于 FastAPI Vue 构建可视化聊天界面□多知识库支持切换不同产品线的知识库□对话记忆支持多轮对话上下文关联□数据导入支持 JSON、CSV、PDF 等多种数据格式□即时通讯接入支持接入微信、钉钉、飞书等平台五. 写在最后做完这个项目我最深的感受是技术没有想象中的那么难但坑比想象中的多。RAG的原理看起来很简单——检索 生成。但真正做起来数据格式、编码问题、角色边界、模型语言切换……每一个细节都可能让你排查半天。但正是这些坑让我真正理解了RAG的工作机制也让我学会了如何一步步调试、优化。几点心得数据决定上限——chat.txt的质量决定了AI能回答得多好代码只是把这个质量发挥出来编码问题最隐蔽—— 一个看不见的BOM头能让你排查一整天工具链的细节很重要先跑起来再说—— 别想太多从最小可用版本开始然后再逐步优化项目已开源至Github 基于 RAG 的智能家电客服助手如果您也喜欢或者给您提供了一丝灵感欢迎 Star 支持也欢迎 Fork 项目进行二次开发或提交 Issue 和 我 一起完善。如果您也在做类似的项目欢迎交流讨论。