RAG 知识增强问答平台

背景与问题

企业知识分散在 PDF、Word、PPT、Excel 与扫描件中，纯向量检索在专业术语、长文档和实体关系上召回不稳定；答案无法追溯、知识更新成本高，导致知识问答容易停留在演示阶段。

我的角色

作为研发型 AI 产品经理，负责问题定义、产品架构、检索链路、权限边界、效果指标、Roadmap 与验收；算法调优、工程实现和业务接入由算法、前后端与业务团队共同完成。

约束与取舍

• 纯向量、BM25 还是混合检索：纯向量更擅长语义相似，但专业实体和精确词组容易漏召回；BM25 对实体更稳定，却难覆盖同义表达。最终选择双路召回与 RRF 融合，代价是链路与调参复杂度上升。
• 所有结果都 Rerank 还是按场景控制：统一 Rerank 便于保证排序质量，但增加模型成本和响应时延。最终把候选数量、Rerank 和图谱增强做成知识库级策略，允许业务按准确性与时延取舍。
• 依赖人工体感还是建立评测集：快速人工试答适合 POC，却不能稳定回归。最终引入 Golden Dataset、RAGAS 和 Bad Case 运营，接受持续维护数据集的成本。
• 验证方式：分别观察检索召回、引用有效性、阶段耗时与业务接入，而不是只用最终回答的主观“像不像”判断效果。

产品方案

设计文档解析、OCR 清洗、语义分块、Embedding、向量与 BM25 双路召回、RRF 融合、Rerank、知识图谱增强、答案引用和 RAGAS 评测链路；补齐三级 API Key、按知识库开关策略、阶段耗时与 Bad Case 运营能力。

结果与证据

• 团队技术结果：项目评测中长文档召回率提升约 40%，并形成混合检索、引用和批量评测闭环。
• 平台业务结果：日均请求 12,000+，接入 10+ 企业业务场景。
• 产品结果：文档接入、权限、阶段耗时、RAGAS 与 Bad Case 进入同一运营工作台；未公开测试环境的时延数字不用于跨系统比较。

局限与下一步

现有评测更偏长文档和已接入场景，对表格、扫描件、频繁更新知识和跨库权限的覆盖仍不足；知识纠错也依赖运营人员主动发现。下一步应扩展分类型 Golden Dataset，并追踪知识更新时间、无答案率、转人工和人工修订成本。