选开源 RAG 组件，不要先问哪个好：先问谁负责哪一层

先把社区当成真实工程现场

开源项目不是素材库，也不是热词来源。需要认真处理的学习的是维护者如何处理问题、如何设计版本、如何接受贡献、如何暴露边界。 观察对象应放到 issue、release、文档、测试和许可证这些能被读者自己验证的地方。

开源 RAG 选型的第一步，更要看拆清楚每个组件到底负责哪一层。

把一个框架当成全部架构，会让替换、调优和排错变困难。

从现场问题开始

团队同时试了多个 RAG 框架，每个 demo 都能跑；真正接企业数据后，解析、索引、权限、检索、重排、评测和审计边界全混在一起。

解析层负责把资料变成结构

PDF、Word、图片、网页、表格、代码仓库都需要不同解析策略。解析质量会直接影响后续检索，不应被框架默认值吞掉。

索引层负责可检索对象

全文索引和向量库各有优势。字段过滤、精确词、高亮、语义相似、元数据 payload 要按任务拆分。

编排层负责流程而非魔法

编排框架可以连接解析、检索、重排、模型和工具，但不能替代权限设计、数据治理和评测。

评测层负责持续比较

没有评测工具，组件选型会变成主观感受。每次替换 embedding、reranker 或模型，都应跑同一批问题。

可复刻实验片段

parser:
 responsibility: normalize documents and preserve source structure
index:
 keyword: elasticsearch
 vector: qdrant
retriever:
 filters: [tenant_id, acl, open_state]
 reranker: bge-reranker
generator:
 model_service: local-or-private-api
evaluation:
 metrics: [citation_hit_rate, refusal_accuracy, acl_block_rate]

架构评审要保留替换空间

架构更要看让关键层能够被替换、比较和回退。 RAG 组件责任矩阵 应该写清每一层的输入输出和责任边界。 这样未来换模型、换向量库、换解析器或换编排框架时，不会牵一发动全身。

先画责任矩阵，再比较 Star

一个更稳的判断是先问三件事：系统到底处理了哪些对象，对象状态由谁确认，出现异常后有没有证据能回到原始材料。围绕 开源 RAG 组件选型，最需要提前写清的对象包括：文档解析、切片、向量化、索引、权限过滤、检索编排、模型调用、评测、日志和管理界面。这些对象不一定都要做成复杂系统，但必须在数据结构、接口、表格或日志里有位置。

常见误区是用一个开源项目解决全部 RAG 问题。它看起来节省时间，实际上会把风险推迟到更难处理的阶段。到那时，开发人员已经按旧字段写完接口，业务人员已经按旧口径组织材料，运维人员只能面对一堆没有上下文的截图和文件夹。

开源框架负责流程，不负责你的业务口径

这张表不需要写进所有对外方案，但项目内部必须有人拿它逐项核。尤其是涉及高水平数字档案馆、数字档案室或智能应用的内容，不能把 AI、机器人、检索、展示当成替代基础能力的捷径。它们最多是增强层，基础仍然是归档、检测、资源、权限、安全、长期保存和人工复核。

许可证和运维成本要提前进入选型

很多项目只保留成功样本，这是后期返工的来源。开源 RAG 组件选型 至少要准备一组反例：权限不允许、状态不完整、对象不存在、日志缺失、校验失败、人工复核未通过。反例用于确认系统边界，避免错误路径被当作正常能力。

验收或自测时，可以把指标写得更硬一些：每层组件都有输入输出、失败边界、替换方案和许可证结论；不能把权限和证据回跳外包给演示框架。这类指标比“功能正常”“界面友好”更有价值，因为它能让项目团队知道问题出在数据、流程、接口、模型还是人员复核。

反例还应该进入后续运维。新增一批数据、调整一次规则、替换一个组件、升级一个模型，都要用旧反例复测。只要旧反例开始通过错误路径，说明系统边界已经被改坏。这个动作看似笨，但能避免很多演示顺利、上线失控的问题。

组件能替换，数据结构不能随意换

开源 RAG 组件选型 最后要回到真实工作分工。架构人员确认分层，法务或管理人员确认许可证，开发人员确认替换成本和日志能力。如果一件事只能由写代码的人解释，说明它还没有进入组织能力；如果一件事只能由业务人员口头确认，说明它还没有进入系统证据；如果一件事只能靠验收前补材料，说明平时运行没有沉淀。

领至科技在这类项目里更愿意先把证据链拉直，再讨论智能化程度。因为智能能力越强，越需要解释它依据了什么、排除了什么、谁复核过、出了错如何回滚。没有这些边界，所谓效率提升很容易变成风险加速。

开源组件先按责任分层

