从表格到知识库：把工程属性变成可检索的数据

工程现场最常见的知识载体不是长篇制度，而是仪表索引表、设备数据表和材料清单。它们信息密度高，却很难被普通 RAG 正确理解：同一个位号分布在多张表中，字段和值依赖行列关系，用户还会以“某设备的设计温度是多少”这样的自然语言提问。

建立统一的数据单元

不要把整份 Excel 或整页 PDF 当作一个文本块。表格解析后的最小业务单元应接近 对象—属性—值—单位—来源：例如 161-P-1001 / 设计压力 / 1.6 / MPa / 文件、页码、单元格。原始行、表头路径、文件版本和模板编号则作为元数据保留。这样既可做语义检索，也可做精确过滤和后续质量校验。

模板与模板实例分离

模板描述字段规则、表头层级、必填项与别名；模板实例描述某一文件的具体坐标和识别结果。二者分离后，一次人工标注可服务同类文件，而修订版带来的变化只影响实例。对于没有匹配模板的新文件，系统应提供标注入口，而不是强行套用最近的模板。

长任务要与交互解耦

文件上传、转图、OCR、表格恢复和向量化都可能耗时。将它们放进一次 HTTP 请求，用户只会得到超时。更适合的方式是：上传时创建文件记录和任务；后台 Worker 分阶段处理；前端通过状态轮询或 SSE 获取进度；失败时记录失败阶段、原始异常和可重试条件。任务幂等性同样重要，重复提交不应产生多份相同数据。

向量库并不是唯一答案

表格知识库通常需要三类存储协同：关系库管理文件、模板、任务和精确字段；向量库负责语义召回；对象存储保存原件、页面图片和解析中间产物。位号、文件编号、专业等强约束字段应优先走关系查询或 metadata 过滤，再把少量候选交给语义检索。

当结构化单元、处理流程和来源证据都被保留后，知识库才不是“上传文件后能聊天”的演示，而是能支撑工程查询与数据积累的基础设施。