裁员潮中，我用RAG重构了代码人生
早上八点，咖啡刚泡好，我盯着本地IDE里那个跑不通的向量检索模块，脑子里还在回放昨天晚上和猎头的电话。"三线城市？技术负责人？有AI项目经验吗？"对方语气礼貌但明显兴趣缺缺。我苦笑了一下，把手机扔到一边，继续调试——毕竟，再焦虑也得先把今天要交付的POC搞定。
我是某三线城市一家中型互联网公司的技术负责人，入职三年多，从单体架构一路陪着公司拆到微服务，熬过双11大促，也扛过凌晨三点的线上事故。老实说，公司氛围其实不错，老板不画饼，同事不甩锅，连产品经理都学会了说“这个需求我们先评估下技术可行性”。但去年开始，行业风向变了。先是隔壁组裁了三分之一，接着年终奖缩水，再后来，连服务器预算都开始砍。我知道，该考虑换个环境了。
从“稳”到“慌”，只差一封邮件
去年11月，一封全员邮件打破了平静。内容很官方：“优化组织结构，聚焦核心业务”。但明眼人都知道，这是裁员前奏。虽然我暂时安全，但心里清楚——在三线城市，技术栈偏传统、业务增长停滞的公司，能撑多久？更现实的是，如果真被裁，我能去哪？
我翻了翻自己的技术栈：Spring Boot、MySQL、Redis、K8s……都是实打实的生产经验，但在一线大厂的JD里，这些已经成了“基础要求”。真正让我心慌的，是那些高频出现的关键词：AIGC、大模型、RAG、向量数据库、LangChain。我连RAG（Retrieval-Augmented Generation）是啥都得现查。
那一刻，我意识到：我的代码人生，可能卡在了“能跑就行”的舒适区。
RAG不是魔法，但可能是船票
说实话，一开始我对RAG这种“新概念”是有点抵触的。总觉得又是资本炒出来的 buzzword。直到上个月，产品部提了个需求：做个智能客服，能回答用户关于我们SaaS产品的各种问题，别再让人工客服背FAQ文档了。
我第一反应是：“这不就是个关键词匹配+规则引擎？”
但产品小王神秘一笑：“老板说，要‘像ChatGPT那样’。”
得，又是老板的“灵光一现”。可抱怨归抱怨，活儿得干。我花了一周时间研究，才搞明白RAG的核心逻辑：不把所有知识塞进模型，而是让模型在回答时，实时从外部知识库中检索相关片段，再生成答案。这样既避免了微调大模型的高昂成本，又能保证答案的准确性。
对我们这种小团队来说，简直是天赐良方！
从零搭建RAG，踩坑比写代码还多
说干就干。我选了开源方案：LlamaIndex + Milvus（轻量级向量数据库） + 本地部署的ChatGLM3-6B。目标很明确：用最低成本跑通流程。
但现实很快给了我一记重拳。
坑1：文档切片不是Ctrl+C/V
我天真地以为，把公司帮助文档PDF一股脑丢进去就行。结果生成的答案要么驴唇不对马嘴，要么直接 hallucinate（幻觉）。后来才明白，RAG的效果，70%取决于数据预处理。
我花了整整三天做文本清洗：
- 去掉页眉页脚
- 合并跨页表格
- 按语义分块（chunking），而不是按固定字符数
- 给每个chunk加元数据（比如所属模块、更新时间）
# 示例：用LlamaIndex做语义分块
from llama_index import SimpleDirectoryReader, VectorStoreIndex
from llama_index.node_parser import SentenceSplitter
documents = SimpleDirectoryReader("docs/").load_data()
splitter = SentenceSplitter(chunk_size=512, chunk_overlap=50)
nodes = splitter.get_nodes_from_documents(documents)
# 关键：保留原始文档ID，方便溯源
for node in nodes:
node.metadata["source_doc_id"] = node.source_node.node_id
坑2：向量检索，召回率才是命门
本地测试时，问“如何重置密码？”，系统返回了“如何导出数据？”。我一度怀疑Milvus是不是装错了版本。
后来发现，问题出在embedding模型。我用的默认sentence-transformers/all-MiniLM-L6-v2，在中文场景下表现一般。换成BAAI/bge-large-zh后，召回率肉眼可见提升。
| Embedding 模型 | 中文问答召回率（Top-3） | 推理速度（QPS） |
|---|---|---|
| all-MiniLM-L6-v2 | 62% | 120 |
| bge-large-zh | 89% | 45 |
虽然速度慢了，但准确率提升值得。毕竟，用户宁愿等两秒，也不愿看到错误答案。
坑3：Prompt工程，玄学中的科学
即使检索到了正确片段，模型还是经常“自由发挥”。比如用户问“能导出Excel吗？”，检索到“支持CSV导出”，但模型回答“目前不支持任何格式导出”。
我这才意识到，prompt的设计决定了RAG的天花板。最终我用了带约束的模板：
你是一个专业的SaaS客服助手。请严格根据以下上下文回答问题。
如果上下文无法回答，请说“抱歉，我暂时无法回答这个问题”。
不要编造信息，不要添加解释。
上下文：
{context_str}
问题：
{query_str}
回答：
加上这条“紧箍咒”，幻觉率直降80%。
跳槽不是逃命，是升级装备
就在上周，我用这个RAG demo面了一家二线城市的新公司。面试官是位CTO，看了我的GitHub repo后，直接问：“你是怎么解决中文长尾问题的？”
我如实相告：没有银弹，只有不断迭代。从数据清洗到模型选型，再到prompt调优，每一步都是试错。但正是这些“脏活累活”，让我对RAG的理解从“听说过”变成了“能落地”。
更意外的是，对方开的薪资比我预期高了30%。理由很简单：“会用大模型的人很多，但能把RAG在生产环境跑稳的，不多。”
代码人生，从来不是直线
回头看这段经历，我最大的感悟是：裁员潮不可怕，可怕的是在浪潮来临时，发现自己还在用十年前的渔网。
作为三线城市的技术负责人，我曾以为“稳定”就是护城河。但技术世界没有永恒的安稳，只有持续的进化。RAG对我而言，不只是一个技术方案，更是一次认知升级——它逼我走出舒适区，去理解AI时代的工程范式。
现在，我每天依然八点开工，但不再只是修Bug、改需求。我会花一小时读论文，试新工具，甚至给开源项目提PR。不是为了“卷”，而是明白了一个道理：你的代码人生，由你写的每一行决定，而不是由你所在的城市决定。
给同样在“边缘”奋斗的你
如果你也在小城市、小公司，正焦虑着未来的方向，分享几点真心话：
- 别迷信“大厂光环”：很多一线大厂的螺丝钉，技术深度还不如你。关键是你是否解决了真实问题。
- RAG是很好的切入点：不需要GPU集群，一台16G内存的笔记本就能跑通全流程。而且企业级需求明确，容易做出成果。
- 把工作当练兵场：哪怕公司不用AI，你也可以用内部文档做RAG实验。我现在的demo，就是拿公司帮助中心练手的。
- 输出倒逼输入：写博客、录视频、做分享。我在知乎发的RAG踩坑笔记，意外引来两个猎头。
最后，送自己也送你一句：潮水退去时，裸泳的人才会慌。而真正的程序员，永远在造自己的船。
附：我的RAG学习路径（亲测有效）
- 入门：LlamaIndex官方文档（别看英文劝退，代码示例超清晰）
- 中文优化：重点研究
bge系列 embedding 模型- 部署：用 Docker 一键启动 Milvus，别自己编译
- 调试技巧：务必记录每次 query 的检索结果和生成答案，建立评估集
记住：RAG不是替代你，而是放大你的专业价值。你懂业务，懂数据，这才是AI时代最稀缺的能力。
评论 0