1. 范式转移的背景为什么企业开始需要“理解型”数据平台先讲一个我最近的实际感受。过去大半年我接触了不少正在做数据平台升级的企业客户几乎每个人都提到同一个痛点湖仓一体已经建完了数据也确实都集中在OneLake或者类似的数据底座里了但业务部门问的最多的还是那一句——“数据到底能帮我干什么”以前我们把数据平台做出来是解决“有没有”“能不能取”的问题现在企业真正卡住的是“取出来之后怎么变成判断和动作”的问题。这就是Fabric IQ这类平台出现的逻辑背景。它不是又一个ETL工具也不是单纯的数据可视化套件而是一个试图把“数据资产”升级为“知识资产”的中间层。微软对它的定位也很有意思不是让你再学一个新数据库而是在现有的Fabric架构之上把本体Ontology、**语义模型Semantic Model和大语言模型LLM**三套原本各玩各的技术栈整合成一条可供企业直接用自然语言对话、查询、分析甚至决策的生产链路。我见过不少团队在评估这类平台时第一反应是“这不就是个BI加上ChatGPT外壳吗”。说实话我一开始也这么想但深入拆解后发现没有这么简单。传统BI的核心是“定义的报表和固定的维度”而Fabric IQ这类智能平台的本质是“让机器用业务语义去理解数据再让模型用业务语义去生成答案”。这中间多出来的本体层恰好是过去大多数数据平台缺失的一环也是今天数据平台和大模型能不能真正结合的关键分水岭。为了把这件事说清楚这篇文章我会按自己的实际研究和踩坑经验从技术架构、本体设计、模型接入、落地实践和问题排查五个维度展开。如果你正在做企业级数据智能平台的选型或者已经准备在Fabric生态里尝试大模型能力这篇文章里的细节应该能帮你少走不少弯路。2. Fabric IQ架构拆解OneLake、语义模型与本体层各司其职2.1 从OneLake到Semantic Model数据怎么变成模型能消费的形态Fabric IQ底座的存储核心是OneLake这个应该不用我多介绍就是微软把Azure Data Lake Storage上面那套分布式能力搬到了SaaS层统一管理结构化、半结构化和非结构化数据。但真正的重点不在存储而在OneLake之上那层**语义模型Semantic Model**怎么设计。很多人会混淆语义模型和传统数据模型。传统关系模型里我们用外键、视图、存储过程去描述数据关系但机器不关心“客户”这个词在不同部门意味着什么。而Fabric的语义模型在你的Lakehouse上定义的是“指标、维度、业务实体和关系”这套模型天然服务于“人用业务语言去查询数据”。举个例子我在帮客户设计财务主题域的时候他们原来的数据仓库里可能有三张表——订单表、退款表、客户表。传统方式是写六个JOIN才能算出“月均客户退款率”但在语义模型里我只需要定义一个指标叫“客户退款率”它绑定了订单实体的金额维度、退款实体的状态维度和时间维度。大模型在回答“上个月退款率为什么上升”这个问题时不需要读懂三张表的JOIN逻辑它只需要基于语义模型去理解“退款率”这个指标的定义和它关联的维度就能生成一段合理的分析描述。这里有一个关键认知Fabric IQ的价值不在于模型多大而在于语义模型定义得有多准。如果语义模型里指标口径是混乱的那大模型再聪明也会一本正经地把错误答案讲得头头是道。2.2 本体层Ontology企业知识的结构化骨架再往上走就是Fabric IQ里最容易被忽略、但也是最有想象空间的部分——本体层。本体这个词在学术界存在几十年了简单说它就是一套“领域概念 概念间关系 约束规则”的显式规格说明。在企业数据场景里本体的作用是把散落在不同系统里的数据、指标、业务规则统一回到一个互相连接的知识骨架里。我用一个生活化的例子解释。你问智能助手“市场部这个季度的线索转化怎么样”如果没有本体层大模型面对的可能是一堆孤立的表和字段它只能靠联想猜。但如果有本体层模型知道“市场部是一个组织单元”“线索是一个业务对象”“转化率是由线索状态和商机金额共同决定的”“季度是一个时间维度”——这些都是预先定义好的结构模型回答的时候就是在一个有边界的知识网络里推理而不是在大海捞针。这就是本体层和大模型结合的妙处。大模型擅长的是语言生成和意图理解但它天生对企业的数据权限、指标口径、实体边界没有概念。本体层的职责就是把“企业知识的边界”先画好让模型在这个边界里自由发挥既保证回答的灵活性又保证企业上下文不会跑偏。Fabric IQ在工程实现上本体层通常以标准语义模型如OWL或类似图谱结构的方式存储在元数据服务里模型推理时通过语义检索把相关实体和关系送给LLM做上下文增强。这跟我一直在用的GraphRAG基于知识图谱的检索增强思路高度一致只不过Fabric IQ把这一层产品化了你不用自己从零去搭图谱服务和向量库的对接管道。2.3 LLM推理与微调什么场景需要私有化大模型说到大模型这是大家最关心也最容易产生误解的部分。Fabric IQ并不是让你必须自己训练一个大模型它更多是站在“模型网关”的位置帮你把任务分发给最合适的模型。比如简单的自然语言转SQL可能用中等参数量模型就够了复杂的跨域分析报告可能需要更强的推理模型涉及敏感数据的场景可能要走私有化部署的模型。我自己的实践经验是企业级落地时80%的场景根本不需要微调大模型本身更需要做的是检索增强RAG和上下文工程。真正需要微调的场景集中在三块第一领域术语高度专精。比如医疗、金融法务、半导体制造通用模型对“晶圆良率”“PI环”“对公授信”这类词汇理解有限微调或至少做术语注入才有明显效果。第二输出格式强约束。比如必须输出JSON格式的合规审查意见、必须遵循特定模板生成检测报告这种场景微调后稳定性能提高不少。第三私有化部署要求。当数据不能出域时不管效果如何你总得把模型部署到内网这时候模型量级、推理框架和硬件选型就都变成必须面对的问题。Fabric IQ的好处是它把这条路包装成了配置项而不是代码工程。你可以选择直接用Azure OpenAI服务也可以对接自己在内网部署的模型服务还可以在Fabric里调用微调管道做轻量级的领域适配。对团队来说这意味着可以先把流程跑通再逐步加强模型的深度而不是一开始就被模型训练绑住手脚。3. 五大关键组件与设计选型搞懂它们才算入门为了更直观地把Fabric IQ这类平台拆解开我按自己经常向客户介绍的方式把它整理成五个核心组件。每个组件背后都有明确的设计逻辑理解了这五个部分你就理解了Fabric IQ整体是怎么运转的。组件核心职责关键技术要点典型痛点OneLake数据底座统一存储所有结构化和非结构化数据Delta Parquet格式、跨云复制、OneLake快捷方式Shortcuts数据入湖的格式不统一语义模型层定义指标、维度、业务关系和权限类Tabular模型、行级安全、对象级权限指标口径定义容易失控本体与知识图谱描述业务实体间的语义关系和规则约束实体关系定义、属性槽位、规则引擎本体建模人才稀缺LLM编排与推理将用户意图转化为查询、分析、摘要动作自然语言转SQL、工具调用、多轮记忆幻觉问题、查询生成不准确可观测与治理记录分析过程、审计权限、追踪数据血缘CI/CD管道、活动日志、信息保护权限与合规审计困难先说底层设计逻辑。OneLake用Delta Parquet作为统一存储格式这招很聪明。Parquet是列式存储压缩率和查询性能都好Delta则在上面加了事务日志保证并发读写的一致性。本质上它把数据仓库的ACID能力带到了数据湖上唯一的代价是你必须接受一套有约束的文件组织方式不能再随便堆一堆CSV就完事。语义模型层则是整个系统的“翻译官”。大模型不读你的物理表结构它读的是语义层暴露出来的逻辑实体和指标。所以在这里面我强烈建议采用指标先行的设计方法先收集业务部门真正关心的核心指标再倒推需要哪些维度表和事实表而不是反过来从底层表往上凑指标。这个顺序一旦搞反后面大模型的答案质量一定会受到影响。本体层是整个Fabric IQ最可能的护城河。它跟语义模型的差别在于语义模型解决“指标怎么算”本体解决“业务世界怎么被理解和连接”。一个简单的例子在语义模型里你会定义“订单金额单价×数量”但在本体里你还要定义“客户-订单-付款”这些实体间的状态流转关系以及“如果付款逾期超过30天则该客户标记为风险客户”这类业务规则。这套规则日后会直接影响大模型在生成建议时会不会越界去谈一些不该谈的内容。LLM编排层是大家感知最明显的部分。你在对话框里输入“帮我分析一下华东区Q3销售下滑原因”后台实际上发生了一系列操作意图分类、实体识别、语义模型匹配、SQL生成或DAX查询、结果汇总、自然语言生成。任何一个环节出错最终答案都可能会偏。我遇到过很多次模型生成的SQL是对的但用错了维度的粒度把部门级数据当成公司级数据统计结果整个分析就废了。治理与可观测是用户最容易轻视的部分。大模型带来的最大风险是权限旁路——以前你给业务人员开一个报表权限就行现在他可以直接问“全国销售额最高的客户有哪些”如果你没在语义模型、本体层和LLM编排层都套上权限控制很可能一次对话就把不该看的明细给暴露出来了。Fabric的治理体系其实挺完整的问题在于落地时多数团队并没有把权限策略细化到对象级别。4. 从数据平台到智能平台的关键跃迁本体检索增强与语义缓存实战4.1 检索增强让大模型回答之前先查本体Fabric IQ里最核心的工程环节就是本体检索增强。这一步要做的事情用大白话说就是在大模型正式回答之前先从本体库存取与问题相关的背景知识然后把这些知识塞进Prompt里再让大模型生成。为什么要多此一举因为通用大模型并不了解你的企业。你在Prompt里不加点料大模型连“华东区包含哪些省份”这种基础问题都可能答错更不要说复杂的业务逻辑了。实际操作中一个标准的本体增强流程长这样用户输入问题先做意图识别和实体抽取“华东区Q3销售下滑原因”识别出实体是“华东区”和“销售”意图是“原因分析”。通过语义检索去本体知识库匹配“华东区”的成员省份、“销售”涉及的订单实体和指标定义。把匹配到的本体信息构造成JSON片段作为上下文连同原始问题一起发给大模型。大模型基于增强后的上下文生成SQL或分析结论。把结果返回给用户并记录到日志中。这段逻辑在实现上不难但在生产环境有很多细节要磨。比如语义检索的相似度阈值设多少设太严相关本体搜不到设太松无关实体跑到上下文里反而干扰判断。我通常建议从0.75起步上线两周观察Top-K召回准确率再慢慢调。还有一个非常容易踩的坑就是本体实体的歧义。中文博大精深“销售”既可能是一个部门也可能是一种行为还可能是一张表。所以我在设计实体描述时会给每个实体写一个上下文无关的默认解释并允许后续根据用户行为统计动态调整优先级。比如本体内“销售”部门实体的公文中写“负责面向客户的销售行为与订单管理的组织单元”模型在遇到歧义时会优先按这个解释走。4.2 语义缓存解决重复查询和多轮对话的性能问题做过大模型应用的人都知道生成式回答的延迟和成本永远是不可回避的痛点。虽然Fabric IQ背后有大厂的基础设施但在企业私有化部署场景下每次对话都去调用大模型API那费用和响应速度都是问题。我在项目中几乎都会加上一层语义缓存。原理不算复杂把“用户问题”经过归一化去掉停词、统一同义词后算出一个语义指纹存到Redis或类似的缓存里。下次来相似的问题先查缓存命中就直接返回之前的答案不再调用大模型。这里面有个细节值得展开什么叫“相似”不可能要求用户每次都一字不差地问同一个问题。“帮我看看华东区销售情况”和“华东区卖得怎么样”在字面上完全不同但语义指纹是接近的就该命中缓存。具体实现上我当时用的是Embedding向量余弦相似度匹配每次来新问题先把它转成向量和缓存库里的向量做相似度计算超过阈值就命中。为了控制缓存膨胀还会给每条缓存设置TTL一般15~30分钟比较合适既保证业务数据的时效性又不会频繁失效。缓存层还有一个额外的好处是能让你做分析路径追踪。用户问“华北区退货率”时如果走了缓存你至少能知道这个答案的原始分析链路是什么这对于后续审计和指标口径追溯都有帮助。4.3 数据权限在对话链路中的传递这个点我特别想强调因为它最容易在演示阶段被忽略一上生产就原地爆炸。在传统报表里权限是跟着报表走的。但在对话式分析里模型生成的SQL是动态的如果不做权限限制用户问“查一下所有客户信息”模型可能真的就去扫全表了。Fabric IQ的权限体系依赖三个层面的配合数据源权限OneLake的访问控制、语义模型权限指标和维度的可见性控制、以及LLM输出层的权限校验。我建议在生成SQL之后、执行查询之前强制加入一层查询改写逻辑拿到当前用户的上下文身份比如所属部门、职级把查询条件中自动加上该用户可访问的范围过滤。举个例子某销售总监问“本月排名前十的订单”系统查到他负责的是华东区那生成SQL时就要自动拼上WHERE region east_china。这个环节不能指望大模型自觉必须在代码层面强制拦截校验。4.4 预计算与增量刷新让本体跟上业务变化最后聊一个偏架构的问题本体不是建完就完事的它是需要持续维护的活物。业务部门的组织架构调整、新产品的上线、指标口径的变更都可能导致本体里的实体和关系过时。我在项目里通常会建一套增量同步管道定期从业务系统抽取变更日志经过解析后自动更新本体知识库的状态。清洗规则上优先保障幂等性不管同一个变更事件推送几次更新后的本体状态都必须是确定且一致的。实现方式可以在本体存储层加一张变更记录表以entity_id version为唯一键冲突时取版本号最高的那条。这里有一个我踩过很多次的坑不要用全量重建的方式来刷新本体。全量重建在大规模企业环境里耗时极长而且会打断正在运行的在线推理服务。正确做法是只对新增或变更的实体做局部更新并在更新完成后对比新旧版本的关键属性变化输出变更摘要供治理团队审核。5. 数据入湖与建模实操从原始表到可对话的语义资产5.1 数据入湖工程别在源头埋雷搞Fabric IQ这类平台实际动工第一天不是写代码调模型而是把数据源梳理清楚。我强烈建议项目团队一开始就做一次彻底的数据源盘点明确以下信息数据源类型数据库、API、文件、消息队列、数据量级、更新频率、质量状况、以及最主要的——这对业务意味着什么。入湖的工程标准我一般按四个要求卡第一格式统一。能转Delta Parquet的统一转不要又存CSV又存JSON又存老式Parquet后续做语义模型和本体时会痛苦到怀疑人生。第二变更捕获。尽量采用CDC机制捕获源系统的增量变化别天天全量抽取。全量抽取的数据管道跑起来很爽但一旦数据量上到TB级别调度和存储压力会把整个平台拖垮。第三敏感字段提前打标。身份证号、手机号、邮箱这些字段一进湖就要打上敏感标签后面Fabric的信息保护策略才能自动识别和控制访问。等数据已经广为流传后再补这道工序基本上就是亡羊补牢。第四时间戳统一。强烈建议所有入湖数据都统一使用UTC时间存储展示时再转本地时区。很多业务分析问题追到最后都源于时间字段的时区混用。5.2 语义模型的具体构建步骤语义模型的构建路径我不建议一上来就开搞中台那一套繁重体系。务实做法是选择一个核心业务域比如销售域作为试点从三张核心表开始做起。第一步确认事实表和维度表。事实表存业务过程比如订单表维度表描述业务环境比如客户表、产品表、区域表。第二步定义关键指标。和业务确认“销售额”“订单量”“客单价”这些指标的计算逻辑注意区分“有退款的销售额”和“已确认的销售额”同名不同义的情况特别多。第三步配置关系模型。在Fabric语义模型里建立事实表与维度表的关联关系并用行级安全对象RLS给不同角色配置可见范围。第四步发布并验证。让业务用户通过自然语言测试几个最常用的问题看模型给出的SQL和结果是否符合预期不符合就回头调整语义定义。这里给一个简单的语义模型JSON参考片段方便你理解这类语义层的描述方式{ model: sales_semantic_model, entities: [ { name: Order, type: fact, measures: { revenue: {expression: SUM(Order.Amount), format: currency}, order_count: {expression: COUNT(Order.OrderID), format: integer} }, dimensions: [ {name: Customer, roles: [buyer]}, {name: Region, roles: [ship_to]}, {name: Date, roles: [order_date]} ] } ], relationships: [ {from: Order.Region, to: Region.RegionID, type: many_to_one} ] }这段JSON描述的是“订单”实体包含两个指标收入、订单数和三个维度关联。后续本体层的实体描述会引用这套语义模型的特征大模型提问的时候就是在这个结构化的语义空间里去寻找答案的路径。5.3 本体构建的一些实操心得再往下到本体层很多团队就容易发怵因为“本体建模”这四个字听起来像学术论文课题。我的建议是别想太复杂本体建模的第一步就是能画出一张业务实体关系图就行。拿销售域举例组织单元OrgUnit—包含— 区域Region客户Customer—属于— 行业Industry客户Customer—发起— 订单Order订单Order—包含— 订单明细OrderItem产品Product—分类— 品类Category每一条关系都标注清楚关系语义是“组成部分”还是“依赖关系”是一个客户可以有多张订单还是一张订单只能归属一个客户。这些语义搞清楚了本体层的“骨架”就立住了。下一步非常关键为实体写一段自然语言描述。比如“区域”这个实体描述为“企业按地理范围划分的经营管理单元通常包含省、市、区县等层级”。不要小看这段描述它在做检索增强时会被直接拼进Prompt里是让大模型理解企业语境的关键素材。6. 模型微调与私有化部署本地大模型怎么和Fabric IQ协作6.1 微调还是RAG先想清楚你的问题分类在做技术选型时我一次次被问到“要不要微调大模型”。我的回答一般是先回答另一个问题——“你遇到的bad case是因为模型不知道还是因为模型知道但做不对”如果是模型不知道比如公司内部产品代号、专有术语、最新价格表那RAG就能解决加文档、加本体描述效果立竿见影如果是模型做不对比如输出格式不对、逻辑推理总是错那才需要考虑微调。Fabric IQ在做微调时通常采用LoRA这类参数高效微调技术只训练模型的一小部分参数几小时就能跑完一轮。具体步骤上我当时走的是收集高失败率的用户提问和对应正确答案整理成指令微调数据集。对答案做标准化处理确保格式统一。用LoRA在基座模型上做微调训练轮数控制在3轮以内避免过拟合。在验证集上对比微调前后的准确率和格式合规率。模型上线后持续收集新bad case进入下一轮迭代。这里要特别提醒一点微调不是越多越好企业场景里小而精的微调数据集比大规模通用语料有价值得多。一千条高度贴近业务的指令样本效果好过十万条网上扒来的通用对话。6.2 私有化部署的硬件与推理框架选择很多企业核心业务数据不能出内网这时候模型必须以私有化方式跑。硬件选型上我的经验是7B~14B级别模型用一张A10080G或消费级4090勉强能跑70B级别至少要两张A100/H100才谈得上稳定服务。推理框架上目前最主流的选择是vLLM和TensorRT-LLM。vLLM的PagedAttention机制能显著提升吞吐量在相同硬件下比原生推理能多支撑一倍以上的并发。如果追求极致低延迟TensorRT-LLM在NVIDIA硬件上的表现会更稳就是配置复杂度高一些。这里有一个容易被忽视的部署细节上下文长度Context Length的取舍。很多团队喜欢开长上下文以为越长越能装上下文但长上下文对显存占用和推理延迟的影响都是线性的。我在生产环境通常把上下文控制在8K~16K靠检索增强进关键信息而不是靠把全部文档塞进去。6.3 模型网关多模型协同的编排思路企业里不太可能只部署一个大模型。有些场景用轻量模型省钱有些场景用重推理模型才能答对。Fabric IQ在这一层应该承担“模型网关”的职责按规则把请求分发给不同模型。我采用的策略是简单查询“上个月销售额是多少”→ 走语义模型直接查询不调用大模型或者调用小模型做自然语言润色。中等问题“分析一下各区域销售变化”→ 调用7B~14B模型做NL2SQL和摘要。复杂任务“对比三个季度各产品线表现并给出建议”→ 调用70B甚至更大参数模型。涉及敏感数据“查询指定客户明细”→ 强制走私有化小模型或直接规则化处理。这套路由策略的好处非常明显成本可以下降至少40%响应速度也能有质的提升。真正的难点在于路由规则的定义和维护怎么样的提问算“简单”、怎么样的算“复杂”需要结合实际业务数据和用户行为持续迭代别指望一次就能定死。7. 企业落地Fabric IQ的五大雷区每一个都是我踩过的坑7.1 雷区一把本体层当成一次性建模项目很多团队把活干成“建完本体就验收验收完就没人管”。结果三个月后业务部门组织架构调整了一次本体的实体关系还停留在三个月前的状态大模型回答问题开始频繁出错。应对办法是把本体维护纳入常规数据治理流程每个迭代排期都要有专门的实体变更检查项。我甚至在团队里设了一个“本体小管家”的角色每周跑一次变更检测脚本输出一份实体变更周报。7.2 雷区二指标口径缺乏唯一责任人“销售额”到底是含税还是不含税“活跃用户”到底以登录还是以消费为准这类问题在传统BI里通过报表评审制度勉强能管住但在Fabric IQ里一旦语义模型定义错了所有大模型回答都会跟着错而且是错得非常自信。所以每一个关键指标必须指定一个唯一的业务责任人语义模型更新时必须经过该责任人审批。别觉得麻烦你后面减少的返工量绝对值得这点沟通成本。7.3 雷区三权限体系没有跟着数据走这也是我前面反复强调的问题。在会话式分析场景权限漏洞往往不是出在数据API上而是出在自然语言查询上——用户问出一个没被预料到的问法生成了超出权限的查询条件结果就把不该看的数据带出来了。我的实践方案是在语义模型层和LLM编排层双重校验语义模型层靠预定义角色限制LLM编排层靠查询改写强制过滤。两关都过了才真正执行查询。7.4 雷区四幻觉问题只靠Prompt解决如果你们测试环境里大模型经常把指标算错或编造业务事实第一反应不要只去调Prompt。Prompt优化能解决的幻觉有限真正要检查的是你给到模型的上文数据是不是足够精确。一个反幻觉的组合拳建议先走本体检索确保实体范围精确再走语义模型确保指标计算逻辑清晰最后在Prompt里明确写出“若上下文中无相关信息请直接说明不知道禁止猜测”。这一套组合下来幻觉率能降一大半。7.5 雷区五评估体系没有跟上没有评估体系的智能数据平台就是聋子的耳朵。用户觉得好不好用不能靠感觉必须量化。我建议至少采集四个维度回答准确率人工抽检或LLM-as-Judge打分、查询耗时、权限越权次数、以及用户的提问转化率问出结果后是否追问修正。建一个简单的评分看板每周Review一次问题才能尽早暴露平台才能持续进化。8. 常见问题速查表与分析链路优化技巧为了让团队里的小伙伴排查问题方便我整理过一张速查表也分享给你参考现象可能原因排查路径大模型答非所问本体检索召回不准确检查实体描述质量、相似度阈值查询结果明显错误语义模型指标口径不对复查指标计算公式、维度关联同一问题多次回答不一致模型随机性太强或缓存未生效降低温度参数、检查语义缓存命中率权限越权事件频发查询改写逻辑缺失检查LLM编排层是否有强制权限过滤响应速度慢模型参数过大或上下文过长考虑路由到小模型、压缩上下文微调后效果反而变差数据集噪声大或过拟合清洗指令集、减少训练轮数再分享一个优化分析链路的小技巧。大模型生成SQL后执行前可以先做一个静态SQL风险扫描查一下生成的SQL是否包含全表扫描、是否缺失WHERE条件、是否访问了不在用户权限范围内的表。这个环节可以用规则引擎实现也可以直接让一个小的LLM做二次校验。别小看这一步能拦截掉很多运行时才发现的问题省下的排障时间相当可观。9. 我的一些总结体会坦白说Fabric IQ这种平台目前仍处在快速进化期很多命名、模块边界和功能路线图都在变。今天我用“本体大模型平台”来描述它的形态可能过段时间微软又会给出更正式的产品名称和更完善的功能矩阵。但有一点是确定的企业数据平台从“存、管、用”走向“理解、推理、建议”的范式转变已经开始了。我自己的项目经验是转型成功与否技术选型只占三成剩下七成在于组织能不能把指标、本体、权限这些东西当作核心资产来运营。数据平台的建设本质上是在建一套关于企业业务的知识体系大模型只是让这套知识体系终于变得“会说人话”了。如果你正在规划这类项目我的建议是小步快跑不要等一切完美再上线。先选一个业务域把语义模型和本体建起来接上一个大模型跑通端到端对话式分析让业务用户用起来。收到真实反馈后再逐步扩展实体、优化模型、完善治理。大模型时代的项目慢了才是最大的风险。
