先想清楚：你的数据到底需不需要RAG？
搭RAG系统前，先问个最实际的问题：你的知识库，多久更新一次？
如果数据源相对稳定，比如产品手册、历史合同，半年甚至一年才更新一次，那投入大量精力做向量数据库、Embedding模型调优、分块策略，性价比可能很低。一个精心设计的提示词工程，加上合理的上下文管理，效果不一定差。
RAG的真正价值在于实时检索——从海量、非结构化、频繁变化的数据里，抓出最相关的片段。深圳有家支付公司想用RAG检索内部风控规则文档，测完发现规则库虽大，但核心逻辑变化慢。他们最终只在处理非结构化的客诉邮件时，才做实时检索增强，初期开发成本省了约40%，响应也更快。
快速判断： 你的数据源是不是每月都有大量新增或修改？信息是不是散落在PDF、邮件、会议记录等各种格式里？用户问题是否高度依赖特定、不连续的片段？如果三个里有两个是“是”，RAG值得投。否则，先优化提示词。
Agent的自主权：你想让它当员工，还是当工具？
搭Agent的门槛不高，但“自主权”设计是最容易踩的坑。很多团队一上来就想造能自动规划、调用工具、自我纠错的“全能员工”，结果往往陷入调试泥潭，成本飙升。
更稳的路径是从工具做起，逐步放权：
- 第一阶段：确定性流程Agent。 执行步骤固定的简单任务，比如查订单。接到指令后，固定调API、格式化信息、用固定话术回复。几乎不需要“思考”，出错率极低，能立刻替代重复人力。
- 第二阶段：有限决策Agent。 在流程里加决策点。比如客服Agent处理退款，可以根据退款原因和用户信誉分，决定是直接同意还是转人工。这里用的是规则和分类模型，不是大模型的自由推理。
- 第三阶段：自主规划Agent。 只有前两阶段跑稳了，积累了足够多的成功失败案例，才该考虑引入有长期记忆和复杂规划能力的Agent。这类Agent的测试调试周期，至少要预留前两阶段的3倍。 我们实测过一些快速搭建的自主Agent，真实业务中面对模糊指令或意外情况，超过40%的对话最终需要人工接管。
关键问题： Agent可以犯多大的错？退款上限多少？什么情况必须转人工？这些安全护栏的设计，比让Agent更“聪明”重要得多。
微调：你是要改风格，还是补精度？
这一步最容易烧钱，也最容易见效，但方向错了，投入就是打水漂。
补精度，是模型在特定领域表现不行。比如通用大模型读医学影像报告，术语准确率可能只有70%；分析特定行业财务报表，容易漏关键指标。这时需要高质量、带专业标注的数据集做监督微调，目标是提升特定任务的准确性。这通常需要数万条高质量数据。
改风格，是模型能力没问题，但输出不符合你的品牌调性或用户习惯。比如想让AI客服回复更口语化，或者法律AI生成的文书要更严谨。这种情况用LoRA等参数高效微调技术，配合几千条“风格示范”数据，往往就能见效，成本远低于全参数微调。
一个重要的成本认知：算上数据标注、持续优化和人工复核，AI项目的实际收益可能只有预期的68%。微调不是一锤子买卖，数据迭代和模型版本管理需要持续预算。
实战建议： 先用少量样本测试基座模型，搞清问题是精度不足还是风格不匹配。然后从LoRA微调开始，用3000-5000条数据快速验证，再决定是否加码。最后一定建立反馈闭环，收集用户对输出的评价（比如点赞点踩），这是下一轮微调最宝贵的原料。
一个更稳的组合：RAG + 轻量微调 + 有限Agent
对大多数中小团队和垂直场景，更稳的技术选型可能不是三选一，而是组合拳：
- 用RAG解决知识新鲜度，把最新的产品信息、政策法规、客户资料实时注入模型。
- 用轻量微调塑造输出风格和提升特定任务精度，让模型更懂“你的业务”该怎么说、怎么做。
- 用有限自主权的Agent串联流程，让它可靠地完成查询、检索、生成、执行的一连串动作，并在关键节点设人工检查点。
这个架构平衡了效果、成本和可控性。动手前先问自己：要解决的具体业务问题是什么？成功的量化指标是什么？预算能支撑多久的试错？
想清楚这三件事，技术选型才不会跑偏。
