RAG 是自行实现还是采用开源组件？

核心回答

我倾向于复用成熟组件，自行实现业务策略与集成。文档加载、切分、Embedding 接入、向量存储和基础编排可以采用现成实现；资料清洗、领域元数据、权限、检索组合、引用和评测，则根据业务需求设计。是否自建某一层，要看现有组件的能力缺口和长期维护成本。

以文档问答为参考，可以用 LangChain 的加载器、切分器和检索接口，连接 Embedding 服务与 Redis 向量存储，再由应用组织检索证据、提示词和答案。这里既有组件复用，也有应用集成，并非整套 RAG 都从零实现。面试时讲清每层输入输出、自己增加的逻辑及选择理由，比只回答“自研”或“调框架”更有信息。

先说明复用的是哪一层

RAG 至少包含数据进入索引与在线回答两段。前者处理文档读取、清洗、切分、向量化和更新；后者处理查询、召回、筛选、上下文和生成。每一层可以采用不同组件，不必绑定一套全包方案。

例如加载器把文件转成文档对象，切分器生成带元数据的块，Embedding 服务计算向量，存储负责索引与查询，应用再决定哪些证据进入模型。若企业已有搜索或知识库服务，也可以直接接入它返回的证据，不一定重新建设向量库。

需要区分组件、模型服务与平台：调用托管 Embedding 是复用模型服务，使用开源切分器是代码依赖，使用知识库平台则可能把文档处理和索引一起交给平台。不能用一个“开源”概括所有实现边界。

哪些工作通常体现项目差异

文档中表格和图片怎样处理，型号、版本与权限怎样进入过滤，精确编号与同义问题怎样同时召回，命中片段怎样补回上下文，资料更新后如何清除旧块，这些都需要业务约定。

应用还要保留原文位置与引用，处理无答案、冲突和超时，并建立失败样本与回归评测。可以在框架扩展点完成，不必为了体现工作量重新实现底层向量索引。反过来，安装一个加载器也不能说明复杂文档和权限问题已经解决。

如果需要比较个人工作，可以沿一次文档更新或一次用户问答，指出哪个模块直接复用、哪个适配层自行开发，以及处理了什么具体问题。例如标题与条件在切分后丢失，就说明如何补结构与验证证据，而不是只列依赖名称。

什么时候值得局部自建

现有组件不能保留必须的结构、过滤语义与系统不匹配，或者扩展方式长期阻碍调试、性能和版本迁移时，可以先替换相应层。对外保留稳定的文档、检索结果和来源接口，降低替换范围。

自建同时意味着维护解析异常、并发、更新一致性和兼容测试。选型要在相同数据、任务、权限与质量要求下比较完成效果、延迟、成本和维护难度。依赖少不自动更可靠，平台功能多也不代表更适合当前需求。

常见追问

直接调用平台，还能讲哪些技术工作？ 可以具体说明数据接入、结构与权限映射、参数选择、服务接入、失败处理和效果评测；如果平台承担了切分与检索，就讲清应用控制哪些配置和逻辑。

什么时候从组件方案迁移？ 先用实际失败样本证明能力缺口，比较配置调整、扩展点与局部替换，验证新旧索引和引用兼容后逐步迁移，不因为出现一个新框架就整体重写。

对应教程

参考资料