AI友好的数据管理:宣言

面对这样的结果，我们需要同时检查模型能力和数据条件：AI获得了什么信息，这些信息如何组织，哪些内容值得信任，又有哪些已经需要更新？

这正是我准备公开写作《AI友好的数据管理》的出发点：从数据管理入手，帮助AI更可靠、更高效地完成任务，并降低全生命周期的使用和维护成本。

一、为什么要公开写这本书

这本书面向数据管理从业者、AI应用开发者，也面向使用AI开展研究、分析、创作和日常工作的普通使用者。它关注从模型训练、评测，到推理、智能体执行、上下文与记忆管理，再到持续改进的全过程。

我希望把这些环节中的数据问题串起来。例如，什么样的训练样本值得保留；知识库如何维护来源和版本；一次推理需要哪些上下文；智能体应该记住什么、怎样更新记忆；运行反馈又如何转化为可靠的改进材料。

这些问题既需要共同的原则，也需要具体的结构、模板和实施方法。公开分享，希望带来三方面价值。

• 建立共同语言。让业务、数据和AI团队能够说清楚：一个问题来自数据缺失、语义歧义、知识过期、上下文组织，还是模型与任务本身不匹配。

• 提供可用方法。把原则落实为数据说明、组织结构、接口约定、记忆模板、评测方法和可复现案例，使读者能够从一个具体场景开始改进。

• 通过协作持续完善。让定义接受讨论，让方法接受实际任务的检验，让错误和局限能够被及时发现、记录和修正。

我也希望明确，这套方法最终要接受效果、效率和成本的共同检验。效果，要看任务完成质量、事实与引用准确性；效率，要看处理时延、人工介入和返工情况；成本，要看完成合格任务所需的数据加工、存储、检索、模型调用和维护投入。

数据量、知识库规模和上下文长度可以描述投入，但不能单独证明价值。如果一种数据组织方式增加了维护负担，却没有改善目标任务，就需要重新评估它的必要性。

本书计划采用“公开分享、协作共建”的方式持续更新，以非商业学习、交流和共同完善为目的。公众号发布能够独立阅读的方法与案例，GitHub维护完整书稿、配套模板和更新记录。商业再利用，以及将书稿内容用于论文、专利申请、出版物等成果的授权边界，将在仓库许可说明中明确。

二、什么是AI友好的数据管理

在这本书中，我提出如下工作定义：

AI友好的数据管理，是围绕具体任务，对AI全生命周期中使用和产生的数据及其衍生产物，进行组织、治理、供给与持续维护的一套原则、方法和工程实践。它在模型能力、使用权限、时效要求和资源预算的约束下，使数据更容易被发现、理解、使用和验证，并支持更新、纠错、撤回与退出。

这里的管理对象，既包括文档、表格、图片、音视频等原始材料，也包括加工后的数据集、知识片段、索引、上下文、工具返回结果、任务状态、长期记忆和运行反馈。

“AI友好”需要落实为几个具体问题：AI能否找到需要的数据，理解其含义与适用条件，在权限范围内获得充分的信息，定位支撑判断的证据，以及在数据发生变化后停止使用过时的内容。

这与既有数据管理思想一脉相承。FAIR原则强调数据的可发现、可访问、可互操作和可复用，并明确了标识、元数据、来源与使用许可的重要性。 本书在这些基础上，进一步讨论数据如何进入具体的AI任务，如何适配上下文与记忆，以及如何根据使用结果持续调整。

AI友好程度取决于任务和运行条件。同一份材料，可能适合检索，却不适合直接作为训练样本；可能适合短期工作记录，却不适合长期保存。判断一种设计是否有效，需要结合具体模型、应用方式和评价结果。

它与哪些概念不同：

第一，它不等同于“用AI做数据治理”。用AI辅助清洗、标注、分类，关注的是数据管理工作的自动化；AI友好的数据管理，关注的是怎样组织和供给数据，使AI更好地完成任务。两者可以相互促进。

第二，它不等同于某种文件格式或技术产品。把文件转成Markdown，或者把资料放入向量数据库，并不会自动解决语义、来源、时效与权限问题。表格、图关系、原始图像、接口和Markdown，都需要根据任务选择。

第三，它不止于训练数据集或RAG知识库建设。推理过程中选入的信息、智能体的工具结果、跨步骤任务状态，以及长期记忆和反馈，同样需要管理。

第四，它不以“尽可能多地提供数据”为目标。上下文组织需要兼顾信息充分性与资源约束；按需检索、压缩和外部记忆，都是可以根据任务选择的方法。 对某个任务有帮助的信息，未必应该出现在每一次调用中。

以记忆管理为例：

设想一段项目讨论先出现“预算80万元”，后来又出现“预算60万元”。如果只把聊天记录不断追加到一个文件中，后续调用仍需要重新判断两者是什么关系。

