智能遇不到数据
处理高敏感数据的时候，企业会遇到三个事实：
- 智能在外部：能力强的大模型大多都运行在服务商的服务器上，企业只能使用 API 调用。
- 数据在内部：企业数据都保存在系统内部，或是私有云中。
- 数据无法外出：由于合规要求和商业机密，数据默认不发送给外部模型。
当这三个事实遇在一起时，会产生矛盾。
智慧的大脑，看不到作业本，而看到作业本的大脑，又不太聪明。
所以我们可将问题定义成「如何让智能遇到数据」。
要么出去，要么进来
解决方法无外乎两种，
只让必要的数据出去，或是让智能进入企业自己定义的信任边界。
在实际工程中，多条路径会结合使用。
数据出去
路径 A：把必要的数据变小和变干净，然后发送出去。
企业可以使用 RAG 获取和问题有关的信息，再进行权限检查、数据最小化和提前脱敏，只将必要的部分，发送到外部大模型。
路径 B：让数据进入到受到硬件保护，可以验证的计算环境
数据在传输和存储时，保持加密，只有进入到验证过的硬件隔离环境后，才会发生计算。该环境被称为 TEE（Trusted Execution Environment），该技术也被称为 Confidential Computing。
智能进来
路径 C：使用本地数据增强本地模型的能力
数据不会越过信任边界。企业使用本地数据 和 fine-tuning，训练本地模型成为某个领域的专才。
路径 D：使用智能教会本地模型
使用更强的大模型作为 teacher，生成训练样本或监督信号，再将一部分能力转移给本地 student 模型。这就是 Knowledge Distillation。
每条路径的可能
路径 A - RAG
RAG 的全称是 Retrieval-Augmented Generation。
在 RAG 中，文档通常先被切分并建立索引。索引可以是向量索引、BM25/全文索引、结构化数据库，或几种方式的组合。
用户提问时，获得相关的 chunks，然后发送给内部或外部大模型。
如果送到外部大模型，其中重要的步骤是，即便是碎片，但发送的数据仍是真实的，因此还需要做额外处理：
- Access Control：需确认用户有权访问被检索到的数据。
- Data minimization：只发送回答问题必要的信息。
- Local embedding and reranking：本地完成向量化和排序。
- PII redaction /masking layer：使用本地模型或者规则，替换或删除真实的敏感信息，收到答案以后再按需回填。
- query rewriting：对具体问题进行抽象化。
最近提出的 SAG，全称是 SQL-Retrieval Augmented Generation，是一种具体的结构化检索方案。它将 chunk 表示为 event 和 indexing entities，再使用 SQL join 在查询时建立局部关联，适合跨文档关联和 multi-hop retrieval。但它目前仍是一种较新的具体架构。
检索质量决定了这条路径的上限。如果检索不到关键信息，或者无关信息太多，大模型再聪明也没有办法。不仅如此，原始数据质量、权限控制、reranking、上下文组织和生成模型同样会影响最终效果。
路径 B - 让数据进入一个受到硬件保护的计算环境
数据在传输和存储时保持加密。进入硬件隔离的安全区域后，只有被允许的代码才能使用这些数据。这个安全区域被称为 TEE（Trusted Execution Environment），相应的技术通常被称为 Confidential Computing。
TEE 的目标是保护 data in use，使 TEE 之外的程序或对象难以直接读取或篡改其中的数据。
它通常还支持 Attestation。企业可以在释放密钥和发送敏感数据之前，验证对面运行的是不是约定好的硬件环境、代码版本和配置。
但 Attestation 不能证明程序没有漏洞，也不能阻止设计错误的程序主动泄露结果。
目前，云厂商和硬件厂商已经提供 confidential VM、container 和 GPU 等基础设施。不过，具体的大模型服务是否支持可验证的 confidential inference，仍然取决于供应商和部署方式。
缺点是可能带来额外的成本、性能开销、硬件限制和运维复杂度。
路径 C - Fine-tuning
转变智能的方向，不让小模型变大，而是变成专才。
选择一个可自托管的开放权重模型，将其部署在本地或经过批准的私有环境中，再使用企业允许的数据进行 fine-tuning。
为了降低训练成本，可以使用 LoRA 等 PEFT 方法。具体实现可以使用 Hugging Face PEFT、Unsloth、Axolotl 等框架，也可以在合规要求允许时使用 AWS SageMaker 等托管平台。
本地模型的通用能力通常难以追平更大的前沿模型。但在边界清晰的任务上，例如工单分类、字段抽取、格式转换和固定风格改写，小模型可能超过通用大模型。
fine-tuning 适合学习稳定的行为、格式和任务模式，不适合存储需要频繁更新、精确引用和及时删除的企业事实。这类知识通常仍然更适合通过 RAG 提供。
这条路径的难点是训练算力、评估体系和 MLOps。
更深的陷阱是数据质量，因为 garbage in, garbage out。使用敏感数据训练后，还需要评估模型是否会记忆或泄漏训练内容。
路径 D -Knowledge Distillation
经典的 Knowledge Distillation，是让 student 模型学习 teacher 模型的输出分布或其他监督信号。
在现在的 LLM 工程中，更常见的是一种行为蒸馏：企业准备合成数据、公开数据或脱敏后的数据，由大模型 teacher 生成答案候选、结构化结果或可以验证的中间结果。
随后使用规则、程序执行、历史结果或领域专家进行筛选，形成高质量的输入输出对，再通过 supervised fine-tuning 训练本地 student 模型。
它和路径 C 天然结合。
distillation 提供训练目标，fine-tuning 负责让 student 学会这些行为。这种组合适合高频、稳定和模式化的任务。
不过 teacher 的输出不能被认为是完全正确的 label。如果没有验证，teacher 的错误也会被一起蒸馏给 student。
路径终会成环
实际中，路径会形成一个环，并使用 local handling rate 衡量效果。
这里的 local handling rate，是指在满足质量和风险要求的前提下，不调用外部模型便能完成的请求比例。
目标是在满足质量、安全和成本要求的前提下，尽可能地提高这个值。
前半部分是 RAG，如果只需模型转述或总结 chunk，那么本地模型即可，如果需要更高性能的模型，则要脱敏后发出，并获得高质量答案。
在完成数据治理的前提下，这些交互可以成为候选训练数据，为了成为实际的训练集，还需要检查数据权限、保留期限、输出质量、来源追踪和人工反馈。
如果只停留在这一步，系统只是能用，为了让它好用，我们还需要引入一个受到质量控制的反馈机制。
因此，下一步可以引入 Distillation + Fine-tuning。使用上一步经过筛选和验证的候选数据，并结合企业内部经过治理的数据，对模型进行内部 Fine-tuning，使其更加精专，让系统从能用变得好用。
对于高难度、高敏感度的边缘情况，如果所需模型支持可验证的 TEE，可以使用 Confidential Computing。否则，系统仍然需要转交人工，或拒绝自动处理。
飞轮转动起来后，智能和数据的交汇点会越来越向企业的信任边界内靠拢。
最终，更多适合本地处理的请求可以留在企业内部。
对于高频且稳定的任务，这可能减少敏感数据向外暴露的范围，也可能降低边际推理成本。
