1. 合作探索的背景AI公司遇上建筑央企到底在谈什么接手“范式智能中建方程”这个合作探索项目之前我其实花了不少时间想一个问题AI大模型这两年火得不行但真正落到传统行业里、能跑通闭环的案例到底有多少尤其是建筑这类产业链长、参与方多、数据标准乱的行业AI到底能帮上什么忙这个项目给了我一个很好的观察窗口——它不是那种“签个战略协议拍张合影就结束”的务虚合作而是双方实打实地坐下来把业务场景一个一个摊开讨论哪些地方现在就能用AI提效哪些地方还得再等一等。先交代一下背景。范式智能这边核心能力是自研的行业大模型、AI Agent编排框架和私有化部署方案跟那种只提供一个API接口的通用平台不一样我们更擅长在客户已有的系统里“长”出AI能力。中建方程则是建筑行业里业务链条相当完整的平台型企业从项目投资、规划设计到工程建设、运营管理都有涉及。这种企业最大的特点是什么数据量巨大、文档巨多、流程巨复杂但日常工作中大量时间被耗在“找资料、写报告、审合同、盯进度”这些重复性劳动上——这恰恰是AI大模型最擅长解决的事情。这次合作探索的目标不是一上来就要搞什么“AI取代项目经理”这种大新闻而是做三件事第一把建筑业务里适合AI介入的场景梳理清楚排优先级第二选定两到三个场景做技术验证PoC用真实数据跑通流程第三把验证结果变成可以复用的工程方案供后续规模化推广。整个项目持续了大概八周节奏是两周需求调研、三周PoC开发、两周试运行、一周复盘总结。这篇文章就是把这八周里踩过的坑、验证过的方法、整理出来的场景清单原原本本分享出来。对于正在做To B AI落地、或者所在企业正在考虑引入大模型能力的朋友里面很多细节可以直接参考。2. 需求盘点与场景收敛建筑行业的AI需求不是太少而是太散2.1 别被“AI能做的太多了”带偏节奏首次需求调研会业务部门提了快四十个想法智能审图、进度预测、材料价格分析、劳务管理、安全巡检、合同审查、知识问答……每个听起来都合理但真要全做团队几个月都不够。这里就暴露出To B AI项目最典型的陷阱——需求发散。后来我们做了一个动作把四十个需求全部拉进一张评分表里从四个维度打分——数据可得性、业务价值、技术成熟度、实施成本每项1到5分最后按总分排出梯队。最后真正进入PoC阶段的只有四个场景制度文档智能问答、安全巡检隐患识别、工程合同风险审查、经营数据自然语言查询。这四个场景有一个共同特征数据基础相对干净、流程边界清晰、业务方有明确的使用意愿。反过来像“AI自动编制施工组织设计”这种需求虽然价值高但涉及多专业协同和大量非结构化知识短期内很难做到可用状态只能放进中长期规划。2.2 建筑行业AI需求的三个真实层次需求收敛之后我发现建筑企业的AI需求其实可以分成三个层次这个分层对后面做技术方案特别有用。第一层是知识密集型场景典型代表是制度问答和合同审查。建筑企业积累了海量的制度文件、技术标准、合同范本、历史标书这些东西散落在各业务部门新员工找不到老员工凭记忆办事知识没有变成资产。AI在这里的定位是“知识放大器”把积累的经验结构化、可检索化。第二层是流程密集型场景典型代表是进度预警和文档流转。这类需求要求AI不只是回答一个问题而是嵌入业务流程里和现有的PM系统、OA系统做打通。比如进度计划一旦滞后超过阈值AI自动生成分析报告并推送给相关责任人。其实施难度比第一层大不少因为涉及系统对接和权限模型。第三层是决策辅助型场景典型代表是经营分析。领导想看的“本月回款情况怎么样”“各个区域的利润率对比”本质上是要在大模型和结构化的业务数据之间搭一座桥。这一层次的技术难点已经不在模型本身而在于指标口径的对齐和自然语言到查询语句的转换准确性。这次合作探索最终确定为“121”格局也就是一个知识类场景、两个流程类场景、一个分析类场景目的就是让技术验证覆盖三种不同难度层级既能快速拿到成果又能测试团队的深度交付能力。3. 技术方案选型为什么是大模型底座加Agent编排加RAG的组合3.1 模型选型的取舍逻辑方案设计阶段第一个绕不开的问题是用哪个大模型做底座我们当时对比了三个方向通用开源模型比如Llama系列、Qwen系列、商业API模型、以及基于开源模型微调后的垂直模型。对比结论非常明确这个项目必须做私有化部署原因不在技术而在数据合规——建筑企业的合同、图纸、经营数据都属于敏感信息不可能送到外部API去处理。所以路线直接锁定在开源模型加私有化部署这个方向上。模型参数规模方面我建议从70亿7B到140亿14B这个区间开始试这个量级的模型在配备一块主流显卡的服务器上就能跑起来单次推理延迟控制在1到3秒之间对于文档问答、报告生成这类非实时交互场景完全够用。关于要不要做微调我的经验是第一版千万别做微调先用RAG。原因很简单建筑行业的专业知识庞杂且更新频繁微调的成本高、周期长而且很容易训完就“旧了”。RAG方案在架构上天然适合这种需要持续更新知识库的场景后续只要更换知识库数据不需要重新训练模型。3.2 RAG流水线的关键节点设计RAG检索增强生成听起来不复杂就是“先检索再生成”但实际搭出来的效果天差地别差距全在细节里。我们的RAG流水线分四段文档解析、切片、向量化、检索排序。文档解析是第一个坑。建筑行业的制度文件大量是PDF而且是扫描件、表格混排、页眉页脚一大堆。直接用常见的解析库经常把表格拆得七零八落。我们后来用的方案是先做OCR识别再按版面结构还原最后针对不同类型的文档走不同的解析策略。制度类文件按章节层级切技术规范按条目切合同文本按条款切。切片长度我实测下来256到512个token之间效果比较好太长检索不精准太短上下文割裂。向量化阶段要选嵌入模型这里有个经验通用领域的嵌入模型在建筑专业术语上表现一般比如“桩基”“围护结构”“认质认价”这些词如果只做常规向量化检索召回率会明显偏低。我们通过补充一个专业词典在切片阶段对关键术语做了权重增强召回率从71%提到89%。检索排序我也强烈建议加一层重排序。向量相似度检索出来的Top20结果里往往有三到五条是“看起来像但实际没用”的干扰项。用一个轻量级的交叉编码器做重排序把最相关的内容顶到前面生成的答案质量会有质的提升。3.3 AI Agent的编排思路这次合作探索里“智能体”不是概念包装而是实打实的工程组件。我们的Agent框架负责三件事任务分解、工具调用、记忆管理。举个例子用户问“今年一季度公司在施项目的安全巡检情况怎么样”一个完整的Agent行为链条是第一步调用意图识别模块判断这是一个数据查询任务第二步调用自然语言转查询工具把问题翻译成结构化的数据查询语句从安全管理系统里拉取巡检记录第三步把结构化数据转成摘要文本第四步调用报告生成模块输出一段带统计口径说明的文字。这四步如果不用Agent编排而是写成死流程任何一个环节的输入格式发生变化就全盘崩溃。Agent的价值恰恰在于它能在运行时动态选择工具路径容忍输入的不确定性。记忆管理方面我们给每个业务角色配置了独立的会话记忆空间。比如安全员问过的问题、看过的报告会被记住下次提问时可以直接说“和上次一样把最新的加上”不需要重新描述一遍筛选条件。这个细节对业务方的好感度提升非常明显。4. 核心场景实操四个场景从设计到跑通的完整记录4.1 制度文档智能问答知识库从搭建到调优第一个场景是制度文档智能问答面向的是公司全员。企业内部的制度体系往往几十万字起步从行政管理办法到质量安全管理制度分散在OA系统、共享盘、甚至个人电脑里。员工平时问“报销标准是多少”“请假流程找谁审批”没有任何一个入口能快速给出准确答案。这个场景的落地分四步。第一步是数据归集和行政部门配合确认制度文件的唯一权威版本清单把过期的、作废的、互相矛盾的文件先清理掉。这一步最费时间但绝对不能省因为垃圾进垃圾出知识库如果混入大量过期制度AI给出的答案就是错的还错得理直气壮。第二步是文档解析和切片。我一直强调一个观点——建筑行业的制度文档解析质量决定了问答质量。我们遇到的一个典型问题是制度条款里大量使用“原则上”“特殊情况除外”这类限定性表述如果切片时把限定条件切丢了AI就会给出片面答案。解决办法是把“条款限定词例外说明”作为一个不可分割的语义块整体入库。第三步是问答效果调优。建完知识库后我们从业务部门收集了300个高频问题做评测覆盖费用报销、招采流程、人事制度、安全管理四类。第一轮测试的通过率只有62%主要有两个问题一是关联词检索不到比如用户问“出差住宿能报多少钱”制度原文写的是“差旅费管理办法”模型没把“住宿”和“差旅”关联起来二是答案不完整模型只回答了报销标准没带上“需附发票原件”的限定条件。针对问题一我们扩充了同义词映射表把“住宿”“路费”“补贴”等常见口语词映射到制度原文用词针对问题二优化了提示词模板要求模型在给出结论时必须附带原文出处和限定条件。调整后第二轮的通过率提到85%。第四步是上线试运行。这里有一个容易被忽略的点AI问答工具上线后的反馈闭环。我们在前端页面加了一个“答案是否有用”的点赞点踩按钮同时要求业务部门每月提交一批新的高频问题补充进评测集。这个机制保证了知识库不是一次性工程而是持续生长的系统。4.2 安全巡检隐患识别图像模型加文本模型的组合拳第二个场景是安全巡检隐患识别。建筑工地的安全管理是所有施工企业最头疼的事之一传统的巡检模式是安全员现场拍照、手写记录、回办公室录入系统一个隐患从发现到闭环少说两三天而且照片和文字描述经常对不上。我们设计的方案是用计算机视觉模型对现场照片做初筛识别出未戴安全帽、临边防护缺失、材料堆放杂乱等高频隐患类别然后用大模型将现场照片和语音记录自动转成结构化的隐患描述包括隐患位置、类别、风险等级、整改建议直接推送到隐患管理系统生成整改单。这里有个技术细节值得展开视觉模型的识别能力不是一开始就能覆盖全部隐患类别的。我们和安全管理部一起把过去两年积累的三万多张现场照片全部翻出来标注了十六类常见隐患用其中一万张做训练两千张做验证。第一版模型在类内准确率能做到91%但在跨项目的泛化测试里掉到了78%。原因是不同项目的工服颜色、围挡样式、光照条件差异太大。后来我们加了数据增强把训练集里各种场景的照片做了亮度扰动、色彩偏移、尺度变化泛化准确率拉回到了86%。文本生成那侧最大的挑战是语音转文字的准确率。工地现场嘈杂安全员的口述经常夹杂着“那个地方”“就那什么”这类指代词。我们的处理方式是在提示词里加入规则约束要求模型遇到指代不清的信息时必须以“待核实”标记而不是自动脑补。这个设计是为了保证AI生成的内容可以追溯到现场真实情况宁可让细分发“待核实”让安全员补填也不能编造隐患位置。4.3 工程合同风险审查从“人肉通读”到“人机协同”合同审查这个场景是建筑企业里业务价值最直观的一个。一个项目从投标到履约涉及的合同可能有几十份动辄几十页到上百页法务人员通读一遍至少三四天而且人眼审查很难保证条款覆盖的完整性。我们的方案是把审查流程拆成三步。第一步合同文本解析从PDF中抽取关键条款包括付款条款、违约责任、工期约定、变更签证流程等建立合同要素结构化的数据表第二步风险规则匹配维护一个建筑行业合同风险规则库每条规则对应一个风险模式和判定逻辑。比如“付款比例低于行业惯例”“违约金上限设置异常”“知识产权归属约定缺失”每命中一条规则就生成一条风险提示第三步汇总生成审查意见书输出风险清单、对应条款原文、修改建议提交给法务人工复核。落地过程中的核心难点有两个。难点一是规则库的建设。建筑合同的风险点有很强的行业属性通用AI模型不可能覆盖到“固定单价合同与可调价格合同对材料价差调整方式的不同约定”这种细颗粒度问题。我们和公司法务部门做了四轮工作坊共同整理出一份包含120条规则的初版风险库后续每审查一份合同法务补充一条新规则。这种“规则库持续生长”的机制是保证审查准确率持续提升的关键。难点二是大模型抽取条款的准确性。让大模型从长达六十页的合同中准确抽取“付款节点和比例”这类信息并不像想象中那么可靠。我们做了字段级的置信度评分——置信度低于阈值的字段单独标记为“需人工确认”不让模型硬着头皮给答案。实测下来合同要素抽取的整体准确率做到94%左右剩下6%的人工兜底整体效率比纯人工通读提升了三倍以上。4.4 经营数据自然语言查询给业务指标装上对话接口第四个场景是经营数据查询。建筑企业的经营管理部门每天要做大量报表汇总和分析但数据分散在财务系统、项目管理系统、供应链系统里口径还不统一。领导问一句“今年各区域公司的产值完成率”下面的人可能要翻三个系统、对四个口径、折腾半天才能给出一个还不一定准的数。我们用AI-Agent架构做了一个数据对话助手核心是文本转查询加指标口径管理。思路是这样的先把企业里常用的经营指标全部梳理出来每个指标定义清楚它的计算公式、数据来源、统计周期、业务口径形成一份指标字典然后当用户用自然语言提问时Agent先解析用户意图把问题映射到指标字典里对应的指标再生成查询语句到对应系统里取数最后把结果转成带口径说明的自然语言回答。这个场景的难点在于口径解析。举个例子“回款率”在不同部门理解完全不同财务部门算的是“实际到账金额除以合同金额”运营部门算的是“本期回款除以本期应收”。同一个词指标字典里必须区分出不同口径并标注适用场景Agent在回答时要明确告诉用户“按财务口径统计的回款率为82%”避免歧义。技术实现上自然语言转查询的准确率是核心指标。我们第一版用大模型直接生成查询语句准确率只有76%大量时间浪费在生成后调试上。后来改成结构化方案先做指标匹配把用户问题映射到不超过三个候选指标再基于指标的预定义查询模板做参数填充准确率直接跳到93%。这个对比很能说明问题——在To B场景里不要指望大模型什么都能直接生成给它搭一个结构化的脚手架效率和稳定性会好很多。5. 实施过程中的典型问题与排查经验5.1 数据质量问题的“三查三看”整个PoC过程中我们踩得最多、也最深的坑全部集中在数据质量上。建筑行业的数据系统往往是多年演进出来的历史遗留问题非常多同一个项目名称在合同系统里叫“XX项目一期”在财务系统里叫“XX项目A区”在进度系统里叫“XX标段”。系统之间数据拉通全靠人工适配AI一进来直接面对这些数据问题全暴露了。我的处理经验总结成“三查三看”查字段完整性、查数值合理性、查主键唯一性看数据更新的新鲜度、看空值的分布规律、看不同系统之间的口径差异。这套检查在每一类数据接入前都必须做一遍宁可多花两天做数据治理也不要带着脏数据上线。而且数据质量问题要在项目一开始就拉上业务部门一起看因为只有业务部门知道“哪个系统里的数是管用的”技术人员自己猜是猜不出来的。5.2 模型幻觉在严肃业务场景里的治理手段大模型的幻觉问题在建筑这种严肃行业会被放大——合同审查里如果AI漏掉一条关键风险条款法务基于错误输出签了字那责任算谁的所以我们在所有场景里都坚持“结果可溯源”这个原则。治理手段分三层。第一层是提示词约束要求模型在输出答案时必须有引用来源没有把握的信息必须明确说“未找到相关依据”禁止编造。第二层是流程约束所有涉及业务决策的输出在系统设计上必须经过人工确认环节AI只做“初稿生成”和“风险提示”不做“自动裁决”。第三层是知识库约束通过RAG把模型生成的内容锚定在检索到的段落上答案在逻辑上必须和知识库内容匹配。这套组合下来幻觉没有完全消失——坦白讲以当前大模型技术能力不可能做到零幻觉但它被有效限制住了。我们的评测基准将“事实性错误率”从初期的18%压到了4%以内这个水平在辅助类场景里是可以接受的。5.3 私有化部署的性能与成本平衡模型部署这块开头提到的7B到14B参数规模方案实际执行时踩了一个性能坑。我们最开始选的7B模型在单机GPU环境下跑得很流畅但并发一上来六七个用户同时提问响应延迟直接从1.5秒暴涨到8秒。后来拆开排查发现不是GPU算力不够而是推理框架的并发配置没调好。解决办法是把推理服务拆成“在线问答”和“离线批处理”两条链路在线问答走低延迟推理通道动态批量优化后并发响应控制在2到3秒内离线批处理比如批量生成巡检报告、批量合同初筛走单独的任务队列可以接受几分钟级别的延迟。这个架构调整之后同一台物理服务器支撑的在线并发能力提升了三倍硬件成本一分钱没多花。算力的精神就是“够用再扩容”——先跑通业务再根据真实的并发曲线决定要不要加机器而不是一开始就按满配采购。6. 合作推进中的实战经验与个人体会6.1 甲方乙方协作的节奏把握To B的AI合作项目技术能力只是成功的一半跟业务侧的协作节奏决定了项目能不能持续走完。这次合作探索我们有几个经验值得记录。一是每次评审会都要把“AI能做什么”翻译成“业务能省多少时间”。业务领导不关心你用了什么模型调了什么参数他们只关心能不能减少加班、降低差错、加速流程。我们汇报时统一用“原来完成一项合同初筛需要多少人工小时现在需要多少人工小时”这种颗粒来呈现沟通效率高了很多。二是业务部门要有一个专职对接人。AI落地项目最怕的就是需求方只是“配合调研”结果开发到一半业务方说“这个流程不是这样的”。后来我们争取到了每个应用场景对应的业务部门派一名骨干全程参与这个人同时懂业务逻辑和数据细节能在第一时间把业务侧的反馈转化成技术可执行的需求变更。三是PoC的范围必须用文字锁定。合作探索阶段最忌讳“范围蔓延”业务方今天说“既然能做合同审查那顺带把投标文件审查也做了吧”明天说“这个数据查询能不能再加一个报表模块”。我们不拒绝新需求但统一登记到后续迭代的待办池里当前阶段只做已确认范围内的事情。这样对双方都有保护项目不至于失控。6.2 对AI赋能建筑行业的一些判断八周项目下来我对AI赋能建筑行业这件事有了更清晰的判断。建筑行业的数字化基础确实比互联网行业薄弱但恰恰因为薄弱AI带来的边际提升反而更明显。一个已经高度数字化的行业AI可能只是锦上添花而一个大量依赖人工经验的行业AI直接补齐的是经验和知识的代际传递。但也别把AI神话成一夜之间颠覆行业的东西。真正能落地的路径一定是先从一个具体的、高频的、业务方有痛感的场景切入做出让人看得见摸得着的效率提升再逐步扩展。这次合作探索里制度问答和合同审查这两类场景之所以最能出成果正是因为它们对应的是每天都发生、人人都能感知的事情。6.3 后续扩展的几个方向项目复盘时我们和业务方达成了三个后续扩展方向的共识。第一个是建设企业级的AI知识中台把散落在各业务系统的知识资产统一接入避免各部门重复建设知识库。第二个是完善多智能体协作框架从单一场景的Agent走向跨场景的Agent编排比如安全巡检发现的隐患自动联动合同审查里的相关责任条款。第三个是探索建筑行业垂直模型的持续训练机制用积累的项目数据做领域增强让模型越来越懂建筑行业的“行话”。最后说一点我自己最深的体会AI赋能To B行业技术上没有迈不过去的坎真正难的是把技术的语言和业务的语言对齐。这次合作探索最有价值的产出不是跑了多少个模型、开了多少轮会而是建立了一套让AI团队和建筑业务团队能高效对话的机制。这套机制一旦跑通后面不管扩展多少场景路都会顺很多。如果你正在推进类似的AI落地项目建议不要一上来就追求宏大的平台架构先找两三个场景做出真实成效让业务方自己说“这东西真有用”后面的事情会好办很多。