更适合这个任务的组织方式，是明确区分“初步估算”和“已批准预算”，记录对应来源、确认时间和适用范围，并说明后者是否替代前者。原始讨论可以按保留策略保存，当前有效事实则应能够被单独找到。

记忆结构还应区分事实、偏好、任务状态和待核实判断。Markdown中的标题、字段和目录，要帮助系统完成这些区分。记住了什么、凭什么记住、什么时候需要修改，应该成为记忆本身的一部分。

三、AI友好数据管理宣言

借鉴《敏捷软件开发宣言》以价值取舍指导实践的表达方式，我提出以下六项主张，作为本书讨论与实践的起点。

任务成效，高于数据规模。

语义清晰，高于格式统一。

按需供给，高于全量交付。

可验证的证据，高于即取即用的结论。

可更新、可撤回的记忆，高于完整持久的记录。

基于反馈的持续改进，高于初始设计的完备。

这些取舍承认两侧各自的价值。在资源有限、目标冲突或需要作出工程选择时，我们优先考虑前者。它们也不改变必须遵守的边界：合法授权、隐私保护、访问权限和必要的安全要求，应贯穿全部实践。

1. 任务成效，高于数据规模

数据规模可以扩大覆盖，但应以任务表现检验投入。对于一个回答制度问题的助手，首先要检查它是否引用了正确版本、是否识别适用对象、证据是否充分，再决定要补充多少材料。

2. 语义清晰，高于格式统一

统一格式有助于处理，清楚的语义则决定数据如何使用。一个字段的含义、单位、统计口径和适用时间，一段文字是在描述事实、提出建议还是记录假设，都应尽可能明确。

3. 按需供给，高于全量交付

在恰当的时点提供完成当前任务所需的信息，并保留继续获取细节的入口。组织可以分层，信息可以逐步展开；压缩应保留关键条件，检索应覆盖必要证据。这里追求的是充分且相关的信息。

4. 可验证的证据，高于即取即用的结论

摘要和结论能够提高使用效率，但关键判断应保留来源、版本和适用条件。证据可以通过引用和标识关联，无须每次全部装入上下文；需要核实时，应能回到支撑结论的材料。

5. 可更新、可撤回的记忆，高于完整持久的记录

长期记忆需要明确什么已经确认、什么仍待验证、什么已经失效，并能够修正错误和停止后续调用。工作记忆与审计记录可以采用不同策略：保留历史，并不意味着每次任务都要继续使用这些历史。

6. 基于反馈的持续改进，高于初始设计的完备

初始方案需要合理设计，也需要接受运行验证。真实任务、失败案例和可靠反馈，应推动数据组织与供给方式不断调整。每次调整都要经过适当评测，必要时能够回退，避免把未经验证的反馈直接变成新的事实或规则。

四、AI友好数据管理全生命周期参考框架

为了把这些主张落实到工作中，本书提出一个面向AI全生命周期的数据管理参考框架。它以AI系统从任务设计到构建、运行、改进和退出的过程为主线，明确每个阶段需要承担的数据管理责任。

同时需要区分：AI系统有设计、构建、运行和退出的生命周期；数据也有获取、加工、使用、更新和删除的生命周期。两者相互交织。系统投入运行后，仍会不断接收新数据、产生新反馈；数据撤回或权限变化，也可能要求立即调整正在运行的系统。

表中的顺序用于说明主要工作，不要求所有项目走同一条路线。训练可以是可选环节；采用已有模型的应用，也需要开展数据准备、评测、运行维护和退出管理。

在构建与运行阶段，可以组合三类使用路径：模型学习，包括预训练、微调和偏好学习；知识供给与推理，包括检索增强、数据库查询和上下文组织；智能体执行，包括工具调用、任务状态维护和多智能体协作。

上下文与记忆承担运行过程中的数据组织和延续职责，不能简单地排在“训练、推理、智能体”之后。某个任务可能只需要一次检索，另一个任务则可能需要多轮执行和跨会话记忆。

让框架形成真正的反馈闭环

首先，评估从任务定义开始，并持续贯穿运行。数据变更后，应在适当控制其他条件的情况下，比较任务质量、时延、成本和人工返工。用于调试改进的样例与用于最终检验的保留样例，应有清楚的职责区分。

其次，反馈需要经过筛选和验证。用户纠正、工具执行结果、点赞和模型自评，提供的是不同类型的信号。只有确认来源、适用范围和使用权限之后，才能决定将其转为知识更新、记忆、评测案例或训练候选数据。

再次，变化应沿着数据依赖关系传播。一份制度被替代，不仅需要更新原文件，还要检查相关索引、摘要、缓存和记忆。对于已经参与训练的数据，删除源文件并不等于消除它对模型的影响，相关处理需要另行评估；机器遗忘研究所讨论的，正包括如何移除特定训练数据对模型的影响。

