我是运营商门店的驻店专员，说白了就是卖套餐办业务。没有技术背景，Python 是今年 3 月在网吧学的。
90 天后，我搭了一个电信套餐智能问答系统，部署在云服务器上，评测准确率 98.7%，零幻觉。
这篇文章记录全过程：踩了什么坑，怎么爬出来的，以及一个非技术人员搞 AI 到底行不行。
为什么要做这个
今年 3 月，我调到新门店。店员们都没接触过购机优惠和套餐业务，平时也忙，凑不到一起培训。
运营商的套餐体系很复杂——不同档位的流量、通话、副卡规则、宽带权益、橙分期补贴，每个维度都不一样。新人问老员工，老员工也记不全，翻文档又慢。
我想：能不能搞个"智能客服"，店员直接问，系统自动答？
当时我刚考完 CAIE（注册人工智能工程师），学了一堆概念，但一行代码都没写过。
第一阶段：从零开始（第1-30天）
Day 1：Chroma Studio + 8G 内存
3 月 20 日，我下载了 Cherry Studio——一个可视化的 RAG 搭建工具。用 Ollama 部署了 BGE-M3 嵌入模型，配了 DeepSeek R1，把套餐文档导进去。
第一次对话测试：
CPU 风扇嗡嗡响，内存占用 99%，等了好几分钟，返回一串红色错误——文档没上传成功。
折腾半小时，文档终于嵌入进去了。再问一个问题，又等了十几分钟。8G 内存的电脑跑 BGE-M3，就是这个效果。
但答案是对的。
那一刻我知道方向对了。
平台选型：踩了五个坑
接下来就是不停地试错：
| ====平台==== | ===== 结果==== | ==== 问题==== |
|---|---|---|
| Cherry Studio | 能用但太简单 | 定制化程度低，没法加业务逻辑 |
| 腾讯云 ADP | 试用额度烧完 | 幻觉严重，误操作把额度用光了 |
| AnythingLLM | 安装成功 | 模型调用不稳定，经常超时 |
| Dify | 没搞成 | 在网吧电脑部署，重启就没了 |
| LangChain | 最终选择 | 自由度高，学习曲线陡，但可控 |
最终选 LangChain，不是因为它最好用，而是因为它最灵活——我可以控制检索策略、Prompt 模板、模型调用的每一步。
最崩溃的一天：编码问题
TXT 文档是 ANSI 编码，嵌入模型只认 UTF-8。
我试了 PowerShell 命令（中文乱码），Python 脚本（网吧电脑跑不了），VS Code 插件（内容被清空）……
最后发现要两步转换：先转带 BOM 的 UTF-8，再转无 BOM 的。
就这么一个小问题，折腾了大半天。后来才明白：数据清洗是 RAG 最基础也最容易被忽视的环节。
网吧做开发
我在网吧的电脑上搞这些。下载 Ollama 要几个小时（国外节点），Docker 要重启才能用（重启就没了），模型文件拷到移动硬盘结果丢失……
后来我学聪明了：在家先下好整个 ~/.ollama 目录，拷到移动硬盘带去网吧。
网吧做开发，每一步都是在跟环境搏斗。
转折点：上云（第30-45天）
本地搞不下去了。我租了阿里云 ECS，4 核 8G，把环境迁上去。
世界清净了：
- 不用担心电脑重启
- 不用跟网吧网速较劲
- 24 小时在线
在云服务器上，用 LangChain + ChromaDB + SiliconFlow API 重新搭建了 RAG 系统，这才算真正走上了正轨。
性能优化：120秒 → 4秒（第45-60天）
系统能跑了，但慢得离谱——120 秒才出结果。
瓶颈分析：LLM API 调用占了 80% 的时间，原始工作流调了 3 次 LLM（意图识别 → 信息提取 → 生成回复）。
优化步骤
第一步：减少 LLM 调用
把 3 次调用合并成 1 次，直接让 LLM 根据检索结果生成回答。
120s → 25s
第二步：换模型
从 DeepSeek-V4-Flash（25 秒/次）换成 GLM-4-9B（3 秒/次）。客服场景不需要最强模型，够用就行。
25s → 4s
第三步：加 Reranker
用 BGE-Reranker-v2-M3 对检索结果重排序，召回率提升 20-30%。
第四步：优化 Prompt
告诉 LLM"不要编造信息，文档里没有就说不知道"。幻觉率从 30% 降到 10%。
到这一步，纯 RAG 版本（rag-from-zero）基本能用了。我把它集成到钉钉，店员可以直接在群里 @机器人 问问题。
第二阶段：从 RAG 到 Agent（第60-90天）
纯 RAG 能用了，但有两个硬伤：
- 对比型查询效果差——"99 元和 129 元套餐有什么区别"，系统只能分别查两个套餐，没法做结构化对比
- 多跳推理不行——"办 2 张副卡后全家多少流量"，需要先查主卡流量、再查副卡规则、再算总和
于是我把它升级成 dx_agent——一个带 Agent 路由的智能问答系统。
核心升级
查询进来
↓
意图分类器（simple / comparison / complex）
↓
├── simple → 快速路径（直接检索 + 回答，1.8s）
├── comparison → 对比路径（per-tier 检索 + 表格展示，4.4s）
└── complex → Agent 路径（Tool Calling，LLM 自主决定查什么）
关键改动：
| 改动 | 效果 |
|---|---|
| 单一向量检索 → 向量 + BM25 混合检索 | 召回率从 70% 提升到 85%+ |
| 无路由 → 查询分类路由 | 简单查询省 60% token |
| 无状态 → 会话历史管理 | 支持多轮对话 |
| 一次性返回 → SSE 流式输出 | 用户体验提升 |
| 无缓存 → LRU + TTL 缓存 | 重复查询秒回 |
| 无对比 → per-tier 独立检索 + 表格 | 对比查询满分率 100% |
Agent 路由的实现
用 LangChain 的 Tool Calling，给 LLM 注册了三个工具：
tools = [
Tool("query_plan_info", search_knowledge_base, "查询套餐详情"),
Tool("compare_plans", compare_plans, "对比多个套餐"),
Tool("calculate", calculate, "计算费用/流量"),
]
LLM 自己决定什么时候查知识库、什么时候用计算器。对于"办 2 张副卡后全家多少流量"这种问题，它会：
- 先调
query_plan_info查主卡套餐的流量和副卡规则 - 再调
calculate算总流量 - 最后组织语言回答
最终评测结果
30 道真实业务题目，覆盖单点查询、套餐对比、复杂计算三种类型：
| 指标 | 结果 |
|---|---|
| 评测题目 | 30 题 |
| 成功率 | 30/30（100%） |
| 综合得分 | 148/150 星（98.7%） |
| 幻觉率 | 0% |
| 平均响应 | 3.0s |
| 最快 | 1.4s |
| 最慢 | 9.9s |
其中对比型查询（"99 元和 129 元套餐区别"）从纯 RAG 版本的 40% 满分率，提升到 100%。
两个版本的对比
| 维度 | rag-from-zero（V1） | dx_agent（V2） |
|---|---|---|
| 检索方式 | 单一向量检索 | 向量 + BM25 混合检索 |
| 路由 | 无，全部走 RAG | 查询分类 → 三条路径 |
| 简单查询响应 | 4.0s | 1.8s（提升 55%） |
| 对比查询 | 不支持 | 4.4s，表格展示 |
| 多轮对话 | 无状态 | 会话历史管理 |
| 输出方式 | 一次性返回 | SSE 流式 + 打字机效果 |
| 缓存 | 简单缓存 | LRU + TTL + 统计 |
| 准确率 | 85%+ | 98.7% |
我学到的 5 件事
1. RAG 的灵魂在检索，不在搭建
搭个能跑的 RAG 很快，但让它"好用"需要花 3 倍以上的时间调优检索策略。分块大小、相似度阈值、Reranker 配置——这些细节决定了系统的上限。
2. 数据质量 > 一切
垃圾数据进去，垃圾结果出来。文档编码、分块大小、信息冲突——这些"脏活"决定了系统的上限。我花了一整天解决编码问题，但这比换十个模型都有用。
3. 选对模型比选贵模型重要
客服场景用 GLM-4-9B（3 秒）比 DeepSeek-V4-Flash（25 秒）更合适，牺牲 5% 准确率换来 85% 的速度提升。够用就好，不要追最强。
4. AI 是工具，不是魔法
它没有自主意识，你不给指令它就不动。它会"幻觉"，会"忘记"你给过的知识。掌控程度决定效果。
5. 没有技术背景不是障碍
我做的是销售。从 Cherry Studio 到 LangChain，从网吧电脑到云服务器，从 120 秒到 1.8 秒——每一步都是边学边做。
你不需要会写底层框架，你需要的是理解业务问题，然后找到合适的工具去解决它。
技术栈总结
| 组件 | 选型 |
|---|---|
| 框架 | LangChain + LangGraph |
| 向量数据库 | ChromaDB |
| 嵌入模型 | BAAI/bge-large-zh-v1.5 |
| Reranker | BAAI/bge-reranker-v2-m3 |
| LLM | GLM-4-32B-0414（SiliconFlow API） |
| 部署 | 阿里云 ECS + FastAPI |
| 集成 | 钉钉机器人 / Web UI |
写在最后
这个项目从 3 月 20 日开始，到现在 90 天。中间经历了无数次失败、换方案、从头再来。
有人说"非技术人员搞不了 AI"，我觉得不对。你不需要会写底层框架，你需要的是理解业务问题，然后找到合适的工具去解决它。
RAG 不是终点。下一步我计划把它做成 MCP Server，做成可以培训店员的智能顾问。
路还长，但方向对了。
作者：关彧 | GitHub: Guanyu-AI-pro
项目地址：rag-from-zero
