企业做知识系统落地时，经常陷入两种“极端”：
- 只做 RAG：成本可控、更新方便，但遇到跨段推理、长文一致性、复杂归纳时效果不稳。
- 只靠长上下文：能把整本手册/整份合同“塞进去”，但成本、延迟、权限隔离、可维护性压力会迅速放大。
更现实、也更容易规模化的路线是：RAG 负责“找准内容”，长上下文负责“深度推理与一致性”。本文给出一套更偏工程化、可审核、安全表达的企业级架构解析，并附上“文字版架构图 + 可复制的 Mermaid 图”。
1. 业务目标与边界
企业级知识系统通常追求四个指标：
- 可用：命中率与回答稳定性
- 可控：成本、延迟、并发有治理手段
- 可管：权限隔离、审计可追溯
- 可演进：文档更新、索引更新、模型升级不“牵一发而动全身”
落地原则建议一句话概括：
检索把“范围”缩小，长上下文把“推理”做深；系统把“治理”补齐。
2. 为什么要“协同”而不是“二选一”
2.1 RAG 擅长的事
- 知识更新频繁（制度、FAQ、产品文档）
- 需要可追溯引用（回答必须能指到来源）
- 成本与延迟要可控（检索+少量上下文）
2.2 长上下文擅长的事
- 长文全局一致性（合同/规范/手册）
- 跨章节归纳与冲突消解
- 多轮复杂任务（分析→对比→总结→输出结构）
2.3 协同带来的收益
- 更少“塞全文”：用检索把候选材料压缩到“少而准”
- 更强一致性：对关键段落做深度推理、跨段整合
- 更好治理：检索与上下文注入点更容易被审计、被限流、被缓存
3. 架构图
下面是一套“企业级知识系统（RAG + 长上下文）”的分层架构，强调：路由、治理、可观测与安全边界。
4. 关键模块设计要点
4.1 策略路由：什么时候用 RAG，什么时候用长上下文？
建议做一个“轻量可解释”的路由策略：
- RAG 优先：问答型、查条款、找定义、找流程
- 长上下文增强：需要跨章节总结、冲突消解、长文归纳
- 混合模式：先检索收敛范围，再把“关键片段 + 必要上下文”交给长上下文深推理
工程上不要把“全文喂给模型”当默认路径，把它当“升级路径”。
4.2 上下文构建：别把“多”当成“好”
长上下文不是越长越好，建议引入 Context Pack 概念：
- 片段去重（同义段落合并）
- 章节排序（按目录结构或引用关系）
- 片段压缩（对非关键段做摘要压缩）
- 引用绑定（每段带来源ID，便于审计与回溯）
4.3 成本与延迟治理：企业落地绕不开
三件事就够用、也好落地：
- Token 预算器：每次请求给出上限，超了就缩片段或降级
- 分层模型策略：简单问题走轻量模型，复杂问题再升级
- 缓存：片段缓存 + 问答缓存（对高频内部问题很有效）
4.4 权限与审计：知识系统必须“可管”
- 租户隔离（部门/项目空间）
- 文档访问权限（ACL）在检索阶段就要生效
- 全链路审计：检索结果、注入片段、提示版本、模型版本可回溯
5. 推荐落地路径（从0到1更稳）
- 先做可用的 RAG：把“可引用、可更新、可追溯”跑通
- 再引入长上下文增强：只对“复杂问题/长文任务”开放升级
- 补齐治理能力：成本、限流、审计、可观测
- 最后做自动路由：把经验策略固化为可配置规则
结语
长上下文能力提升并不等价于“抛弃 RAG”。对于企业级知识系统，更可行的路线是：用 RAG 控范围，用长上下文做深推理，用治理能力保证可控与可管。当系统具备清晰的路由策略、可观测与审计能力后，模型能力才能稳定转化为业务能力。
