RAG与微调并不是二选一的“大模型增强方案”，而是分别解决两类不同问题：RAG解决“模型需要查什么”，微调解决“模型应该如何表达和执行”。企业在选型时，若把不断变化的内部知识直接写进模型参数，维护成本和信息时效性都会成为问题；若试图仅靠检索解决固定话术、输出格式或复杂业务习惯，效果也往往不稳定。
RAG适合补充知识
RAG的核心是先从企业知识库中检索相关内容，再交给模型生成回答。它更适合制度查询、内部知识库问答、文档助手等场景，尤其适用于知识规模较大、内容持续更新、答案需要追溯依据的业务。
RAG的优势在于迭代成本较低。企业更新文档、调整知识库或改变权限范围后，通常不必重新训练模型。但RAG并非“接入文档就准确”：文档清洗、切片、权限隔离和检索质量都会直接影响结果。知识库内容混乱，或者检索到的片段与问题不匹配，模型仍可能生成不可靠答案。
微调适合改变行为
轻量化微调更适合解决表达和行为层面的问题，例如统一企业话术、适配专业术语、固定输出格式，或让模型更稳定地遵循特定业务逻辑。源材料明确提到，LoRA、QLoRA可用于参数级调优，但这类技术不应被当作企业知识库的替代品。
如果目标是让模型掌握经常变化的制度、产品信息或业务数据，优先考虑RAG；如果目标是让模型长期保持某种风格、格式和处理习惯，微调更有针对性。把频繁变动的信息固化到参数中，会增加更新与验证负担；把稳定行为完全寄托于提示词，又可能难以保持一致性。
实际项目通常采用组合策略
较稳妥的架构是“RAG提供事实，微调约束行为，智能体编排负责执行”。例如，模型通过RAG读取企业制度，再按照微调形成的审查格式输出，最后由智能体调用业务系统完成流程。涉及金融、医疗、政务、制造等场景时，还应同步配置权限控制、日志审计和输出过滤，确保模型只访问授权知识。
判断边界时，不妨先问两个问题：变化的是“内容”，还是“行为”？前者优先RAG，后者优先微调；若两者同时存在，就应组合使用，而不是期待单一技术解决全部问题。