版权与内容来源声明
本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容，均在附表 A 中标注来源；引用官方原文保持原样，不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准，标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式，也不对任何收益结果作承诺。转载请注明出处。
第 1 章 你手上的「老师傅语料」，为什么不能直接喂
能源行业的朋友转到 AI 大模型方向时，第一反应往往高度一致：我这儿几十年的巡检记录、故障工单、检修报告、交接班记录，全攒着呢，把这些喂给模型，不就有个永不退休的老师傅了吗？
这个直觉有道理。模型确实擅长从大量文字里提炼规律，而这些非结构化历史文本，正是你单位里最「值钱」的资料——规程、图纸在别处也能查到，但老师傅记在工单里的那些「这台泵一抖就先紧出口阀」的经验，外面买不到。
1.1 先说清楚：这些记录算不算「语料」
「语料」是个外来词，简单说就是喂给模型的原始文字材料。你那份 2015 年的巡检本、去年冬天的故障工单、上个月的交接班记录，落到文件里，对模型而言都是同一类东西：一堆带时间戳的文字。
所以它们当然是语料，而且是高价值语料。问题不在「能不能喂」，而在「怎么喂、喂哪些」。
1.2 直觉的危险：老师傅也会记错、记旧、记岔
老师傅的经验之所以值钱，是因为它经过现场反复验证。但工单里的文字，并不等于经验本身：
- 同一台设备换了三茬人，记录口径早就散了；
- 设备改造过，老办法对现在的设备不灵了，可纸面上看不出来；
- 大量记录只有当事班组懂，外人读着像天书。
直接把几十年的工单整包丢进知识库，相当于让一个新徒弟同时听二十个口音不同、部分说法互相矛盾的老师傅讲课，还不允许他提问。第 2 章就聊聊具体会翻出哪三种车。
第 2 章 直接喂会出三类具体问题
把历史工单不分青红皂白地塞进 RAG（检索增强生成，先这么理解：模型答题前，先从你的资料里找出相关段落再作答）知识库，最常见的是三类问题。
2.1 口径漂移：同一故障，写法打架
「口径漂移」指的是：同一台设备的同一个故障，在不同年代、不同班组笔下，表述并不一致。
举个小例子。某循环水泵出口压力低，2012 年的工单写「出口阀内漏，紧一紧就好」，2020 年的工单写「出口阀阀芯磨损，需更换密封」，2023 年的工单又写「多为出口压力表引压管堵」。三条都对过，可模型分不清哪条是通用结论、哪条是当时特定条件下的判断，于是学到互相矛盾的表述，答出来的东西左右横跳。
表 1 把三类问题摆在一起看。
| 问题 | 典型表现 | 直接后果 |
|---|---|---|
| 口径漂移 | 同一故障跨年代/班组写法不一 | 模型学到矛盾表述，答案不稳定 |
| 时间衰减 | 设备已改造，老办法失效但无标注 | 给出对现设备错误或过时的处理 |
| 噪声与缺失 | 口语、缩写、缺上下文 | 检索命中但无法正确理解 |
2.2 时间衰减：处理方法对现在的设备已作废
「时间衰减」说的是：设备可能已经改造、更换、升级，旧工单里的处理方法对现在的设备不再适用，但语料里没有任何标记说明「这条已过期」。
模型没有时间感。它只知道这条记录和那条记录都在语料里，权重差不多。于是你问「现在这台机组喘振怎么处理」，它很可能把十年前、针对旧型号机组的处置步骤翻出来给你，还讲得头头是道。
2.3 噪声与缺失：只有内部人懂的记录
大量工单是口语化、带内部缩写、缺必要上下文的。比如「三号机那回一样，找老周」——没有设备唯一标识、没有工况、没有日期，外部人或新模型完全无法还原当时场景。这类记录单独看无害，一旦量大，就会变成第 3 章要讲的「干扰项」。
第 3 章 根因：模型把语料当成「扁平的真理」
为什么塞得多反而容易答错？这得回到大模型本身的工作方式，有一手研究可以支撑，不是我随口说。
3.1 上下文腐化：塞得多不等于用得好
Anthropic 在 2025 年 9 月 29 日发布的工程博客《Effective context engineering for AI agents》里，提出两个关键概念（原文照引）：
“as the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases.”（上下文窗口里的 token 越多，模型从中准确回忆信息的能力越下降。）
“LLMs have an ‘attention budget’ that they draw on when parsing large volumes of context. Every new token introduced depletes this budget by some amount…”（大语言模型有一个「注意力预算」，每多一个 token 都在消耗它一点。）
换句话说，模型的「注意力」是有限的，给得越多，单位信息分到的注意力越薄。
同一个方向上，向量数据库厂商 Chroma 在 2025 年 7 月发布了一份技术报告《Context Rot: How Increasing Input Tokens Impacts LLM Performance》（作者 Kelly Hong、Anton Troynikov、Jeff Huber）。需要如实说明：这是厂商技术报告，不是同行评审论文。它在控制了任务难度、只改变输入长度的前提下，测了 18 个主流模型（含 GPT-4.1、Claude 4、Gemini 2.5、Qwen3），结论是「模型并非均匀使用上下文，输入越长，表现越不可靠」（原文：models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows）。
截至 2026-09-28，关于「上下文时效性」的研究仍以厂商技术报告与官方工程博客为主，尚无统一的行业强制标准。这恰恰说明：把历史工单治理好，比「越多越好」重要得多。
3.2 工单语料里的「干扰项」从哪来
Chroma 的报告里有个词叫 distractor（干扰项）：和正确答案话题相近、但内容不同的信息，会抢走模型的注意力。
对应到工单语料，干扰项就是那些「看着相关、其实过期或口径不同」的记录。表 2 是映射。
| Chroma 报告的发现 | 工单语料中的对应 |
|---|---|
| 输入越长，表现越不可靠 | 工单总量越大，过期记录越容易混进来 |
| 语义相近的干扰项最「毒」 | 同故障不同年代写法，正好语义相近 |
| 只加一个干扰项也会掉分 | 哪怕只有一条过期工单，也可能带偏答案 |
所以治理历史工单，本质是在替模型「做减法、做标注」——把干扰项挑出来，把该留的留下并注明时效。
第 4 章 一套筛选判据：这条历史工单能不能进知识库
落到实操，核心是一句话：每条历史工单入库前，先过一遍筛选判据。过不了就先别进，或补完信息再进。
4.1 六条判据
表 3 是建议的判据清单，直接可套。
| 判据 | 通过条件 | 不通过的处置 |
|---|---|---|
| 能否定位设备唯一标识 | 能对应到具体设备/位号 | 退回补全，或归为「通用经验」另存 |
| 是否带工况上下文 | 有故障时的运行参数/环境 | 补工况，否则降级为低权重 |
| 是否已被后续记录推翻 | 无更新记录或已确认仍有效 | 标 superseded，不进主库 |
| 时间衰减是否可标注 | 能判断适用的时间范围 | 无法判断则暂不入库 |
| 口径是否与现行一致 | 与新规程/近期工单不冲突 | 冲突的留底备查，不进主库 |
| 信息是否完整可理解 | 外人能读完还原场景 | 缺上下文的先补全 |
4.2 给每条工单贴上「元数据标签」
「元数据」就是贴在每条记录上的标签，说明它属于哪台设备、什么时候、什么状态。它是治理的抓手，没有它，时间衰减和口径漂移都没法标注。
下面这段是给一条工单定义元数据的示例（未实际运行，仅示意字段设计）：
⚠️代码待验证
work_order={"doc_id":"wo_feedwater_pump_2021",# 文档唯一标识，用于后续按文档刷新"content":"出口压力低，紧出口阀后恢复。","metadata":{"equipment_id":"PUMP-FW-02",# 设备唯一标识"fault_type":"出口压力低","recorded_at":"2021-08-12",# 记录时间"valid_from":"2021-08-12",# 该处理适用的起始时间"valid_to":"2023-05-01",# 设备改造后失效"status":"superseded",# superseded=已被后续记录推翻"standard_aligned":False,# 是否与现行口径一致"source_team":"运行三班",},}字段怎么填，正是下一节的重点。
4.3 时间衰减怎么标注
时间衰减的标注，靠两个字段就够了：
valid_from/valid_to：这条处理办法适用的起止时间。设备在某天改造，就把那天的日期写进valid_to，之后不再视为有效。status：current（当前有效）或superseded（已被推翻/过期）。新工单进来时，把同一设备同一故障的老记录标成superseded，而不是删掉——留底备查，也方便溯源。
这套「版本化」思路，在 RAG 文档管理里是通用做法：给每条记录一个版本状态，检索时只取有效的那版。
第 5 章 落地：从筛选到索引的工程做法
判据和元数据定好，工程上要让它们真正生效，靠的是两件事：按文档刷新和按元数据过滤。
5.1 用 doc_id 做「按文档刷新」
主流框架都支持用文档唯一标识做增量更新。以 LlamaIndex 为例，官方文档（Document Management）提供了refresh_ref_docs()：同一doc_id但文本或元数据变了，就更新；不存在的才插入，并返回哪些被刷新了。这样旧工单修订后，不必重建整个索引。
⚠️代码待验证
fromllama_index.coreimportDocument,VectorStoreIndex# 假设索引里已有 doc_id="wo_feedwater_pump_2021" 的旧工单updated=Document(text="出口压力低，经查为出口压力表引压管堵塞，疏通后恢复。",id_="wo_feedwater_pump_2021",)index=VectorStoreIndex.from_documents([updated])refreshed=index.refresh_ref_docs([updated])print(refreshed)# [True] 表示这条被刷新了5.2 用元数据过滤掉过期版本
索引建好后，检索时加上元数据过滤，只取status="current"的记录，过期工单自然不会翻出来。下面是一段示意（语法参考主流向量库过滤写法，未实际运行）：
⚠️代码待验证
# 检索时只取当前有效、且口径与现行一致的工单results=vectorstore.similarity_search(query="出口压力低怎么处理",k=5,filter={"status":"current","standard_aligned":True},)fordocinresults:print(doc.metadata.get("equipment_id"),doc.page_content[:60])LangChain 官方的 Indexing API 也给出了配套能力：用RecordManager记录每个文档的内容哈希、写入时间与来源标识，并支持cleanup模式清理向量库里的过期数据（「remove stale data from your vector store」）。截至 2026-09-28，本文引用的 LlamaIndex 与 LangChain 官方文档均提供文档级刷新与索引清理能力。
配套资料：工单语料元数据标注模板：把第 4 章的判据做成可勾选的字段模板，直接套到你的历史工单上。放在资料包里，扫码即可获取：
第 6 章 为什么这活正好是你——行业老兵——的优势
讲到这儿你可能发现了：前面这些治理动作，算法帮不上太多，真正难的是「判断哪条记录作废、哪条口径要统一」。而这，正好是你——在厂区干过的老兵——的优势。
6.1 你懂设备，才知道哪条记录已作废
valid_to该填哪天？只有真知道那台泵哪年改造过的人才能填准。模型不知道，新来的工程师不知道，只有你翻得出当年的技改单。
同样的，某条 2015 年的「紧一紧就好」，今天到底还灵不灵，取决于设备改没改、工艺变没变——这是现场知识，不是向量检索能替你做的判断。
6.2 口径统一需要现场知识，算法替代不了
口径漂移的治理，本质是「把二十个老师傅的说法，归成一套现行口径」。这一步需要你拍板：哪条是通用结论，哪条是特定工况下的判断，哪条该标superseded。
所以别觉得自己转 AI 没底气。你不需要先成为算法专家，你先把「哪些工单能进知识库」这件事做对，就已经比绝大多数只懂模型、不懂设备的人稀缺得多。语料治理，是行业老兵的护城河。
第 7 章 一个最小可执行的治理流程
最后给一套能直接开工的五步流程，别想太复杂，先跑通一小批工单。
7.1 五步流程
表 4 是流程清单。
| 步骤 | 动作 | 产出 |
|---|---|---|
| 1 抽样 | 先取一个设备的一类工单（如水泵出口压力低） | 一小批可操作的样本 |
| 2 标注元数据 | 填 equipment_id、时间、status 等 | 带标签的记录 |
| 3 过判据 | 用第 4 章六条判据逐条核对 | 可入库 / 待补全 / 留底 |
| 4 入库建索引 | 用 doc_id 写入，开启刷新 | 可检索的知识库 |
| 5 加过滤 | 检索只取 current 且口径一致 | 稳定的回答 |
7.2 三个常见坑
- 整包倒入：先把几十年工单一口气灌进去，后面治理成本翻几倍。先小批跑通。
- 只存不标：只把工单转成文本，不补
equipment_id和valid_to，时间一长照样衰减。 - 忽视推翻链：新工单来了，老的没标
superseded，检索时新旧并出，答案打架。
配套资料：历史工单入库筛选清单：把第 7 章的五步流程整理成一页可打印的核对单，照着走就能开工。放在资料包里，扫码即可获取：
附表 A：本文引用事实与出处对照表
| 事实 | 出处（标题 + 域名） | 本文位置 |
|---|---|---|
| 上下文窗口 token 越多，模型回忆能力越下降；模型有「注意力预算」 | 《Effective context engineering for AI agents》，anthropic.com，2025-09-29 | 第 3 章 3.1 |
| 18 个模型在输入变长时表现非均匀下降，模型不匀速使用上下文 | 《Context Rot: How Increasing Input Tokens Impacts LLM Performance》，trychroma.com，2025-07（厂商技术报告，非同行评审） | 第 3 章 3.1、3.2 |
| LlamaIndex 支持按文档插入/删除/更新/刷新，refresh_ref_docs 按 doc_id 更新 | LlamaIndex 官方《Document Management》，developers.llamaindex.ai | 第 5 章 5.1 |
| LangChain Indexing API 用 RecordManager 记录文档哈希与来源，支持清理过期数据 | LangChain 官方博客《Syncing data sources to vector stores》，blog.langchain.com | 第 5 章 5.2 |
| 检索时应只取当前有效版本，过期文档需标记或清理 | 社区实践总结（dev.to 等，非官方文档），与官方 Indexing API 思路一致 | 第 4 章 4.3、第 5 章 5.2 |
| 截至 2026-09-28，上下文时效性研究以厂商报告与官方博客为主，无统一强制标准 | 本文基于上述一手来源的综合判断 | 第 3 章 3.1 |
附表 B：术语速查表
| 术语 | 一句人话解释 |
|---|---|
| 语料 | 喂给模型的原始文字材料，你的工单、记录都算 |
| RAG（检索增强生成） | 模型答题前，先从你的资料里找出相关段落再作答 |
| 元数据 | 贴在每条记录上的标签，说明它属于哪台设备、什么时候、什么状态 |
| 口径漂移 | 同一故障在不同年代/班组笔下写法不一致 |
| 时间衰减 | 设备已改造，老办法失效，但记录上没标「已过期」 |
| 干扰项（distractor） | 和答案话题相近、但内容不同的信息，会带偏模型 |
| superseded | 标记「这条已被后续记录推翻/过期」，留底备查但不进主库 |
| 按文档刷新 | 用唯一标识更新变了的那条，而不用重建整个索引 |
写在最后：这篇用到的资料
写这篇文章时，我把过去一年帮能源行业朋友梳理历史工单的经验，连同几份可以直接套用的模板一起整理了出来，顺手也整理了几份配套的东西：
- 大模型学习路线图：从零基础到能自己动手做 Agent，按阶段说明每一步该学什么、哪些可以先跳过
- 《LangChain + LangGraph + MCP 智能体开发实战》视频课：7 个模块，从私有化部署、Embedding+RAG 到 MCP+Agent 全流程
- AI 大模型知识库（在线可查）：Agent Skills 从入门到落地、Claude Skills 完全指南等专题，按目录浏览即可
- 640 套 AI 大模型行业报告 + 经典 PDF 书籍：看行业落地案例和别人怎么做的时候用得上
- 大模型零基础到精通教学视频：跟着敲一遍，比只读文档快得多
资料是我自己整理的，放在下面这个码上，扫码即可获取：
添加时备注「AI」，优先通过。
资料按「先路线、再动手、最后查漏」的顺序整理好了，建议先看学习路线那一份，照着它挑一条适合自己当前基础的路径再往下看。
