4. 知识库总体架构设计

知识库总体架构设计的核心任务，是把“原始工程资料”变成“可被大模型稳定调用的知识服务”，并让每一层职责清晰、接口明确、数据流向可追踪。对于工程项目知识库而言，资料形态复杂——PDF 图纸说明、Word 施工方案、Excel 清单、扫描件、验收记录、规范条文、会议纪要等并存，因此不能把 RAG 简单理解成“向量库 + 大模型”，而应设计为分层架构：数据层、知识加工层、检索层、生成层、应用层。RAG 并非独立一层，而是横跨“知识加工—检索—生成”的主链路，是连接知识与回答的桥梁。

一、五层架构的职责边界

数据层解决“知识从哪里来”。它负责接入工程项目的多源异构数据：设计文件、施工组织设计、专项方案、技术交底、变更签证、质量验收记录、安全台账、规范标准、企业知识库等。数据层不直接面向大模型，而是面向加工层提供稳定、可追溯的原始数据。关键设计是保留来源标识：每个文件应有唯一 doc_id，每个段落应有 chunk_id，并记录项目名称、专业、版本、日期、密级等元数据。例如某地铁项目知识库中，一份《盾构始发专项施工方案》可标记为：project=“XX地铁5号线”、discipline=“盾构”、doc_type=“专项方案”、version=“V2.1”、date=“2024-03-12”。这些元数据后续会成为检索过滤的重要条件。

知识加工层解决“知识如何变成可检索单元”。它包含解析、清洗、切分、向量化、索引构建等环节。工程文档常见问题包括：PDF 双栏排版、表格跨页、扫描件无文字层、图纸说明与图号混排。因此加工层需要先做 OCR 与版面分析，再按语义切分。切分策略不能只按固定字数，而应结合工程语义：规范条文按“条—款—项”切分，施工方案按“章节—工序—参数”切分，验收记录按“检验批—主控项目—一般项目”切分。切分后生成 chunk，并写入向量库与关键词索引，形成“向量 + 全文 + 元数据”的混合索引。

检索层解决“如何找到最相关的知识”。工程问答中，用户可能问“盾构始发端头加固范围是多少”，也可能问“XX 项目上次检查发现的临边防护问题整改要求是什么”。前者偏规范知识，后者偏项目实例。因此检索层应采用混合检索：向量检索负责语义相似，BM25 负责关键词精确匹配，元数据过滤负责限定项目、专业、版本。检索结果需经过重排，按相关性、时效性、权威性排序，并保留引用来源。检索层输出的是“候选知识片段 + 来源 + 置信度”，而不是直接给答案。

生成层解决“如何基于知识生成可信回答”。大模型接收用户问题与检索片段，按提示词约束生成答案。工程场景必须强调可追溯与拒答：答案应标注引用来源，无法从知识库找到依据时应明确说明“未检索到相关依据”，而不是编造。生成层还需处理多轮对话、上下文压缩、引用编号映射等。例如回答中写“依据《XX地铁5号线盾构始发专项方案》V2.1 第4.2节”，并附 chunk_id，便于用户回查原文。

应用层解决“知识如何被使用”。它面向不同角色提供入口：施工员查工艺参数、安全员查隐患依据、项目经理查变更影响、新员工做知识培训。应用层可以是问答机器人、知识检索门户、智能审查助手、培训考核系统等。应用层不直接访问原始文件，而是通过统一 API 调用检索与生成服务，保证权限、审计与版本控制。

二、RAG 在架构中的位置与数据流向

RAG 位于知识加工层与生成层之间，并依赖检索层完成知识召回。其数据流向可概括为两条链路：离线加工链路与在线问答链路。离线链路：原始文件 → 解析清洗 → 语义切分 → 向量化 → 索引写入。在线链路：用户问题 → 查询改写 → 混合检索 → 重排 → 提示词组装 → 大模型生成 → 答案与引用返回。两条链路通过索引库交汇，索引库是 RAG 的“知识底座”。

三、关键设计要点与示例参数

在工程知识库中，分层架构能否落地，取决于几个关键参数与策略。以下以某地铁项目知识库为例，给出可参考的示例配置（属于合理假设，非实测结果）：

需要特别强调的是，RAG 不是架构中的某一层，而是贯穿加工、检索、生成的主链路。数据层为 RAG 提供原料，应用层消费 RAG 的输出。若把 RAG 误认为“只属于检索层”，就会忽略加工层的切分质量与生成层的引用约束，导致“检索到了但答不准”或“答得流畅但无依据”。

综上，五层架构的价值在于“各司其职、数据可追踪、RAG 可替换”。数据层保证来源可信，加工层保证知识可检索，检索层保证召回精准，生成层保证回答有据，应用层保证场景落地。设计时不必追求一次到位，但必须先把元数据规范、切分策略与引用机制确定下来，再逐步优化向量模型与重排策略，才能让知识库在工程项目中真正发挥作用。