贯穿所有阶段的，是语义与质量、来源与权限、版本与时效、评价与观测，以及成本和责任分工。无论使用哪一种模型、数据库或智能体框架，都应能够回答：这份信息从哪里来，为什么可以使用，影响了哪些结果，发生变化后由谁处理。

五、后续更新计划：六篇、二十四章

全书拟按六篇、二十四章展开。六篇构成稳定主线，章节内容将随着实践与讨论持续完善。

第一篇 基础：定义、宣言与参考框架

建立共同语言，把“AI友好”转化为可以讨论、设计和检验的管理目标。

• 第1章 AI友好的数据管理：概念与边界——明确管理对象、使用场景与适用条件。

• 第2章 AI友好数据管理宣言与设计原则——把价值取舍落实为具体设计依据。

• 第3章 面向AI全生命周期的参考框架——连接系统阶段、数据过程与管理职责。

• 第4章 从业务任务到数据目标与评价指标——用效果、效率和成本检验管理价值。

第二篇 准备：让数据具备可理解、可信和可用的基础

从现有数据出发，解决来源、加工、语义和供给的基础问题。

• 第5章 数据来源、资产盘点与使用授权——识别可用资源、使用范围与数据缺口。

• 第6章 结构化、非结构化与多模态数据准备——恢复结构，保留语义，建立跨模态关联。

• 第7章 语义组织、元数据与数据契约——明确含义、单位、口径、关系和接口约定。

• 第8章 数据质量、血缘与版本管理——让每一次数据供给能够检查、追踪和复现。

第三篇 学习：支持模型训练、对齐与评测

讨论数据如何影响模型学习，以及怎样区分实际改进与评价偏差。

• 第9章 预训练数据的选择、组合与供给——平衡质量、覆盖、重复和资源成本。

• 第10章 微调、偏好与合成数据管理——把任务经验转化为可验证的学习材料。

• 第11章 评测数据集与污染控制——维护评价样本的独立性与代表性。

• 第12章 数据迭代、实验复现与训练溯源——记录数据变化，验证收益，支持问题回查。

第四篇 推理：知识供给与上下文管理

围绕一次具体任务，决定向AI提供什么信息、怎样提供，以及何时更新。

• 第13章 知识组织与检索增强——设计切分、索引、检索与证据关联。

• 第14章 动态业务数据与实时连接——管理数据库、接口和持续变化的信息。

• 第15章 上下文的选择、组装与预算——组织指令、资料、历史和工具结果。

• 第16章 上下文压缩、缓存与更新——降低重复开销，控制信息损失与过期使用。

第五篇 行动：智能体与记忆管理

面向跨步骤、跨会话和多主体任务，设计可衔接、可检查、可更新的数据组织。

• 第17章 工具调用、任务状态与过程数据——管理输入输出、执行证据和任务交接。

• 第18章 记忆分层、Markdown结构与组织——设计事实、偏好、经历和方法的存放与检索方式。

• 第19章 记忆的写入、更新、冲突与遗忘——明确确认、纠错、失效和退出机制。

• 第20章 多智能体协作与共享知识——处理信息共享、权限边界和状态一致性。

第六篇 演进：持续治理、评估与优化

把分散的方法组织成持续运行的机制，支持系统和数据共同演进。

• 第21章 运行观测、质量变化与成本分析——看清实际任务表现及其变化。

• 第22章 反馈治理与评估驱动的持续优化——把经过验证的失败经验转化为改进。

• 第23章 安全、隐私、授权与责任治理——把治理要求落实到供给、使用与维护过程。

• 第24章 端到端实践与生命周期运营——串联建设、运行、更新、撤回、归档和退出。

每次更新会提供什么

公众号将沿着六篇主线，围绕一个具体问题展开一次更新：解释问题和典型反例，给出设计原则、可用结构与实施方法，再说明怎样评价效果。完整章节、模板、示例和修订记录，将在GitHub同步维护。

记忆管理会是其中一组重点实践：从记忆如何分层，到每层Markdown的标题、字段、目录和引用如何组织，再到写入、确认、冲突处理与失效管理，逐步给出可以讨论和复用的方案。

本篇作为起点，先公开定义、宣言和参考框架。后续将先展开基础篇，再推进数据准备、模型学习、推理、智能体与持续治理；相关模板和案例随章节逐步补齐。

欢迎大家提交实际使用中的问题、失败案例、纠错意见和可复现实践。对于提出的方法，也欢迎说明它在什么条件下有效、在什么条件下不适用。参与讨论时，请先去除案例中的敏感信息，并确认材料可以公开。

希望这本书能帮助我们，把“给AI提供数据”进一步落实为“让AI持续获得适合当前任务、可以验证和维护的数据”。

获取完整内容与参与讨论

GitHub书稿地址：https://github.com/Lucifer-Excelsior/ai-friendly-data-management

讨论区地址：https://github.com/Lucifer-Excelsior/ai-friendly-data-management/discussions