1. 课程导入与全景认知

在工程项目管理与企业数字化实践中，知识往往散落在施工方案、技术交底、变更签证、验收记录、标准规范、会议纪要和历史项目复盘之中。传统检索依赖关键词匹配，工程师输入“地下室顶板裂缝处理”，系统可能只返回包含“裂缝”二字的文档，却无法理解“顶板”“处理措施”“责任归属”之间的语义关联。本课程要解决的核心问题，就是如何把这些非结构化、多来源、强专业性的工程知识，组织成可检索、可追溯、可生成答案的知识库，并用RAG（Retrieval-Augmented Generation，检索增强生成）技术让大模型“有据可依”地回答工程问题。

学习目标可以概括为四个层次：第一，理解工程项目知识库的基本概念、数据边界与业务价值；第二，掌握RAG的核心链路，包括文档解析、切分、向量化、索引、召回、重排与生成；第三，能够针对工程场景设计可落地的知识库结构，例如按专业、阶段、文档类型和项目实体建立元数据；第四，具备基本的评估与排障能力，能判断“答不准”是召回问题、切分问题还是生成问题。技术栈边界也需要明确：RAG不是替代大模型训练，也不是简单的全文检索，它位于“企业私有知识”与“通用大模型能力”之间，承担知识注入与事实约束的角色。

整体实施路线可以按“知识源治理→文档解析与切分→向量化与索引→检索与重排→生成与引用→评估与迭代”六个阶段推进。每个阶段都有工程专属的难点。例如，施工方案PDF常包含大量表格、扫描件和CAD截图，直接文本抽取会丢失行列关系；技术交底记录口语化严重，切分过细会丢失上下文，切分过粗会引入噪声。因此，切分策略不能只用固定字数，而应结合标题层级、条款编号和语义段落。元数据设计也要贴近工程习惯，至少包括：项目名称、单位工程、分部工程、文档类型、专业类别、审批状态、生效日期、版本号。这些字段决定了后续能否按“项目+专业+阶段”过滤召回。

为了更直观地理解RAG在工程知识库中的位置与数据流向，下面用一张信号链式架构图展示从知识源到答案输出的完整链路。图中左侧是工程知识源，中间是RAG处理管线，右侧是用户交互与反馈闭环。注意图中“元数据过滤”与“重排”是两个容易被忽略但直接影响准确率的环节。

从图中可以看到，RAG不是单点技术，而是一条从知识源到答案的完整信号链。左侧知识源的多样性决定了中间处理管线的复杂度，右侧用户反馈又反向驱动知识库迭代。对于工程项目而言，最需要优先投入的往往不是模型选型，而是知识源治理与元数据设计。一个常见的失败案例是：企业直接把几百份PDF丢进向量库，不做表格还原和元数据标注，结果用户问“3号楼地下室防水等级”，系统召回了一堆其他楼栋的防水做法，答案看似合理却张冠李戴。解决方式是在切分时保留“楼栋号、楼层、专业”等字段，并在召回阶段做元数据过滤。

本课程后续将围绕这条链路逐层展开。你需要带着三个问题学习每一节：第一，这个环节的输入是什么、输出是什么；第二，工程场景下有哪些特殊约束；第三，如何判断它是否工作正常。例如，切分环节的输入是解析后的文本块，输出是带元数据的chunk；判断标准可以是“随机抽取20个chunk，检查是否包含完整条款或完整工序描述”。只有把每个环节的可观测指标建立起来，RAG系统才能从“演示可用”走向“工程可信”。