我们准备上AI但有两句话你们记一下第一所有企业数据只能在公司内网里流转谁都不能保证数据安全那就不要上第二团队里没有专职算法岗你们得想办法让业务部门自己也能用起来。类似的话我这一年听过不少次。企业数据留在内网、把AI开发门槛降到最低看上去是两个约束其实是一条路先用私有化方式把大模型能力变成内部基础设施再用贴近业务工具的方法把算法细节藏起来。这篇文章想写的是我在几家企业内网环境里落地AI应用开发平台的完整过程。从大模型底座选型、内网部署推理服务到RAG知识库、Agent工作流的搭建再到离线环境下那些躲不掉的软件依赖问题我把能说的踩坑经验都写出来。不是让你照着我的方案生搬硬套而是给你一套判断逻辑在数据不能出内网的硬约束下哪些环节可以用开源方案降门槛哪些地方必须投入真金白银哪些坑一开始就能避开。1. 企业数据“不出门”不是保守是这类项目的第一需求边界很多技术同行第一次接触这种需求时第一反应是委屈用云端大模型API不是又快又好吗为什么非要自己折腾内网。这种委屈可以理解但换到企业信息负责人视角问题就变了。企业的客户资料、财务数据、研发图纸、内部规章一旦调用外部模型接口数据就要经过外部服务商的服务器传输链路、服务端日志、模型训练数据每一个环节都可能变成泄露点。企业老板真正害怕的不是技术不先进而是数据一旦失控业务损失和品牌信任不是几张API账单能扛住的。把数据留在内网本质上是给AI项目划了一条不变的边界整个项目里模型可以在内网跑知识库可以在内网建Agent可以调内网接口但任何业务数据都不应该离开这座“数据院子”。这条边界一旦划清楚后面所有技术选型都会变得简单。1.1 一个真实的“既要又要”矛盾实际推进时这种项目会先遇到一个明显矛盾一边是数据要求绝对内网化一边是团队AI能力普遍薄弱。内部懂业务的人不懂模型懂模型的人不一定了解内部IT架构真要招一个算法团队时间、预算、编制都不现实。如果再加上一条“公司老员工手里都是Java、Vue、数据库技术栈”那传统大模型项目的玩法基本就不适用了。我在前期和业务部门沟通时频繁听到三种说法。第一种数据敏感部门不敢用外部工具但又眼红AI生成文档、提炼总结的能力。第二种信息部门想把模型部署起来可GPU服务器审批流程走了一个月最后发现没人会配推理环境。第三种公司想做AI应用但所有技术选型都卡在“数据出不去”这个死结上项目迟迟没有启动。这些问题的共同点并不是“算法不够好”而是“AI能力没有变成一项内部基础设施”。把它想成发电厂就好理解了——企业不会让每个部门自己建发电厂但一定会把电力线路铺到每间办公室。内网AI平台要做的事情就是把模型、知识库、开发工具统一管起来让业务部门像用电一样平等地调用AI能力。1.2 理解“门槛”的真实构成环境、工具、人才三件事很多人一提“降低AI开发门槛”第一反应是让非技术人员写提示词或者拖拽画个流程。真实降低门槛远不止这些我习惯把门槛拆成三层。第一层是环境门槛。算法工程师上手最快的方式是有一台装了显卡驱动的Linux机器能跑Docker能访问私有镜像仓库能下载Python包。但大部分企业内网机器被各种安全策略限制装软件要审批开端口要走流程如果这些都靠人工处理开发和运维都会很崩溃。所以内网AI平台要先解决“开发者上手的舒适度”相当于把水电煤管道先铺好。第二层是工具门槛。模型装好了不等于业务能用。开发者需要封装好的API、知识库工具、Agent编排能力、调试后台和日志没有这些业务团队拿到一个裸模型也没用。工具链的好坏直接决定AI应用能否从Demo走向生产。第三层是人才门槛。传统企业里真正能写业务代码的人不少但懂Transformer、SFT、RLHF的人极少。想让这类团队顺利做AI应用最好的办法不是逼他们啃论文而是让大模型能力通过RAG、Agent、低代码平台这类封装好的组件呈现出来让他们主要写业务流程而不是训练模型。这三层门槛是递进关系环境不通后面都白搭工具不顺团队留不住人才不接地气应用永远是孤岛。后面几个章节我会沿着这三层逐步拆解。2. 内网大模型底座的选择逻辑先算显存账再谈参数规模内网AI平台的地基是一个可以私有化部署的大模型。现在开源权重模型已经不少Qwen系列、Llama系列、MiniCPM、DeepSeek开源的版本都能跑企业业务场景。关键问题不是“哪个模型最强”而是“你现有的机器能不能扛住”。我见过太多项目项目初始方案直接写“部署千亿参数模型”结果发现单位根本采购不起对应算力项目在硬件审批环节就被毙掉。真正靠谱的做法是先算清楚显存账再决定模型档位。2.1 先看这个公式省得被硬件销售带偏大模型推理时的显存占用和模型参数量强相关。用FP16精度加载模型模型权重本身大约需要“参数量(以亿为单位)×2字节”的显存。举个例子一个70亿参数模型FP16权重大约占用14GB140亿参数大约28GB320亿参数大约64GB。当然这只是权重部分推理时还要算上KV Cache、中间激活值和推理框架的开销所以真实部署时建议至少留出20%到30%余量上下文越长、并发越大额外显存需求就越高。对典型企业试点环境我给的参考表格大致是这样模型档位FP16权重估算建议设备适合场景7B级14GB单张24GB显卡文档问答、基础助手、低并发测试14B级28GB双卡24GB或单卡48GB复杂指令、更高准确率、小团队使用32B级64GB四卡24GB或双卡A100级别较高难度任务、较多并发70B级140GB多卡集群严肃生产环境、高并发业务如果完全没采购GPU又想先跑POC可以用CPU加量化模型把流程跑通只是速度会很慢。个人自己玩玩的话24GB显存左右的二手卡是性价比较好的起步选择企业采购则要看稳定性和保修不要只看单卡价格。2.2 开源权重模型与商业API的本质区别有人会问为什么不用各大厂商开箱即用的接口非要在内网折腾开源模型原因很简单调API时请求内容不管怎么加密最终还是要穿过企业网络边界送到外部服务器做推理。一部分服务商承诺数据不留存但从企业安全审计角度讲“数据离开内网”这个动作本身就已经触到了红线。开源权重模型给的是全套权重文件可以完全部署在自有机器上推理过程不产生外联请求。只要前期把商用许可规则查清楚企业内部用基本没有障碍。效果上通用聊天能力也许和顶尖商用API有差距但只要应用方式设计得当比如加上RAG知识库、限定任务范围差距在日常业务场景中并不明显。2.3 推理服务的两种部署方式快速起步与扛并发部署方式取决于团队技术底子。想最快验证我推荐用Ollama这类工具一条命令就能把模型跑起来还会提供一个OpenAI兼容的API地址给应用层调用足够用了模型文件和Docker镜像可以在能联网的机器上提前准备好再打包带到内网。# 在可联网的机器上提前把镜像和模型准备好 docker pull ollama/ollama docker save ollama/ollama -o ollama-image.tar # 带到内网服务器后加载 docker load ollama-image.tar # 启动Ollama服务模型目录通过数据卷挂载 docker run -d --gpus all -p 11434:11434 \ -v /data/models:/root/.ollama \ ollama/ollama serve如果想支撑企业级并发Ollama这类极简工具往往不够线上推理建议换成vLLM。vLLM支持连续批处理、PagedAttention这些优化手段同样的显卡能支撑更高并发。它暴露的接口同样兼容OpenAI格式这样上层应用不用改代码只改API地址和密钥就行。这个阶段的设计原则是把“模型服务”当作独立的内部中间件。上层应用只认识一个标准API地址具体背后是7B还是70B、用Ollama还是vLLM对应用透明。后面无论换模型、加卡、升级版本业务系统都不受影响。3. RAG落地把企业知识库做成内网AI助手的完整链路大模型部署好之后最直接的应用不是让员工随便聊天而是把企业知识库变成AI助手来问答。比如新员工查报销流程、销售查产品参数、客服查售后政策这些场景天然适合用RAG技术也就是“检索增强生成”。3.1 为什么业务上优先用RAG而不是微调企业做AI应用很容易被“微调”两个字吸引觉得模型越训越懂自家业务。但从成本角度看微调需要准备高质量标注数据、训练脚本、GPU资源还要防止模型过拟合训练完如果业务资料变了又得重来一遍这对传统企业团队并不友好。RAG的思路是外挂知识库先把企业文档切片和向量化用户提问时先检索相关片段再让大模型基于检索结果生成答案。它不改模型权重只改生成时的上下文因此知识更新非常方便——业务文档变了把新文档更新进向量库就行模型本身不用动。对“降低AI开发门槛”这件事RAG是真正的第一站。业务人员只需要维护好文档开发人员只需要搭好检索管线就能做出一个相当实用的问答应用。3.2 一条经典链路的五个关键环节在某个制造业客户那里我们处理过几千份设备手册和质检规范整个RAG链路分为五个环节。第一个环节是文档解析。企业文档最常见的格式是PDF、Word、扫描件和表格PDF里经常有图片扫描件则必须走OCR识别。这里要注意选择能在内网运行的OCR工具不能偷偷调云端识别。第二个环节是清洗和切片。我的经验是不要按固定字数盲目截断而是尽量按文档标题层级、段落、表格结构切每个切片控制在400到800字之间相邻切片留50到100字重叠防止切断语义。第三个环节是向量化。把切片文本转成向量理论上可以用外部接口的Embedding模型但既然数据不能出内网这里必须也换成本地模型例如BGE系列这类开源中文向量模型效果就比较够用。第四个环节是向量检索与重排序。初期可以用向量数据库比如Qdrant等要拼精度可以再加一层重排序模型把向量召回的前几十条重新排一遍再把最相关的几条放回提示词。第五个环节是生成回答。大模型只看检索出来的片段和当前问题提示词里明确要求“只能依据给定资料作答资料中没有信息就坦诚说不知道”。3.3 内网部署RAG时三件容易被忽略的事第一件是Embedding模型也要本地化。不少人以为只有主模型需要内网部署向量化顺手调云端接口结果数据照样外流。第二件是权限隔离。企业知识库往往分部门销售资料不该出现在研发问答里研发图纸更不该让全员检索到最好在向量库里就给数据打上部门标签检索时根据用户身份过滤避免“知识库等于数据裸奔”。第三件是日志和审计。AI助手记录下来的问答日志是宝贵的运营数据但可能包含敏感片段。实际操作里我会把日志里的姓名、手机号等脱敏后再存并且定期抽样分析看用户都在问什么类型的问题以便持续补充知识库。4. 从问答到干活Agent开发如何把门槛压到业务一线RAG做熟练之后AI应用会从“被动回答问题”进化到“主动完成工作”这就是Agent能发力的地方。对一个不写模型的业务团队来说Agent技术栈最大的价值是把自然语言变成调用内部系统的入口。4.1 Agent让业务系统接口变成大白话工具举个例子。合同管理助理这个Agent可以接收用户输入的自然语言指令自动提取合同文件名、签约主体、金额、付款节点然后调用内部合同系统的“创建待办”“上传附件”“发提醒”等接口完成动作。传统开发方式可能需要为每个动作写单独的入口页面但在Agent模式下后台只是把内部接口描述成“工具”大模型负责理解用户意图再决定调用哪个工具、传什么参数。对于企业内部不太擅长写代码的业务人员他们面对的不是RESTful API和JDBC而是更接近日常用语的说话方式。比如“帮我把上个月华东大区逾期超过三十天的订单整理成表格”这种需求会由平台自动拆成查库、筛选、汇总和生成文件几步。4.2 开发Agent应用的最小闭环想让业务团队快速上手Agent开发一般建议按下面的最小闭环走先圈定一个小目标明确Agent要帮谁、解决哪个高频重复任务。列出Agent可用的内部工具通常是已有API或数据库访问能力起步时控制在三到五个。把工具的“说明书”写得非常详细参数代表什么含义、返回结构是什么、有哪些边界条件这些描述直接影响大模型选工具准确率。拿真实问题回放测试把业务人员过去一个月的提问记录当作测试集持续看Agent的调用选择和最终输出。如果这时团队没有算法专家我建议直接用一个可私有化部署的低代码Agent平台比如Dify这类开源方案。它的核心优势是让人在界面上编排提示词、工具调用和外部配置开发门槛低得多。等到业务跑通了、场景复杂了再考虑用代码手写Agent工作流也不会太迟。4.3 “多AI并行开发”不是噱头是三种并行做Agent平台时另一个常被忽略的问题是多业务线并行。多个部门都会找开发团队要场景如果每个Agent都单独部署一套模型环境不仅资源浪费后续维护也是灾难。我建议在平台层做模型网关把多个模型服务、多个Agent应用统一纳管。这里说的“多AI并行开发”实际会同时发生在三个层面。第一模型层面业务A用7B模型做轻量分类业务B用14B模型做深度问答网关负责路由。第二Agent层面不同部门发布的Agent跑在不同工作区互不干扰。第三开发团队层面每个人或每个小组都可在平台上管理自己的提示词版本像管代码一样管AI应用配置。模型网关还有一个重要作用是审计。所有对模型的调用请求都会流过网关能够清晰地知道哪个部门、哪个应用、调用了哪个模型、消费了多少Token。审计数据同时满足企业内控和数据安全两个要求。5. 受限网络里的搭建实录离线依赖、Docker与前端环境数据留在内网最直接的代价就是没法随手执行pip install、npm install、docker pull。我经手过的内网环境最夸张的一台AI服务器连本地软件源都没有所有安装包都得用移动硬盘人工搬运。这个阶段最容易消耗团队热情但也最能看出规划水平。5.1 内网装Docker这件事的两种做法如果服务器是Windows Server 2016这类老系统我的第一个建议往往是别硬扛Linux容器。Docker容器本身是Linux生态在Windows Server上强行跑Linux容器会遇到驱动、网络、GPU透传等多重问题。实际项目里我更倾向于在Hyper-V或VMware里起一台Linux虚拟机再在这台虚机上装Docker Engine然后把GPU显存直通给这台虚机。离线安装Docker Engine通常是在一台能联网的同版本Linux机器上下载所有rpm/deb包再通过内网拷过去。装好Docker之后更麻烦的事情是镜像搬运因为Docker镜像如果没法从仓库拉取就不能直接使用。常用的办法是先在有网络的环境里pull镜像再把镜像用docker save打成tar包拷进内网后用docker load加载。# 外网机器保存镜像 docker pull qdrant/qdrant docker save qdrant/qdrant -o qdrant-image.tar # 内网机器加载镜像 docker load qdrant-image.tar大型语言模型的模型文件也一样建议统一模型文件目录用移动硬盘或内网文件服务器标注清楚版本让不同服务器之间复用避免重复搬运几十GB的文件。5.2 离线的Python依赖和模型依赖怎么办AI应用开发离不开Python包。内网机器的常见Python安装问题可以在外网机器上先准备好依赖包目录# 在有网络的机器上下载指定依赖到这个目录 pip download -r requirements.txt -d ./packages # 拷入内网后离线安装 pip install --no-index --find-links./packages -r requirements.txt如果团队长期依赖更适合的做法是把Python包上传到内部文件服务器定时同步一次完整包索引。没有内部源的话就算三天两头手工传包也不利于研发效率。5.3 前端和后端组件同样得跟着内网化企业内部开发者的日常通常还涉及Vue这类前端工程的搭建。在内网没有npm镜像可用时有两种可行策略一种是开发阶段把整个node_modules目录通过压缩包拷贝进来能解燃眉之急但版本管理比较混乱另一种是搭建Verdaccio这类私有npm仓库由专门人员定期同步公共依赖包项目部在自己环境里正常执行npm install。当时我还遇到过一个地图组件的问题。业务系统需要在大屏上展示地理分布数据开发商直接给了一个在线地图SDK线上运行倒是没问题但客户坚持所有数据不出内网连地图底图也得用内部瓦片服务。后来我们改用了离线地图部署方案把栅格瓦片文件部署到内部服务上再加载本地的图片瓦片。这件事让我印象很深企业数据留在内网不只是大模型要内网化整个数字基座包括地图、OCR、对象存储、日志服务都得做好准备否则AI应用跑到一半总会被某一处外部依赖卡住。6. 真实跑起来后的效果边界与避坑经验AI应用能跑通和能长期用得好中间隔着一整条经验鸿沟。这一节把我在内网AI项目里吃过亏、后来沉淀下来的要点写出来供你参考。6.1 先泼三盆冷水第一盆冷水是模型幻觉。大模型再强大本质仍然是在生成“看起来合理”的文本并不天然区分事实和编造。RAG能缓解这个问题却不能根除因为检索到的资料本身可能是旧版或过时的。第二盆冷水是权限死角。AI助手一旦掌握了内部接口调用能力权限设计稍有疏忽就可能出现越权查询。比如普通员工通过Agent让模型调用了一个只有经理层才能访问的接口如果接口层面没有做校验那问题就大了。Agent权限的本质是“AI能代表的身份权限”必须和内部权限体系打通越权问题不能靠聊天安全提示解决。第三盆冷水是运维成本。模型不是部署一次就一劳永逸的模型有版本更新、推理独占显存、接口延迟会波动、报表数据要定期统计。很多企业低估了这些持续投入把模型部署完就以为项目结束结果一个月后没人维护应用口碑就开始下跌。6.2 我在内网AI项目里踩过的几个具体坑第一个坑是单卡能加载模型就以为系统能正式上线。结果多人同时提问时推理速度迅速劣化甚至直接OOM。后来我学乖了任何模型上线前先做并发压测把显存占用、首字延迟、生成吞吐量记录清楚。如果不做压测就不知道7B模型到底能支撑多少同事同时用。第二个坑是上下文被文档塞满。早期RAG管道为了让模型答案完整一次性把很多检索段落拼进提示词结果大模型的注意力被稀释反而答非所问。优化办法是限制检索片段数量、加重排序、对长文档做摘要提取最终只把最相关的几条放进去而不是一股脑全塞。第三个坑是一遇到效果不理想就考虑微调后来发现多数时候根本不需要。这里有八成问题是检索环节引入的比如文档切片太碎、向量模型中文能力不强、业务术语召回不准或者知识库文档本身就是错的。调整这些环节往往比微调见效更快、成本更低、试错周期更短。6.3 一个还比较靠谱的验收方法内网AI应用的建设建议带着明确的验收指标做。我会让业务部门整理一百到两百条真实高频问题组成一个“验收题库”覆盖正常问题、边界问题、无答案问题三大类。每次模型或知识库更新都拿题库跑一遍对比上一版本的答案质量和失败类型。不要被一两个惊艳回答打动而是看整体通率比如“完全可用”“部分可用”“不可用”各占多少比例。在人工评阅的基础上还可以选一套自动评价方案用更强的模型按照准确性、完整性、是否忠实原文等维度给每个问答结果打分。大量回放测试时这种方式比全部人工复核高效得多。这里比较适合用的一个技巧是把历史问答日志里“用户随后又问了什么”当作隐式反馈。如果用户问完一个问题后立刻换个说法再问通常说明上一轮答案没解决他的问题。这类信号可以帮助你判断哪块知识库需要优先补充。说实话做企业内网AI项目最触动我的不是某次技术突破而是看到业务人员从“AI能用吗”变成“以后这东西每天得开着”。当一个合同员能通过自然语言让系统自动整理条款差异当一个售后工程师在设备故障现场用手机拍照就能让老员工经验库给出排查思路项目才算真正落地。把企业数据留在内网不是给自己上枷锁把AI开发门槛降下来也不等于做出来的东西幼稚。这两件事凑到一起反而逼出了更接近务实的路线不用追逐最前沿的大模型技术而要搭建一套让数据安全、开发顺手、业务愿意用的内部AI平台。如果你正准备接手类似项目不妨先从一个小场景、一台能跑7B模型的机器、一个小型RAG知识库做起先把“数据不出内网”这个死结打开后面一切都会顺很多。