“context is too large and auto-compaction could not recover this”这句报错如果你还没遇过说明你还没被 AI Agent 逼到墙角。更常见的是另一个 400 错误——“this models maximum context length is 1048576 tokens”窗口都给到百万 token 了任务照样翻车。问题出在哪不是窗口不够大是我们根本不知道该怎么往窗口里装东西。这篇文章就围绕“上下文争夺战”这个话题展开聊聊为什么 prompt 工程正在让位给 context 工程以及微软为什么在这个时间点把 Fabric——那个既做湖又做仓还要做 BI 的统一数据平台——推到 AI 基石的位置上。无论你是做 AI 应用开发的、管数据平台的还是被老板要求“把大模型用起来”的决策者这套逻辑都值得从头捋一遍。1. 先聊聊“上下文”为什么突然成了兵家必争之地1.1 Token 窗口不是越大越好关键在“往里装什么”过去两年各家模型厂商把上下文窗口当军备竞赛打从最早的几千 token一路干到 128K、200K再到某些模型对外宣称的 1M 甚至更多。数字很好看但你真去跑一遍就知道窗口大和“好用”完全是两码事。首先是成本问题。Transformer 的注意力机制是平方级的窗口翻倍算力需求远不止翻倍。你每轮对话都把 80 万 token 塞进去响应慢、账单贵这些是实打实的代价。其次是“迷失在中间”效应——研究早就证明模型对长上下文首尾部分的关注度远高于中间部分你把一堆材料塞进窗口模型很可能忽略掉真正关键的那一段。我做过的测试里给足 200K 上下文让模型找藏在第 100K 位置的一句话十次有六次找不准。窗口再大装不进有效信息等于没有。所以企业里真正卡脖子的从来不是“窗口多大”而是“上下文从哪来、质量怎么样”。公司的知识分散在文档、数据库、聊天记录、邮件、报表指标里格式五花八门权限七零八落就算给你 1M 窗口你也没东西可装。那句 auto-compaction 报错其实就是这个困境的缩影上下文太大装不下系统自作主张压缩压完发现关键细节丢了恢复不回来。这是典型的“用模型的应急机制掩盖数据工程缺失”。1.2 从 Prompt 工程到 Context 工程下一站是数据早期大家玩 AI比拼的是 prompt 怎么写——“请你扮演一个资深分析师”“请一步步思考”。这套东西在单轮、小上下文场景下确实有用但放到真实业务里很快就到瓶颈。原因很简单prompt 决定模型“怎么想”context 决定模型“知道什么”。一个再优秀、再会推理的模型拿到的信息是错的、旧的、残缺的它也只能一本正经地胡说八道。我认识的做 AI Agent 的团队今年基本都在聊同一个词context engineering。说白了就是一套系统性的方法决定哪些信息该进上下文、以什么粒度进、按什么顺序排、如何保证新鲜度和正确性。这活儿本质上更像是数据工程而不是写提示词。你要设计的不再是“请回答”三个字而是一条完整的链路数据接入、清洗、分块、向量化、检索、排序、压缩、权限过滤。多 Agent 协作场景下更麻烦每个 Agent 带自己的上下文彼此还要共享状态、对齐记忆这已经从“窗口问题”升级成了“协调问题”。而协调问题恰恰是数据平台的老本行。所以我说上下文争夺战的真正战场不在模型层在数据层。谁能让企业把散落的数据变成高质量、可治理、随取随用的上下文谁就掌握了 AI 落地的命脉。微软把 Fabric 推出来针对的就是这个位置。2. Fabric 是什么以及它凭什么站在 AI 基石位置2.1 Fabric 的本质把湖、仓、BI、实时分析揉进一个 SaaS先给不熟悉的朋友补个背景。Microsoft Fabric 是微软 2023 年发布的统一数据平台它的野心是一站式替代你手里那一堆割裂的工具。过去你要搭数据栈通常得拼好几样东西对象存储放原始文件数据仓库跑 SQLETL 工具做调度BI 工具出报表还得单独搞一套实时流处理。Fabric 把这些全部收编成一个 SaaS 产品底层共用同一个存储——OneLake上层挂载不同的计算引擎。它内部的主要组件我列个表你会发现每个组件都能在“上下文生产过程”里找到对应角色Fabric 组件干什么的在上下文链路里的角色OneLake统一逻辑数据湖底层是 Delta-Parquet 格式上下文原始素材的存放地Lakehouse湖仓一体Spark 做批处理和机器学习清洗、分块、向量化处理的执行环境WarehouseT-SQL 分析引擎支持完整的 SQL 语义让 AI 通过“问 SQL”拿到精确上下文Semantic ModelsPower BI 语义模型定义指标和关系把业务口径固化成 AI 能消费的上下文Real-Time IntelligenceKQL 数据库、事件流处理给上下文提供实时新鲜度Data Factory数据接入和编排管道定时把散落数据汇入上下文底座Data Activator数据驱动触发动作根据上下文变化自动触发下游决策这套结构最核心的设计是“一份数据多种引擎”。以前的数据架构数据要从业务库复制到数仓再从数仓导出到数据集市每一层复制都带来一致性问题。Fabric 的思路是数据在 OneLake 里只放一份湖、仓、BI、实时分析各自用自己的引擎去读这一份数据。对 AI 场景来说这意味着你的上下文来源是统一的、单一版本的不会被中间环节搞出多个口径打架的“平行宇宙”。2.2 微软的算盘上下文争夺战的胜负手是“可信数据”微软这套组合拳其实逻辑很清楚。AI 要落地到企业三样东西缺一不可模型、算力、数据。模型是 OpenAI 的算力是 Azure 的数据底座就是 Fabric。Fabric 对微软的战略意义不是多卖一个数据产品而是把“数据准备”这个最脏最累最关键的环节牢牢绑定在自己的平台上。你仔细看会发现Fabric 和市面上纯做数仓或者纯做湖的公司有个显著差异它自带语义层。这个东西被很多人低估了。语义模型是 Power BI 的核心资产里面定义了“毛利率怎么算”“活跃用户是什么口径”“订单金额含不含税”这类业务规则。过去这些规则只用于出报表但放到 AI 场景里它们的价值被放大了——因为 AI 最怕的不是不会推理而是拿错口径去推理。你让 AI 回答“本月毛利率为什么下降”如果它自己翻一堆原始表很可能把含税和不含税混在一起算。但如果 AI 直接基于语义模型来回答它消费的是财务团队确认过的指标定义。从这个角度看微软真正推的不是一个数据仓库而是把企业里最值钱的东西——被验证过的业务知识——变成 AI 的上下文资产。还有一个容易被忽略的点治理即上下文边界。Fabric 把权限模型统一到了 OneLake 层面行级安全、列级安全、工作区权限都集中管控。这意味着 AI 能拿到的上下文天然受用户身份过滤。同样是问“这个客户最近表现怎么样”销售总监能看到完整画像普通客服只能看到公开信息。这种“权限即上下文”的设计解决了企业上 AI 最头疼的数据泄露问题。自建 RAG 的时候权限往往是最难补的一环而在 Fabric 里它是底座自带的能力。3. 把上下文变成可治理资产Fabric 的几条核心路径3.1 RAG 的工程化向量检索只是入场券当前最主流的给 AI 提供上下文的方式还是 RAG检索增强生成。但真正的企业级 RAG 远不是“文档切一切、向量存一存、问的时候搜一搜”这么简单。Fabric 在这条路径上的优势是可以把 RAG 全流程做成一条可治理的数据管道。常规做法是这样的文档从 SharePoint、ADLS、SAP 等源头进来通过 Data Factory 管道进入 OneLake落到 Lakehouse 的 Delta 表里。然后一个 Spark Notebook 跑批处理任务做清洗去重、按语义切块、调 embedding 接口生成向量再把「原文块 向量 元数据 来源路径 更新时间」一起写回另一张 Delta 表。到查询阶段用户问题向量化后在向量索引里做相似度检索取回 Top-K 块连同问题一起拼成 prompt 送给大模型。这套流程用自建方案也能做但 Fabric 的价值在细节每一条上下文都有血缘关系能从回答一直追溯到原始文件每一次管道更新都有版本记录能知道上下文是几点刷新的每一块数据都有权限标识检索结果先过权限过滤再进 prompt。我见过太多团队把 RAG 做成“能跑就行”的 Demo聊天机器人确实会回答了但回答错了没人能追责、数据更新了系统还在用旧知识、跨部门共享时权限完全失控。这些问题在 Fabric 上是架构级解决的不需要你额外开发。3.2 语义模型让 AI“读懂”指标而不是翻文档RAG 擅长处理非结构化知识但企业决策大量依赖结构化指标。这时候继续用 RAG 就有点拧巴——你让 AI 去检索一份 100 页的财务分析报告不如让它直接查一个语义模型来得准。Fabric 里 Copilot 可以直接连语义模型回答问题。你问“华东区本季度毛利率环比变化多少”系统不走文档检索而是把用户问题翻译成语义模型查询由 Power BI 引擎计算出准确数字再把数值和上下文组装给大模型组织语言。这里妙的地方在于上下文被“计算”出来了而不是被“检索”出来了。每一次回答都等于实时跑了一遍指标计算不存在文档没更新导致的不一致。这条路径还有个好处就是它天然契合“口径治理”。指标怎么定义、归到哪个维度、如何聚合全部沉淀在语义层里。AI 只是消费方不能自己发明口径。对企业来说这比让 AI 自由发挥重要得多。我甚至觉得语义模型才是 Fabric 在上下文争夺战里最锋利的武器因为它把数据团队多年积累的业务知识直接变成了一种可被 AI 调用的标准化上下文接口。3.3 实时上下文从静态知识库到动态决策RAG 的另一个通病是时效性。文档知识库刷得再勤也是某一时刻的快照。但在库存管理、订单监控、故障响应这类场景里上下文每秒钟都在变静态检索根本撑不住。Fabric 的 Real-Time Intelligence 补的正是这块。事件流接入后进 KQL 数据库通过 KQL 做流式查询聚合AI 应用可以拿“最近 5 分钟的交易异常数”“当前积压工单量”这种实时指标作为上下文。再配合 Data Activator还能做到上下文一变就触发动作——比如某个指标的上下文显示异常自动通知对应负责人或者触发修复流程。跟我之前强调的点一致这里的上下文不是从哪个文档里翻出来的而是从实时数据流里算出来的。静态知识 实时指标 历史趋势三者拼在一起AI 才能从“会聊天”进化到“会决策”。3.4 权限即上下文边界别等出事再补最后单独拎出来说权限。自建上下文管道的团队最痛苦的就是把企业身份体系和检索系统对接——你得让检索结果按提问人的权限过滤还得处理群组继承、行级安全、临时授权。稍微疏忽轻则答错重则数据泄露。Fabric 因为存储和计算在同一套安全体系里上下文检索天然继承 OneLake 权限。一个用户通过 Fabric 接口发起查询系统按该用户在 Fabric 里的权限过滤数据他看不到的行AI 的检索结果里也不会出现。这点在医疗、金融这类强合规行业几乎是刚需。我在实际项目里见过的教训是别高估自己团队的权限管控能力也别低估监管审查时“AI 为什么能回答出这个数”的追问压力。能靠平台能力解决的安全问题尽量不要自己造轮子。4. 自己搭还是用 Fabric一条实用的选型路线4.1 自建 Context Pipeline 的隐性成本很多团队一开始都倾向于自己搭。组件都现成LangChain 或者 LlamaIndex 做链路编排Milvus、Redis、pgvector 做向量库OpenAI 或者开源模型做 embedding再找个对象存储放原始文件。跑通一个 Demo 真的不难我见过一个实习生两天就搭出来。但往上走隐性成本就一个一个冒出来了。文档解析和分块策略这件事就能耗掉你几周PDF 里的表格怎么保留结构、代码仓库怎么按函数切、多语言文档怎么处理、重复内容怎么去重。接着是 embedding 模型升级之后要不要全量重新向量化不重算的话新旧向量不一致检索质量飘忽不定。再往后是权限同步——业务系统的组织架构一变你的检索系统就得跟着变不然离职员工的权限还在。更别提数据新鲜度源系统更新了你的管道能不能及时感知并重算向量把这些罗列完你会发现在企业场景里RAG 的核心工作量根本不在“检索”而在“数据治理”。自建等于把这一整套治理能力重新发明一遍。Fabric 至少把接入、存储、调度、权限、血缘这些基础设施问题打包解决了你只需要关注业务本身。4.2 什么情况选 Fabric什么情况别硬上我梳理了一个粗略的判断框架供你真做决策时参考维度自建 Context PipelineFabric Azure OpenAI数据治理成熟度需要自己补齐权限/血缘/审计平台内置开箱即用团队技能栈需要算法工程数据全栈熟悉 SQL/Spark 即可上手与微软生态耦合不依赖强依赖看现有资产实时上下文支持要自己接流处理和时序库Real-Time Intelligence 内置业务口径统一需要自己维护指标层语义模型天然承载初始成本低但人力持续投入容量计费前期要研究定价灵活性高可以随意替换组件受限必须按平台设计使用我的倾向性建议是如果数据已经大量存在于微软生态——SharePoint、ADLS、SQL Server、Dataverse——那用 Fabric 几乎是顺理成章的因为你省掉的不仅仅是一个存储桶而是整套身份体系和数据管道的对接工作。反过来如果公司有强制开源要求或者已经在 Databricks/Snowflake 上砸了重金那也别硬迁Fabric 不适合用来证明自己“跟上了趋势”。上下文工程没有银弹关键是选一个和你的现实资产匹配的底座。4.3 成本不能只盯订阅费Fabric 按容量计费看起来是个订阅价实际用起来要看吞吐量、Spark 作业、查询并发、实时流处理这些消耗项。我第一次跑 POC 的时候低估了 notebooks 刷数据的资源占用账单超出预期不少。经验是先把数据量、作业频率、并发用户数三个数估准再对照微软官方的容量计算器推一下 CU容量单位需求最后还要留出试错空间。另外把不需要常驻的计算资源及时暂停Fabric 的弹性其实能帮你省不少钱前提是你得养成“用完即释放”的习惯。5. 落地实践把一套 Fabric 上下文系统跑起来5.1 一个最小可行方案长什么样理论聊再多不如跑通一遍。我拿一个最常见的场景举例企业内部知识问答助手。最小闭环分五步。第一步接入数据。用 Data Factory 建一条管道把公司知识库里的文档从 SharePoint 或者 ADLS 同步到 OneLake。这一步别贪多先选三个业务部门的高质量文档把管道跑通再说。第二步建 Lakehouse 和科室表。在 Fabric 里新建 Lakehouse把同步进来的原始文档落到一个 bronze 表字段至少包含文档 ID、文件名、内容、来源路径、更新时间。第三步写 Spark Notebook 做分块和向量化。核心逻辑大概是读取 bronze 表、按固定块大小切分我习惯 800 token 一块、重叠 100 token、调用 embedding 服务的 Python SDK 生成向量、连同原文块和元数据写回 silver 表。代码骨架长这样from pyspark.sql.functions import udf, col from pyspark.sql.types import ArrayType, FloatType # 假设你已经配置好 Azure OpenAI 的 endpoint 和 key def embed_text(text: str): resp openai_client.embeddings.create( modeltext-embedding-3-large, inputtext ) return resp.data[0].embedding embed_udf udf(embed_text, ArrayType(FloatType())) bronze_df spark.table(bronze_docs) chunks_df bronze_df.select( col(doc_id), col(file_name), chunk_text(col(content)).alias(chunk), col(source_path), col(updated_at) ) silver_df chunks_df.withColumn(embedding, embed_udf(col(chunk))) silver_df.write.mode(overwrite).saveAsTable(silver_doc_chunks)第四步做检索和问答。用户提问后用同一个 embedding 模型把问题向量化然后在 silver 表里算余弦相似度取 Top 5 块拼进 prompt调用大模型生成回答最后把引用的文档路径附在答案后面。这一步可以用 Fabric 的 Notebook 快速验证也可以直接用 REST API 包一层服务暴露给前端。第五步加一层权限校验。检索出候选块后在返回给大模型之前先用用户的 Fabric 身份做一次过滤保证他无权访问的数据不会进入 prompt。这一步千万不能省。5.2 实测中遇到的那些坑这套方案跑通不难但跑到生产环境你会遇到几个典型的坑我逐个说。第一个坑是分块策略。切太细语义被切碎检索召回一堆碎片切太粗块里混着无关信息embedding 向量被稀释。我的经验是跟你的实际文档类型强相关不能照搬网上参数。建议先拿 50 篇代表性文档用三四种块大小各跑一轮检索对比命中质量再定。第二个坑是 embedding 版本漂移。你刚开始用 text-embedding-3-large后面可能想换更强的模型或者同一个模型升级了版本向量空间可能都不一样旧向量和新向量不能混用必须全量重算。所以从第一天起就要在表结构里记录 embedding 模型名称和版本方便回溯。第三个坑是 token 预算。Top 5 块看起来不多但每块 800 token 就是 4000 token再算上 system prompt 和历史对话一轮请求很快就吃掉大几千 token。我后来改为先按相似度取 Top 20 块再用一个轻量 rerank 或者直接让大模型对块做一次粗筛只保留最相关的两三块进最终 prompt质量反而更稳成本还降了。第四个坑是数据新鲜度。管道建好了但如果只在初始迁移时跑一次一周以后回答就开始过时。我给自己的项目定了规则关键知识库每天早上七点增量刷新一次低频文档每周刷一次并且把每个块的更新时间写进元数据检索时可以对太旧的内容降权。5.3 我的一些体会踩过这些坑之后我最大的体会是别把上下文当 prompt 问题来解要当数据平台问题来解。很多人一上来就调模型、调提示词反复试几次觉得效果不行就换模型其实根子上的问题往往是上下文的质量、新鲜度、权限边界没做好。Fabric 把我以前要自己拼装的数据治理能力变成了一体化的平台底座让我能把更多精力放在业务问题的定义上。还有一点特别想分享上下文工程做深了之后你会发现“语义模型”才是真正的长期资产。向量库可以被替换模型可以升级换代但一套经过业务验证的指标口径是越用越值钱的东西。微软把 Fabric 推上 AI 基石的位置表面上是押注数据平台本质上是在押注“上下文最终会沉淀为企业核心资产”这件事。我觉得这个方向是对的至少在我自己的实践里把上下文当成数据资产来经营比把它当成 prompt 片段来拼凑带来的复利要厚得多。