构建 RAG 系统并非千篇一律，盲目套用“分块、嵌入、向量检索”的经典流程往往导致资源浪费或效果不佳。真正的关键在于根据文档的复杂度和问题的控制度进行精准诊断。 文档复杂度从固定模板到视觉丰富型分为五个层级。在固定模板场景下，如保险证书或税务申报，所有文件结构一致，直接使用正则表达式提取字段最为高效，使用大模型反而多余。而在视觉丰富型场景，如包含图表的工程蓝图或幻灯片，纯文本解析无法获取核心信息，必须引入视觉模型。对于结构多变的非结构化文档，则需结合目录检索与混合搜索。 问题控制度同样决定技术方案。若问题由工程师预设（如提取特定日期），属于确定性任务，无需复杂解析；若用户可自由提问甚至需要系统追问澄清（如“哪个章节的费用？”），则需构建具备澄清机制的多轮对话流程。将文档维度与问题维度交叉，可形成技术选择地图。左上角区域（固定文档加控制问题）适合规则提取，中间区域（多变文档加自由提问）需完整 RAG 管线，底部区域（视觉内容）则依赖多模态模型。 盲目追求长上下文或高级技术如 HyDE 往往得不偿失。长上下文无法替代精准检索，而虚构查询词汇的技术在缺乏领域词汇表时成本高昂。正确的策略是“用最简单的技术解决问题”，让专家界定系统边界，优先利用现有规则，仅在必要时引入大模型作为兜底。在动手编码前，应先评估文档与问题的实际位置，避免为过度设计买单，确保系统既实用又经济。