这次我们来看一个偏治理方向、但工程上非常值得借鉴的框架Post-Training Adaptation训练后适配六维分类法。它解决的不是“某个模型能不能跑”而是“训练后适配技术这么多企业怎么在模型治理、审计和合规体系里统一描述它们”。如果你所在团队同时维护几十个微调模型、LoRA、量化版本或知识编辑过的模型你会发现用自然语言写模型卡根本管不过来必须有一套可执行、可枚举、可对接自动化策略的分类标准。这套六维分类法就是干这个的。先说核心价值。它把训练后适配技术拆成六个可独立枚举的维度让一个模型从“被怎么改过”变成结构化字段它能把模型审计从“人工看文档”变成“跑规则引擎”它也能把AI治理要求落到模型注册、变更审批、部署前检查和运行期监控上。本文会围绕六个维度逐个拆解然后给出一套可落地的模型注册表Schema、审计策略脚本、API调用示例和批量扫描思路。适合的读者包括负责模型上线和合规审查的工程师、做AI平台和MLOps的架构师、以及需要对开源模型做二次开发和内部治理的技术负责人。下面直接进入分类法本身。1. 核心能力速览能力项说明项目类型训练后适配技术的分类框架属于AI治理工程化方法论核心输出六维分类定义、结构化描述规范、治理应用示例主要功能统一描述微调/对齐/知识编辑/模型合并/量化蒸馏/上下文适配等技术应用场景模型登记、变更审批、风险评估、部署审计、运行期监控技术门槛需要理解基础的大模型训练与推理流程不需要完整复现训练显存与算力要求不需要固定显存取决于具体扫描与评估工具分类本身是纯规则计算支持平台跨平台Python实现即可是否支持API支持可作为治理服务对外提供模型登记和查询接口是否支持批量任务支持适合对模型资产做批量扫描和批量更新落地形式模型注册表 Schema 审计策略脚本 治理 API 服务从材料看这个框架的目的是把“训练后适配”从散乱的技术术语变成可管理的治理对象。下面重点讲六维定义和每维度怎么在治理中落地。2. 六维分类法详解所谓六维是把一个模型在预训练之后经历的所有适配过程拆成六个互不重叠、可枚举的维度。2.1 按适配目标分类第一维回答“这次适配想达到什么目的”。常见目标包括能力增强让模型学会新领域的知识例如代码、医疗、法律行为对齐让模型遵循人类偏好减少有害输出事实修正替换过时或错误的知识风格迁移改变输出语气、格式、语言风格性能压缩用更小的模型保持接近原版的能力任务扩展为特定下游任务增加输出头或工具调用能力。这个维度的治理意义在于每次登记模型变更时必须声明目标类型。目标类型直接影响后续审批策略。2.2 按参数干预方式分类第二维看“适配过程动了哪些参数”。干预方式典型技术治理含义全参微调Full Fine-tuning参数变动面最大需要重新评估全量能力参数高效微调LoRA、Adapter、Prefix-tuning参数增量小可做增量模型管理冻结推理期适配提示词工程、上下文注入、RAG不改权重但改变行为治理上容易被遗漏知识编辑定位-修改-重写参数修改局部事实影响面分析复杂模型融合Model Merging、Model Soup多个模型能力叠加来源追溯难这一维决定治理时的“影响面”。冻结推理期适配虽然不动权重但实际改变了模型行为必须在模型卡里记录。2.3 按数据来源与人工参与度分类第三维描述“适配用了什么数据和反馈信号”。人工标注数据模型生成数据用户反馈数据领域公开语料无数据干预纯靠推理期策略。数据维度直接影响合规和版权审查。如果一个适配模型用了大量未授权语料那么审计时就必须标红。2.4 按优化算法分类第四维记录“用什么算法完成适配”。算法类别代表方法治理关注点监督微调SFT稳定但需要高质量标注偏好优化RLHF、DPO、IPO对齐效果好奖励模型偏见要评估对抗训练红队对抗、鲁棒性训练安全性提升但可能牺牲通用能力知识编辑算法ROME、MEMIT精确修正事实但影响边界要测蒸馏压缩知识蒸馏、量化性能和召回率需要基准测试2.5 按扩展与集成层级分类第五维看“适配发生在哪个层级”。单模型层面直接在一个基座模型上微调、编辑、压缩。多模型层面做模型集成、路由、混杂推理。例如多个LoRA挂在同一个基座模型上或者用路由器分发请求到不同领域模型。外挂系统层面通过RAG、工具调用、提示词模板实现能力扩展。层级不同可管理的最小单元就不同。多模型混合场景必须设计独立的模型版本表否则审计时无法定位哪个子模型产生了问题输出。2.6 按生命周期治理阶段分类第六维是治理流程视角把适配动作放到模型生命周期里看训练期适配部署前适配上线后持续适配退役期适配。这一维的意义是把前五个维度的信息挂到具体时间节点上。配合变更记录可以回答“这个模型在上线后有没有被偷偷改过行为”。从工程落地的角度看这六个维度合在一起就成为一张模型卡的结构化底座。3. AI 治理场景中的落地价值3.1 模型登记与资产盘点当团队内部模型数量超过 50 个时靠 README 文档维护模型说明基本不可行。六维分类法可以把每个模型整理成一条结构化记录目标、参数干预方式、数据来源、优化算法、集成层级、生命周期阶段。这样模型资产的盘点变成一次数据库查询。3.2 变更审批与风险评估模型从 v1 升到 v2审批人最关心的问题是改了什么、动了多大范围、对安全性的影响是什么。六维字段可以直接放进审批单。例如某个变更记录显示适配目标是“行为对齐”参数干预方式是“LoRA”数据来源是“用户反馈”优化算法是“DPO”集成层级是“单模型”生命周期阶段是“部署前适配”。审批系统就能自动判断变更属于低风险微调可以一般审批如果目标是“性能压缩”且用了量化则额外触发基准测试检查项。3.3 审计追踪与责任归属治理体系里最难的一件事是当线上模型输出有害内容时能否快速定位是基座模型的问题还是某个LoRA的问题还是提示词系统的问题。六维分类法中的“参数干预方式”和“扩展与集成层级”两个维度可以支撑这种定位。把模型版本、LoRA版本、提示词模板版本全部记录为独立对象审计时就能按时间线回溯。3.4 自动化监管策略分类法本身是规则规则适合用代码执行。下面是一个简化示例当策略引擎检测到一个适配目标为“行为对齐”但缺少红队测试报告的模型时阻止其上线。4. 环境准备与前置条件这一节以“将六维分类法落地成治理工具链”为目标。不需要训练模型也不需要专用显卡但需要一个可执行Python的运行环境以及一个用于存储模型登记信息的数据库。4.1 基础运行环境操作系统Windows / macOS / Linux 均可Python建议使用 3.10 或更高版本数据库SQLite 足够本地验证团队级建议用 PostgreSQL依赖库pydantic、fastapi、sqlalchemy、requests不需要GPU显存。4.2 目录规划建议把模型资产、分类定义、策略脚本分开管理ai_governance/ ├── schemas/ │ └── model_record.json ├── policies/ │ └── audit_rules.py ├── services/ │ └── model_registry_api.py ├── inputs/ │ └── model_inventory.csv ├── outputs/ │ └── audit_report.json第一次落地时先准备一个模型清单CSV每一行代表一个已登记模型包含六个维度对应的字段。这个文件用于批量导入测试。5. 六维分类法的 Schema 设计要让六维分类法可执行第一步是把六个维度变成结构化的 Schema。下面用 JSON 格式给出一个可扩展的模型登记模板。5.1 基础模型记录{ model_id: llm-finance-lora-v2, base_model: base-model-7b-v1, adaptation: { goal: capability_enhancement, parameter_intervention: peft_lora, data_source: [domain_corpus, human_annotated], optimization_algorithm: sft, integration_level: single_model, lifecycle_stage: pre_deployment }, owner: risk_ctrl_team, created_at: 2025-01-10T08:00:00Z, approval_status: pending }5.2 策略规则声明治理策略可以写成声明式规则。下面是一个策略示例只允许“行为对齐”目的下采用DPO且附带对抗测试记录的模型上线。policy_id: alignment_online_rule condition: adaptation.goal: behavior_alignment adaptation.optimization_algorithm: dpo test_record.red_team_report: exists action: allow_online6. 安装部署与启动方式这里提供一个最小的治理服务启动方案。核心是通过 FastAPI 暴露模型登记与查询接口本地验证时无需数据库服务。6.1 初始化虚拟环境mkdir ai_governance cd ai_governance python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\\Scripts\\activate pip install fastapi uvicorn pydantic sqlalchemy6.2 启动模型登记API以下代码实现了一个简化版模型注册服务包含新增模型和按维度查询功能。实际生产环境需要补充鉴权和数据持久化。from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import List, Optional app FastAPI() class AdaptationInfo(BaseModel): goal: str parameter_intervention: str data_source: List[str] optimization_algorithm: str integration_level: str lifecycle_stage: str class ModelRecord(BaseModel): model_id: str base_model: str adaptation: AdaptationInfo owner: str approval_status: Optional[str] pending models_db {} app.post(/models) def register_model(record: ModelRecord): if record.model_id in models_db: raise HTTPException(status_code400, detailmodel already exists) models_db[record.model_id] record return {status: registered, model_id: record.model_id} app.get(/models/{model_id}) def get_model(model_id: str): if model_id not in models_db: raise HTTPException(status_code404, detailmodel not found) return models_db[model_id] app.get(/models/filter) def filter_models(goal: Optional[str] None, integration_level: Optional[str] None): result [] for record in models_db.values(): if goal and record.adaptation.goal ! goal: continue if integration_level and record.adaptation.integration_level ! integration_level: continue result.append(record) return {count: len(result), models: result}启动命令uvicorn model_registry_api:app --host 127.0.0.1 --port 8000启动后访问http://127.0.0.1:8000/docs可以看到Swagger文档可以直接在页面上测试接口。如果端口被占用换一个端口即可uvicorn model_registry_api:app --host 127.0.0.1 --port 80017. 功能测试与效果验证框架落地后需要验证两件事分类描述是否完整、策略规则是否触发正确。下面给出一套批量验证流程。7.1 批量导入模型清单先准备model_inventory.csvmodel_id,base_model,goal,parameter_intervention,data_source,optimization_algorithm,integration_level,lifecycle_stage,owner llm-finance-lora-v2,base-model-7b-v1,capability_enhancement,peft_lora,domain_corpus,human_annotated,sft,single_model,pre_deployment,risk_ctrl llm-chat-dpo-v1,base-model-13b-v1,behavior_alignment,full_finetune,preference_feedback,dpo,single_model,pre_deployment,platform_team批量导入脚本示例import csv import requests url http://127.0.0.1:8000/models with open(inputs/model_inventory.csv, newline, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: payload { model_id: row[model_id], base_model: row[base_model], adaptation: { goal: row[goal], parameter_intervention: row[parameter_intervention], data_source: row[data_source].split(|), optimization_algorithm: row[optimization_algorithm], integration_level: row[integration_level], lifecycle_stage: row[lifecycle_stage] }, owner: row[owner] } resp requests.post(url, jsonpayload, timeout10) print(resp.status_code, resp.json())注意CSV 中的多值字段用|分隔。这是为了避免与英文逗号冲突实际生产环境建议直接使用JSON记录。7.2 策略规则触发测试接着编写一个规则检查脚本输入模型记录输出是否允许上线。from pydantic import BaseModel class TestRecord(BaseModel): red_team_report: bool False class PolicyEngine: def check(self, record: dict, test: TestRecord) - tuple: adaptation record.get(adaptation, {}) goal adaptation.get(goal) algorithm adaptation.get(optimization_algorithm) if goal behavior_alignment and algorithm dpo: if test.red_team_report: return True, alignment rule satisfied return False, missing red_team_report if goal performance_compression: return False, requires benchmark validation first return True, default allow验证时构造不同组合的模型记录确认规则的返回结果符合预期。判断标准行为对齐 DPO 有红队报告 应允许行为对齐 DPO 无红队报告 应拒绝性能压缩 默认拒绝等待基准测试。7.3 验证步骤总结测试项输入预期结果判断标准模型登记合法JSON记录返回registered数据库可查到记录重复登记相同model_id返回400错误信息清晰六维查询goalbehavior_alignment返回匹配模型分类过滤生效策略拦截无红队报告的对齐模型状态为拒绝策略引擎返回False8. 接口 API 与批量任务8.1 治理 API 调用示例治理服务最终要对接内部平台。建议提供三类接口模型登记、策略评估、审计查询。# 登记模型 curl -X POST http://127.0.0.1:8000/models \ -H Content-Type: application/json \ -d { model_id: llm-chat-dpo-v1, base_model: base-model-13b-v1, adaptation: { goal: behavior_alignment, parameter_intervention: full_finetune, data_source: [preference_feedback], optimization_algorithm: dpo, integration_level: single_model, lifecycle_stage: pre_deployment }, owner: platform_team }# 查询某个维度的模型 curl -G http://127.0.0.1:8000/models/filter \ --data-urlencode goalbehavior_alignmentPython 调用示例import requests import json api_base http://127.0.0.1:8000 model_record { model_id: llm-legal-merge-v1, base_model: base-model-7b-v1, adaptation: { goal: task_expansion, parameter_intervention: model_merging, data_source: [domain_corpus], optimization_algorithm: model_merge, integration_level: multi_model, lifecycle_stage: pre_deployment }, owner: legal_ai } resp requests.post(f{api_base}/models, jsonmodel_record, timeout10) print(resp.json())8.2 批量扫描设计治理场景经常要对全量模型资产做扫描。建议采用“任务列表 单条处理 日志输出 失败重试”的批量模式{ batch_id: batch-20250115, task_list: [ {model_id: llm-finance-lora-v2}, {model_id: llm-chat-dpo-v1} ], strategy: pre_deployment_audit, output_dir: ./outputs/audit_reports }批量扫描脚本需要考虑三点接口超时每个模型记录调用策略引擎时设置超时时间防止单个异常卡死任务失败重试对临时网络错误或数据库锁冲突重试两次结果汇总扫描完成后输出汇总JSON按风险等级排序。9. 资源占用与性能观察这个分类法本身不涉及大模型推理所以显存占用基本可以忽略。真正需要观察的是治理服务的运行开销。9.1 性能观察指标指标说明建议API查询延迟单次模型登记/查询耗时本地应在毫秒级批量扫描吞吐量每分钟处理的模型记录数应记录基线值数据库写入量模型版本变更产生的记录数高频变更场景需要定时归档策略规则执行时间每次规则评估耗时纯规则应在微秒到毫秒级当模型记录数量达到数万条、且每次查询都需要关联审计历史时需要给数据库建索引。如果跨部门部署建议把治理服务与模型推理服务分离部署避免互相影响。9.2 性能优化思路六维字段全部用枚举字符串存储减少自由文本带来的脏数据建立(goal, optimization_algorithm)组合索引加速常见策略查询批量扫描使用多线程或任务队列但要注意数据库连接数限制审计日志单独存储不要在模型主表上保留全量历史。10. 常见问题与排查方法问题现象可能原因排查方式解决方案模型登记接口返回400model_id重复或字段缺失查看接口错误信息检查model_id唯一性与字段是否完整策略规则没有拦截预期模型六维字段值不匹配打印策略引擎输入记录统一枚举值避免大小写不一致CSV批量导入部分失败多值字段分隔符冲突查看每行导入返回状态使用JSON导入或统一使用“查询接口延迟高缺少索引或数据量大查看数据库慢查询日志建立组合索引分页查询API启动时端口被占用端口冲突检查端口占用情况更换端口或杀掉占用进程审计报告缺失某模型模型未登记或字段为空检查模型清单完整性补录模型记录设置“必填字段”校验落地过程中最常出现的问题是同样的适配技术在记录时用了不同的枚举值。例如“DPO”和“dpo”同时存在导致策略规则筛不出来。建议在系统入口做枚举校验所有字段只允许写入统一的枚举列表。11. 最佳实践与使用建议11.1 先定义枚举再上系统六维分类法能不能跑起来关键看枚举值是否稳定。团队内部要提前确定适配目标枚举有哪些参数干预方式枚举有哪些优化算法枚举有哪些生命周期阶段如何划分。不要在上线后再频繁改枚举否则历史数据会很难清洗。11.2 模型卡与代码变更联动模型登记记录不能只靠人工填写。建议把六维字段写入模型的发布配置清单中由CI/CD流程在构建时自动提取并调用治理API。如果模型文件是LoRA则自动读取训练配置中的算法和数据集来源。11.3 审批策略分阶段加严第一次落地时不建议直接拦截所有不满足策略的模型。先观察一个月收集真实数据分布把“行为对齐”“性能压缩”等高风险类型的规则优先启用其他类型先设置为告警模式。11.4 合规与授权边界无论用什么适配技术都要确认数据和代码的使用边界。微调数据如果是网络爬取内容必须确认版权授权情况用户反馈数据如果用于DPO训练需要确保符合隐私政策和用户协议。模型上线前应完成红队测试、公平性评估和可能涉及的肖像或声音授权复核。对开源模型而言还要检查其许可证是否允许商业用途和二次修改并在模型卡中记录许可证信息。11.5 保留一套最小可运行配置维护一个最简单的demo配置包含一个本地SQLite数据库、一个API服务、一个策略脚本。这样团队新成员可以快速理解分类法如何工作业务评审时也能用真实样例说明治理流程。12. 总结与下一步这套六维分类法最值得尝试的部分是“把治理规则变成结构化查询”。它不依赖特定算力也不需要专门的大模型团队只要把现有的模型资产按六个维度登记一次就能获得可查询、可审计、可对接规则引擎的模型台账。建议最先验证的是“模型登记 六维过滤查询”这条链路。先录入手头最常见的三种模型一个SFT微调版本、一个DPO对齐版本、一个LoRA参数高效微调版本然后跑一轮过滤查询。通过后再接入策略引擎把审批规则从人工判断改成代码判断。最容易踩的坑是枚举值不统一。六个维度的取值必须在一开始就定死并且所有录入入口都做校验。后续可以继续扩展的方向引入自动化的红队测试结果字段与策略引擎联动增加多模型路由场景的版本追踪把六维字段嵌入模型推理日志让线上问题定位能直接在审计平台上完成。总之先把分类标准定清楚治理工具就会顺很多。建议收藏备用。