RAG 项目常见争论是“哪个框架最好”。更有用的问题是：文档解析谁负责，切片谁负责，向量化谁负责，索引谁负责，权限谁负责，证据回跳谁负责，评测谁负责。一个框架可能覆盖几层，但很少能替你解决全部业务责任。

先做责任矩阵，再看组件。比如 Unstructured 或自写解析负责文档结构，Qdrant/Elasticsearch 负责召回，FastAPI 负责服务合同，评测脚本负责回归，业务系统负责权限和审计。每层输入输出清楚，组件才可替换。

Star 数不能替代维护判断

开源项目要看的不只是 Star。更重要的是最近 release、issue 响应、破坏性变更、许可证、文档质量、测试覆盖和社区讨论。一个 Star 很高但半年不维护的组件，可能不适合放进长期项目。

读 issue 能看到真实边界：哪些格式经常解析失败，哪些版本升级容易破坏 API，哪些部署方式文档不足。读 release 能看到维护者的节奏。读许可证能判断能否商用和再分发。读 CI 能判断项目是否重视稳定性。

业务数据结构要独立于框架

框架可以换，档案证据结构不能跟着随意换。archive_id、component_id、page_no、bbox、open_state、source_url 这些字段应由业务系统定义，而不是让某个 RAG 框架的默认 Document 结构决定。

如果一开始就把所有字段塞进框架私有对象，后续迁移成本会很高。更稳的是保留自己的证据表和接口合同，开源组件只负责它擅长的一层。这样项目既能利用社区能力，又不会被某个框架锁死。

fork 之前先问维护成本

采用开源组件时，有时需要 fork 修补。但 fork 不是免费的。谁跟进上游更新，谁处理安全漏洞，谁解决冲突，谁维护内部文档，都要提前想清楚。

如果团队没有维护能力，更适合提交 PR 给上游，或把改动限制在适配层。开源更要看把责任从购买许可证转成理解社区和维护工程边界。

项目里最容易漏掉的一页纸

这页纸的价值，是让不同角色在同一张桌上说同一种话。档案人员看到的是业务口径，开发人员看到的是字段和接口，运维人员看到的是日志和恢复，项目负责人看到的是风险和优先级。只要四类人还在各说各话，系统就很难真正稳定。

实际推进时，可以把这页纸做成三段。第一段写“本次处理的对象是什么”，不要用笼统名词。第二段写“哪些情况不能自动通过”，把失败分支列出来。第三段写“验收或复盘时看什么证据”，明确日志、表格、截图、原文、工单或报告的位置。

如果一篇文章读完以后，项目组能多出这样一页纸，它就不是泛泛观点。它会进入需求评审、接口联调、验收准备和运维交接。领至科技后续做数字档案馆、数字档案室、AI 检索、机器人和开源社区内容，也会尽量把观点压到这种能被复用的材料上。

判断成熟度，看它能不能被别人接手

一个能力是否成熟，不看演示人员讲得多熟，而看换一个人能不能接手。换一个档案人员，是否知道怎么抽查；换一个开发人员，是否知道字段从哪里来；换一个运维人员，是否知道异常去哪查；换一个负责人，是否知道下一笔预算该投在哪里。

接手能力来自文档、数据和日志。只有文档没有数据，系统会变成纸面合规；只有数据没有日志，异常无法复盘；只有日志没有业务解释，项目负责人看不懂风险。三者合在一起，才算进入可运营状态。

业务数据结构要独立于框架

框架可以换，档案证据结构不能跟着随意换。archive_id、component_id、page_no、bbox、open_state、source_url 这些字段应由业务系统定义，而不是让某个 RAG 框架的默认 Document 结构决定。

如果一开始就把所有字段塞进框架私有对象，后续迁移成本会很高。更稳的是保留自己的证据表和接口合同，开源组件只负责它擅长的一层。这样项目既能使用社区能力，又不会被某个框架锁死。

许可证和部署方式要一起看

开源选型还要把许可证、部署方式和数据边界放在一起看。某些组件适合云端托管，某些组件适合内网部署，某些组件的许可证会影响商用和二次分发。技术 demo 能跑，不代表交付形态合规。

选型记录里应写清：组件用途、许可证、是否修改源码、是否外连服务、是否处理敏感数据、谁负责升级。这样后续维护不会只依赖当时做 demo 的人。

开源组件要准备退出方案

选型时还要问一句：如果这个组件明年不维护了，怎么退出。退出方案包括数据能否导出、接口能否替换、配置是否可迁移、许可证是否允许保留内部修改。

有退出方案，采用开源才会更从容。没有退出方案，短期 demo 越快，长期绑定越深。