当我第一次决定做一个RAG应用（Retrieval-Augmented Generation），心里是兴奋的。检索增强生成——听起来多么高大上！我设想它能像知识问答超人一样，从海量资料中抽取关键信息，再让大语言模型灵活组织输出。于是我开始了一场“完美架构”的堆叠：多层服务、复杂管线、繁琐缓存、花哨检索、动态提示词系统……结果？模型输出不如最初的demo版本。
说实话，那一刻挺打击人的。
我把所有“工程化的理想”都塞进去了：
各层服务模块化到几乎无法直视的程度。
检索部分加了语义相似度筛选、内容评分、多源融合。
生成部分设计了“上下文自适应提示词系统”，能动态拼装 prompt。
甚至还搞了一个“章节级分片逻辑”，把长文拆成碎片再聚合。
看似科学，实则灾难。模型输出的内容要么啰嗦、要么断裂，要么“聪明反被聪明误”。我忙着让系统“更智能”，结果它连最基本的连贯都丢了。
问题出在哪？我开始反思。
一开始我以为是embedding模型不匹配，换了几个；又怀疑向量库召回精度不够，调了半天阈值；甚至怀疑是LLM的temperature太高，改成0.2还是一样。直到有一天，我把所有复杂逻辑关掉，只留下最简单的几步——上传知识 → 检索片段 → 拼接上下文 → 提问生成。结果模型的回答，突然流畅又准确。
那一刻我愣住了。
原来是我自己把模型“弄笨了”。
我后来总结出一种很真实的经验：RAG不是为了复杂，而是为了让模型“理解”上下文。
而我做的那些多层抽象、繁琐管控，其实让上下文变得支离破碎。模型读到的是一个格式化后的碎片集合，而不是一段有机的语义流。你给它再多工具，它也“读不懂你的心”。
于是我重构了整个架构。删掉了三分之二的中间层，保留最关键的两步：
1. 高质量文本整理：不做切片拼接，只在逻辑断点处切分，让每个片段自成语义单元。
2. 轻量化Prompt注入：不追求炫技提示，而是让模型自然地“读懂”资料。
同时，我给团队定下一个简单原则：
> “任何一行代码、一个功能、一个参数，如果不能显著提高生成质量，就不要加。”
这句话听起来像鸡汤，但它真的救了整个项目。
删掉多余逻辑后，模型输出不仅更连贯，而且更“贴题”。以前那种“明明内容都有但就是答不对”的情况几乎消失了。我们反而能集中精力在真正重要的环节——知识质量与上下文语义。
现在回头看，我发现所谓“过度工程化”，其实是焦虑的产物。
我们总担心：如果不多做点功能，别人会说我们不专业；如果架构不够花哨，就显得技术不够“AI”；如果不加点自动优化机制，就好像没用上“智能”。
但真相是：AI开发最大的陷阱，就是试图把“复杂”当作“聪明”。
RAG项目尤其如此。
它的本质不是让模型会推理，而是让模型看得懂资料、答得出问题。
这件事的核心不在架构，而在内容。
与其写十个过滤算法，不如花时间清洗知识库；与其堆规则，不如让prompt更直白；与其追求动态优化，不如先确保静态版本真的好用。
当我彻底接受“少即是多”之后，整个团队的开发节奏也变了。以前一周做三个功能，现在一周只优化一个场景。结果使用体验反而更稳定。RAG成了一个“可靠的工具”，而不是“有时灵、有时傻”的黑箱。
有一次我在复盘时写下这样一句话：
> “RAG不是让机器看懂世界，而是让我们自己看清机器该做什么。”
这可能才是这次开发最大的收获。
技术的尽头不是复杂，而是清晰。
而清晰的前提，是学会放下那些看似聪明、实则徒劳的“工程美学”。
这次RAG开发让我明白，真正的智能，不在代码的层数，而在你能否识别真正有用的那一层。
我从过度工程化中走出来了。
也许下次再写架构，我会先问自己一句：
> “如果不做这个，它会变得更糟吗？”
如果答案是否，那就删。
这就是我这段时间最真实的开发日记——从复杂走向简单，从技术狂热回归理性。
少即是多。
网友评论