过去一年我帮几家企业搞定了内网里的AI开发环境。听到最多的一句话是“数据能不出内网吗模型我们自己有服务器能跑起来吗开发团队就几个后端没有专门搞AI的能行吗”这三个问题其实就是标题那句话——把企业数据留在内网把AI开发门槛降到最低。行业里喊私有化大模型、企业知识库、AI Agent喊了一年多但对大多数中小企业来说真正的痛点不是技术不够新而是不敢把核心数据交给云端又不知道怎么在断网、缺卡、没算法工程师的情况下把AI用起来。这篇文章我不想讲那种PPT级的概念就按我实际操作过的路径把内网AI开发从技术选型、环境搭建到常见坑位完整拆一遍。你不用懂太多AI底层的东西按着思路走至少能把一个能用的企业知识库问答系统跑起来。1. 先搞清楚为什么非要让企业数据留在内网1.1 数据合规与安全不是“选择题”企业级数据大致分三类客户和个人信息、财务与经营数据、还有研发生产过程中形成的核心资料。这些数据一旦出了问题轻则面临监管处罚重则直接影响企业声誉和业务连续性。前几年很多团队图省事直接调用云端大模型API把内部文档、代码、运维日志丢上去做问答和分析。表面上看效率很高但只要认真读一下各家平台的隐私协议就知道数据在传输和存储过程中并不是绝对可控的。再加上不少云服务商的大模型接口会对输入内容做训练优化等于变相把企业内部资料“喂”给了对方。这显然不是大多数企业能接受的。所以我把“数据留在内网”定义为一切AI能力的底座。这条前提不变后面所有方案都是围绕它搭起来的。举个具体场景一家制造业企业想用AI做设备维修知识库里面有产线参数、故障代码、维修记录这些数据如果上传到云端等于把自己的工艺细节暴露出去。而把数据留在内网意味着AI服务只在内网跑外部网络完全接触不到原始数据从物理和逻辑两个层面都守住边界。1.2 内网AI开发的挑战不只是“没网”很多第一次接触内网AI的工程师以为最大的问题是没有公网网速。真做起来才明白更麻烦的是下面这几件事没有外网大模型和依赖包的下载渠道断了在线安装工具全部失效。硬件资源有限企业内网服务器通常不是为AI设计的没有GPU或者只有老显卡。算法人才缺失大部分企业的研发团队是Java、Python后端不会训练模型甚至不太熟悉AI生态。业务预期过高老板觉得大模型是万能的希望什么都回答但团队不知道如何合理控制边界。这些挑战环环相扣。没有网意味着所有组件都要“人肉搬运”没有显卡意味着模型选型必须克制没有算法工程师意味着平台必须足够傻瓜化。所以内网AI开发并不是简单的“把云端那套搬下来”而是要重新设计一条适合内网环境、适合普通研发团队的低门槛路径。1.3 低门槛不等于低能力有人觉得内网部署AI只能做一些玩具级应用其实不是。只要选型合理内网私有化的大模型完全可以支撑以下几类高频需求企业内部知识库问答政策制度、产品文档、技术手册、客服话术几百上千份文档丢进去员工用自然语言提问。代码生成与评审辅助后端开发团队接入本地模型帮忙生成单元测试、解释遗留代码、做简单的代码审查建议。工单与客服自动化读取历史工单和知识库自动给用户提供初步回复方案。文档资料二次加工合同摘要、会议纪要整理、周报生成、多语言翻译。这些场景的共同特点是不需要大模型有天马行空的创造力只需要在特定领域里结合企业数据给出可靠回答。这正是RAG检索增强生成架构擅长的也是内网AI开发目前最务实的技术路线。2. 内网AI开发的核心技术选型解析2.1 大模型私有化部署开源模型是主流选择要在内网跑大模型不可能用闭源API必须选择可以私有化部署的开源模型。目前国内环境比较成熟的中文模型有Qwen通义千问、DeepSeek、ChatGLM智谱国外还有Llama系列。其中Qwen和DeepSeek对中文支持好社区生态活跃量化工具完善是内网部署的首选。模型规模方面7B到14B级别的模型量化后在16GB内存或12GB显存的机器上就能流畅运行足够处理大多数企业问答、文档摘要和简单代码任务。32B及以上模型需要更大显存但可以退而求其次用CPU多线程跑只是速度慢不少。这里我建议内网AI起步阶段不要盲目追求大参数先把7B或14B的量化模型跑通验证业务真实价值再决定是否升级硬件。推理引擎的选型也很关键常见的有Ollama、vLLM、llama.cpp等。vLLM吞吐能力好但部署配置复杂适合正式服务llama.cpp轻量能在CPU上运行适合单机折腾Ollama则胜在简单一条命令就能启动模型还自带兼容OpenAI格式的HTTP API。我个人对中小企业的建议是先用Ollama拉起模型跑通业务后再根据并发需求迁移到vLLM。2.2 让模型更懂企业RAG架构是真正的降门槛手段很多业务方一上来就喊“微调模型”。但微调需要高质量的标注数据、大量的GPU时间和懂训练的人这本身就违背了“低门槛”的初衷。我更推荐先做RAG。RAG的核心思路很简单用户提问时系统先从企业知识库里检索出相关片段把这些片段和问题一起交给大模型让模型基于片段生成回答。相当于给大模型配了一本“企业手册”每次回答前先翻到对应页而不是靠模型自己死记硬背。这样做的优势非常明显企业知识可以随时更新只要改文档、重新索引不需要反复训练模型。答案有据可查模型引用来源业务人员能校验可信度高。计算成本低不用训练推理阶段多几步检索而已。RAG的组件也不复杂文档加载、文本切分、向量化、向量检索、重排序然后拼接提示词。关键点在于文本切分的大小和重叠以及Embedding模型的选择。内网环境里Embedding模型我一般用bge系列比如bge-m3它对中文效果不错并且支持本地部署不需要联网调用外部API。2.3 开发框架与可视化编排让普通后端也能上手单纯有模型和向量库还不够企业要的是一个能用的应用能传文档、能对话、能管理权限。从零开发一套前端、后端、任务队列工作量不小。好在目前有成熟的开源开发框架可以大幅降低开发工作量我用得比较多的是Dify和FastGPT。这类低代码平台的核心价值在于把知识库管理、检索流程、提示词编辑、应用发布都封装成可视化界面。你不需要写一堆胶水代码只需要在界面里配置数据源、选择模型、拖拽流程。更重要的是Dify和FastGPT都支持本地离线部署可以完全跑在内网底层的模型、向量库、Redis等都可以用内网容器搞定天然符合“数据留在内网”的硬性要求。如果你熟悉LangChain或LlamaIndex这类开发库也可以自己写代码构建RAG流程灵活度更高。但对于多数企业团队我建议先用可视化平台跑通MVP等业务稳定后再根据性能瓶颈用LangChain定制。合理的技术栈组合是Dify Ollama 本地Embedding 向量数据库这一套足够覆盖90%的企业知识库问答需求。3. 实操从零搭出一套内网AI开发环境3.1 硬件规划与最小配置内网部署AI不一定要“一步到位买A100”。先明确你的使用规模是5个人内部试用还是全公司上百人同时用是纯文本问答还是要处理大量长文档这些直接决定硬件投入。我整理了一个最小配置参考表基于量化后的模型推理场景模型规模量化级别最低显存最低内存适用场景1.5B ~ 3BQ4_K_M4GB8GB轻量问答测试环境7B ~ 8BQ4_K_M8GB16GB小团队知识库问答、代码辅助14BQ4_K_M12GB~16GB32GB较复杂推理中大型团队测试32BQ4_K_M24GB64GB复杂任务内容生成质量要求高没有GPU就别硬撑。用纯CPU跑7B量化模型每次回答可能在几十秒到几分钟不等取决于CPU核心数和内存带宽。如果只是内部几个人体验勉强能接受但如果是员工自助查询建议还是添置一块消费级显卡比如RTX 3060 12G是目前性价比很高的内网AI起步卡。3.2 离线环境下安装Docker与基础依赖内网服务器通常没有外网。通过yum、apt或pip在线安装软件基本行不通所以第一步是把所需软件和镜像“搬运”进去。这里Docker是首选因为镜像一经打包拷贝到内网直接load就能用依赖环境一致省掉很多编译和依赖问题。具体操作可以分三步在有外网的机器上下载适合内网服务器架构的Docker离线安装包比如docker-ce的tar包并下载常用基础镜像例如ubuntu、redis、postgres。把安装包和镜像压缩包通过U盘或内部文件服务器拷贝到内网服务器。在内网服务器上解压安装Docker然后用docker load将镜像导入。要注意架构一致性。如果内网服务器是x86_64就在x86的外网机器上打包如果是ARM比如部分国产服务器就要选择对应的镜像和离线包否则会报exec format error。另外Docker版本不要磨太新稳定版就好内网环境不需要最新特性。3.3 安装Ollama并加载模型Ollama是我强烈推荐的模型推理工具它在内网环境最大的优势是模型管理简单。正常在有网络的机器上执行ollama pull qwen2.5:7b就能下载模型。内网机器没网就得手动把模型文件“搬”过去。最简单的办法是在能联网的机器上安装Ollama先pull好需要的模型比如qwen2.5:7b-instruct然后找到Ollama模型存放目录通常是~/.ollama/models整体压缩打包传到内网服务器后解压到相同位置。内网机器启动Ollama服务运行ollama list能看到模型就算成功。如果企业不允许任何有网设备接触业务环境也可以走另一条路从HuggingFace等平台手动下载GGUF格式的模型文件比如Qwen2.5-7B-Instruct GGUF再通过Ollama的Modelfile创建自定义模型。操作大致是写一个ModelfileFROM /data/models/qwen2.5-7b-instruct-q4_k_m.gguf TEMPLATE {{ .Prompt }}然后执行ollama create qwen2.5:7b -f Modelfile。这种方式的好处是模型文件可控能验证哈希值适合高安全要求的环境。启动后可以用ollama serve起服务默认监听11434端口。测试API是否正常curl http://127.0.0.1:11434/api/generate -d {model:qwen2.5:7b,prompt:你好}3.4 部署本地向量库和Embedding模型向量库用于企业文档的向量化存储和检索。我建议内网首选用Chroma或Qdrant它们轻量、支持Docker部署、API简洁足以支撑知识库问答。生产并发大也可以考虑Milvus但部署复杂度会高一些。以Qdrant为例内网部署只需要导入镜像然后启动容器docker run -d --name qdrant -p 6333:6333 -v /data/qdrant:/qdrant/storage qdrant/qdrantEmbedding模型则用bge-m3或更小号的bge-small-zh。如果有GPU可以像部署大模型一样把Embedding模型跑在Ollama或专门的推理服务上如果资源紧张也可以在Dify里选择本地Embedding模型路径让Dify自己管理向量化。我的经验是Embedding模型参数很小用CPU跑完全没问题关键是模型文件要提前下好并配置好路径避免运行时去公网下载。3.5 用Dify快速搭建企业知识库问答应用Dify是一个可以私有化部署的LLM应用开发平台支持知识库、工作流、Agent等功能。离线部署Dify需要准备它的全部镜像通常用一个有外网的机器把docker-compose里定义的镜像dify-api, dify-web, postgres, redis, weaviate等全部docker pull后再docker save打包到内网docker load并执行docker compose up -d。启动后在Dify后台配置模型供应商。选择Ollama类型填写内网地址比如http://host.docker.internal:11434这是从Docker容器访问宿主机的地址如果Ollama也跑在容器里则写容器名称或内网IP。填好模型名称和上下文长度保存即可。然后创建应用选择“聊天助手”。左侧“上下文”里关联一个知识库知识库里上传企业文档比如员工手册.pdf、运维操作手册.docx。点击“处理并索引”选择本地Embedding模型Dify会自动切分文档、向量化并写入向量库。这样应用就有了检索能力。最后在提示词里做一些约束比如“你是企业内部助手请基于知识库内容回答回答要简洁必要时说明出处。”保存后发布会生成一个对话Web页面和API接口团队成员直接访问链接提问。3.6 为Java/Python团队提供AI开发接口Dify和应用界面适合业务人员直接对话但很多企业还要让AI能力嵌入现有业务系统比如OA、ERP、客服后台。这时候需要把内网模型服务封装成接口提供给Java/Python团队调用。Ollama原生提供了兼容OpenAI格式的API所以Java后端可以用OpenAI Java客户端把base-url指向内网的http://127.0.0.1:11434/v1就能直接访问。示例代码var client OpenAI.builder() .baseUrl(http://127.0.0.1:11434/v1) .apiKey(ollama) .build();Python更简单import requests response requests.post( http://127.0.0.1:11434/api/generate, json{model: qwen2.5:7b, prompt: 请总结这段内容} )如果你想统一管控权限、做并发隔离可以在内网再加一层API网关把Ollama、向量检索、知识库逻辑封装为一个标准REST服务。这样普通后端开发完全不用理解大模型原理按照普通接口对接即可。这也是“降低AI开发门槛”落到实处的关键一环。4. 内网AI开发常见问题与排查记录4.1 内网没有外网依赖和模型怎么搬运这个问题问得最多。核心原则是找一台带外网的“摆渡机”把所有东西下载好打包拷贝进内网。软件安装包如Docker离线rpm/deb包。容器镜像docker save成tar内网docker load。大模型文件Ollama模型目录或GGUF文件。Python依赖通过pip download到目录内网pip install --no-index --find-links。搬运过程中最容易踩的坑是路径不一致。比如Ollama模型目录拷贝后权限或路径不对会导致ollama list看不到模型。解决方法是先在内网机器上启动一次Ollama生成目录结构再停止服务、覆盖文件、重启。另外镜像导入时要耐心等大文件加载完成不要在docker load过程强制中断。4.2 Windows Server 2016安装Docker失败怎么办很多企业内网服务器是Windows Server 2016标准版网上有大量吐槽帖。原因在于Docker Desktop从某个版本开始要求Windows 10 64位专业版或Windows Server 2019以上对Server 2016支持非常有限。就算强行用Docker Toolbox也是基于VirtualBox的老式Hyper-V方案性能和稳定性都很差。我的建议是不要和系统版本死磕。如果内网有虚拟化平台开一台最少2核4G的Linux虚拟机安装Ubuntu Server 22.04或Rocky Linux把Docker和AI应用全部跑在Linux里Windows服务器只做资源提供方。如果实在没有Linux环境至少升级到Windows Server 2019或2022再用Docker Desktop的Windows容器模式。记住Windows Server 2016跑容器不是不能但投入产出比太低后面维护会让你哭。4.3 内网GPU性能不足推理速度慢很多企业拿老旧的机器跑AI跑起来发现一个字一个字蹦等得心慌。这种情况先别急着加硬件可以从这几个维度优化换更小的量化模型比如从Q8降到Q4速度通常能提升2到3倍效果损失在可接受范围。减少上下文长度把Dify里的“上下文长度”从8192降到4096甚至2048降低显存/内存压力。关闭多余占用显存的程序包括桌面环境和无用的浏览器。如果是Ollama可以限制并发数比如设置OLLAMA_NUM_PARALLEL1避免多个请求同时抢显存。实在不行再考虑加卡。内网环境CPU推理也能跑但通常并发能力极差只适合开发测试。生产环境我建议至少有一块12G显存的GPU专门用来跑大模型另一部分CPU留给向量检索和应用服务。4.4 模型回答质量差不接地气有老板反馈模型是能跑起来但回答的和我们的业务对不上。原因一般不是模型笨而是RAG链路没调好。最常见的问题是文档切分不合理一句话被切开或者关键信息在多个章节里检索时只召回其中一部分。解决思路是按层级切分、适当增加重叠。Dify里可以调“切片长度”和“重叠长度”一般切片300到500字重叠50到100字比较合适。如果知识库里有大量表格、PDF扫描件需要先做OCR转成文本否则向量检索根本找不到内容。另外要给知识库设计“标题摘要”的元数据让检索阶段更容易匹配到正确片段。回答质量还可以靠“重排序”来提升。Dify支持配置rerank模型检索出Top50个片段后重排序挑出最相关的Top5效果比纯向量检索好很多推荐加上。4.5 团队缺乏AI开发经验怎么破这会涉及到组织推动的问题。我见过最快的落地方式是让一个后端工程师专门负责AI平台工具业务部门出一个人兼职整理知识库文档算法专家只做远程顾问。三个人三周就能把一个知识库问答应用上线。对普通工程师来说先不要碰LangChain源码不要碰模型微调不要在K8s上折腾。把Dify、Ollama、向量库这三样用好就能解决80%的实际问题。等大家对AI的能力边界有了真实感受再逐步引入Agent、工作流、复杂编排才不容易虎头蛇尾。4.6 数据安全与权限控制细节内网AI平台上线后权限控制很容易被忽略。企业知识库里可能有不同敏感级别的文档如果所有人都能问所有内容就会造成越权访问。合理做法是在Dify里创建多个知识库按部门或文档等级隔离。应用层面对接企业账号体系LDAP/AD控制谁能访问哪个应用。所有问答记录保存审计日志方便追溯。模型服务只开放给内网IP不要暴露到外网。数据安全并不只是“数据没出内网”就完了内部权限同样要细化否则等于把公司的资料库直接公放给全员。5. 一个月跑通内网AI开发的实践经验分享我帮一家中等规模的制造型企业搭过一整套内网AI知识库。他们的情况非常典型内网有几十台Windows服务器唯一一台能用的GPU是某员工自带的旧显卡数据散落在文件服务器、OA系统和个人电脑里没有任何人做过算法相关的工作。我们只做了一件事把员工手册、设备操作规程、维修案例、常见报错解决方案整理出来大约300多份文档做进RAG知识库然后用Dify发布了一个叫“智能制造问答助手”的应用。第一周搭环境Linux虚拟机、Docker、Ollama、Qwen2.5 7B量化模型、Qdrant、Dify全部就绪。第二周清数据把几百份Word、PDF、Excel统一转文本手工删掉大量废话和过期内容。第三周调检索和提示词反复测试不同切片长度、是否加重排序、系统提示词怎么写。第四周上线试用给车间主任和一线工程师演示让他们提问。最终效果是过去查一份设备维修手册要翻文件柜十分钟现在问一句就有答案还标了来源页码。这个过程中我有几个深刻体会第一内网AI开发最大的成本从来不是模型而是数据清洗。文档质量决定回答质量如果把一堆扫描件、加密PDF直接塞进去效果会惨不忍睹。第二先从一个特别小、特别具体的场景切入。不要一上来就做一个大而全的“企业大脑”那会陷入需求无底洞。从IT支持、行政问答、新人入职指引这类高频低风险的场景开始跑通一个再复制。第三低门槛工具不是玩具。Dify这类可视化平台在严肃业务场景下一样能扛住关键在于底层资源规划和权限设计做到位。不要因为“低代码”就看不上它它解决的恰恰是“没有算法工程师”的真实痛点。最后再分享一个小技巧内网AI环境建议把模型版本和知识库索引状态都记录下来每次更新文档后重新索引模型如果有新版本先在一个测试实例上验证确认无问题再替换生产实例。这样既能保持系统稳定又能持续迭代。如果你所在的企业也面临“数据不敢出网、AI没人会做”的困境别急着上高大上的平台先按照这条路线走一遍找一个具体问题、准备一台服务器、部署Ollama和Dify、扔进去几十份文档最快一周就能看到效果。等业务方说“这个真有用”之后再谈扩展和优化就顺理成章了。
内网AI开发实战：从零搭建企业知识库与私有化大模型
过去一年我帮几家企业搞定了内网里的AI开发环境。听到最多的一句话是“数据能不出内网吗模型我们自己有服务器能跑起来吗开发团队就几个后端没有专门搞AI的能行吗”这三个问题其实就是标题那句话——把企业数据留在内网把AI开发门槛降到最低。行业里喊私有化大模型、企业知识库、AI Agent喊了一年多但对大多数中小企业来说真正的痛点不是技术不够新而是不敢把核心数据交给云端又不知道怎么在断网、缺卡、没算法工程师的情况下把AI用起来。这篇文章我不想讲那种PPT级的概念就按我实际操作过的路径把内网AI开发从技术选型、环境搭建到常见坑位完整拆一遍。你不用懂太多AI底层的东西按着思路走至少能把一个能用的企业知识库问答系统跑起来。1. 先搞清楚为什么非要让企业数据留在内网1.1 数据合规与安全不是“选择题”企业级数据大致分三类客户和个人信息、财务与经营数据、还有研发生产过程中形成的核心资料。这些数据一旦出了问题轻则面临监管处罚重则直接影响企业声誉和业务连续性。前几年很多团队图省事直接调用云端大模型API把内部文档、代码、运维日志丢上去做问答和分析。表面上看效率很高但只要认真读一下各家平台的隐私协议就知道数据在传输和存储过程中并不是绝对可控的。再加上不少云服务商的大模型接口会对输入内容做训练优化等于变相把企业内部资料“喂”给了对方。这显然不是大多数企业能接受的。所以我把“数据留在内网”定义为一切AI能力的底座。这条前提不变后面所有方案都是围绕它搭起来的。举个具体场景一家制造业企业想用AI做设备维修知识库里面有产线参数、故障代码、维修记录这些数据如果上传到云端等于把自己的工艺细节暴露出去。而把数据留在内网意味着AI服务只在内网跑外部网络完全接触不到原始数据从物理和逻辑两个层面都守住边界。1.2 内网AI开发的挑战不只是“没网”很多第一次接触内网AI的工程师以为最大的问题是没有公网网速。真做起来才明白更麻烦的是下面这几件事没有外网大模型和依赖包的下载渠道断了在线安装工具全部失效。硬件资源有限企业内网服务器通常不是为AI设计的没有GPU或者只有老显卡。算法人才缺失大部分企业的研发团队是Java、Python后端不会训练模型甚至不太熟悉AI生态。业务预期过高老板觉得大模型是万能的希望什么都回答但团队不知道如何合理控制边界。这些挑战环环相扣。没有网意味着所有组件都要“人肉搬运”没有显卡意味着模型选型必须克制没有算法工程师意味着平台必须足够傻瓜化。所以内网AI开发并不是简单的“把云端那套搬下来”而是要重新设计一条适合内网环境、适合普通研发团队的低门槛路径。1.3 低门槛不等于低能力有人觉得内网部署AI只能做一些玩具级应用其实不是。只要选型合理内网私有化的大模型完全可以支撑以下几类高频需求企业内部知识库问答政策制度、产品文档、技术手册、客服话术几百上千份文档丢进去员工用自然语言提问。代码生成与评审辅助后端开发团队接入本地模型帮忙生成单元测试、解释遗留代码、做简单的代码审查建议。工单与客服自动化读取历史工单和知识库自动给用户提供初步回复方案。文档资料二次加工合同摘要、会议纪要整理、周报生成、多语言翻译。这些场景的共同特点是不需要大模型有天马行空的创造力只需要在特定领域里结合企业数据给出可靠回答。这正是RAG检索增强生成架构擅长的也是内网AI开发目前最务实的技术路线。2. 内网AI开发的核心技术选型解析2.1 大模型私有化部署开源模型是主流选择要在内网跑大模型不可能用闭源API必须选择可以私有化部署的开源模型。目前国内环境比较成熟的中文模型有Qwen通义千问、DeepSeek、ChatGLM智谱国外还有Llama系列。其中Qwen和DeepSeek对中文支持好社区生态活跃量化工具完善是内网部署的首选。模型规模方面7B到14B级别的模型量化后在16GB内存或12GB显存的机器上就能流畅运行足够处理大多数企业问答、文档摘要和简单代码任务。32B及以上模型需要更大显存但可以退而求其次用CPU多线程跑只是速度慢不少。这里我建议内网AI起步阶段不要盲目追求大参数先把7B或14B的量化模型跑通验证业务真实价值再决定是否升级硬件。推理引擎的选型也很关键常见的有Ollama、vLLM、llama.cpp等。vLLM吞吐能力好但部署配置复杂适合正式服务llama.cpp轻量能在CPU上运行适合单机折腾Ollama则胜在简单一条命令就能启动模型还自带兼容OpenAI格式的HTTP API。我个人对中小企业的建议是先用Ollama拉起模型跑通业务后再根据并发需求迁移到vLLM。2.2 让模型更懂企业RAG架构是真正的降门槛手段很多业务方一上来就喊“微调模型”。但微调需要高质量的标注数据、大量的GPU时间和懂训练的人这本身就违背了“低门槛”的初衷。我更推荐先做RAG。RAG的核心思路很简单用户提问时系统先从企业知识库里检索出相关片段把这些片段和问题一起交给大模型让模型基于片段生成回答。相当于给大模型配了一本“企业手册”每次回答前先翻到对应页而不是靠模型自己死记硬背。这样做的优势非常明显企业知识可以随时更新只要改文档、重新索引不需要反复训练模型。答案有据可查模型引用来源业务人员能校验可信度高。计算成本低不用训练推理阶段多几步检索而已。RAG的组件也不复杂文档加载、文本切分、向量化、向量检索、重排序然后拼接提示词。关键点在于文本切分的大小和重叠以及Embedding模型的选择。内网环境里Embedding模型我一般用bge系列比如bge-m3它对中文效果不错并且支持本地部署不需要联网调用外部API。2.3 开发框架与可视化编排让普通后端也能上手单纯有模型和向量库还不够企业要的是一个能用的应用能传文档、能对话、能管理权限。从零开发一套前端、后端、任务队列工作量不小。好在目前有成熟的开源开发框架可以大幅降低开发工作量我用得比较多的是Dify和FastGPT。这类低代码平台的核心价值在于把知识库管理、检索流程、提示词编辑、应用发布都封装成可视化界面。你不需要写一堆胶水代码只需要在界面里配置数据源、选择模型、拖拽流程。更重要的是Dify和FastGPT都支持本地离线部署可以完全跑在内网底层的模型、向量库、Redis等都可以用内网容器搞定天然符合“数据留在内网”的硬性要求。如果你熟悉LangChain或LlamaIndex这类开发库也可以自己写代码构建RAG流程灵活度更高。但对于多数企业团队我建议先用可视化平台跑通MVP等业务稳定后再根据性能瓶颈用LangChain定制。合理的技术栈组合是Dify Ollama 本地Embedding 向量数据库这一套足够覆盖90%的企业知识库问答需求。3. 实操从零搭出一套内网AI开发环境3.1 硬件规划与最小配置内网部署AI不一定要“一步到位买A100”。先明确你的使用规模是5个人内部试用还是全公司上百人同时用是纯文本问答还是要处理大量长文档这些直接决定硬件投入。我整理了一个最小配置参考表基于量化后的模型推理场景模型规模量化级别最低显存最低内存适用场景1.5B ~ 3BQ4_K_M4GB8GB轻量问答测试环境7B ~ 8BQ4_K_M8GB16GB小团队知识库问答、代码辅助14BQ4_K_M12GB~16GB32GB较复杂推理中大型团队测试32BQ4_K_M24GB64GB复杂任务内容生成质量要求高没有GPU就别硬撑。用纯CPU跑7B量化模型每次回答可能在几十秒到几分钟不等取决于CPU核心数和内存带宽。如果只是内部几个人体验勉强能接受但如果是员工自助查询建议还是添置一块消费级显卡比如RTX 3060 12G是目前性价比很高的内网AI起步卡。3.2 离线环境下安装Docker与基础依赖内网服务器通常没有外网。通过yum、apt或pip在线安装软件基本行不通所以第一步是把所需软件和镜像“搬运”进去。这里Docker是首选因为镜像一经打包拷贝到内网直接load就能用依赖环境一致省掉很多编译和依赖问题。具体操作可以分三步在有外网的机器上下载适合内网服务器架构的Docker离线安装包比如docker-ce的tar包并下载常用基础镜像例如ubuntu、redis、postgres。把安装包和镜像压缩包通过U盘或内部文件服务器拷贝到内网服务器。在内网服务器上解压安装Docker然后用docker load将镜像导入。要注意架构一致性。如果内网服务器是x86_64就在x86的外网机器上打包如果是ARM比如部分国产服务器就要选择对应的镜像和离线包否则会报exec format error。另外Docker版本不要磨太新稳定版就好内网环境不需要最新特性。3.3 安装Ollama并加载模型Ollama是我强烈推荐的模型推理工具它在内网环境最大的优势是模型管理简单。正常在有网络的机器上执行ollama pull qwen2.5:7b就能下载模型。内网机器没网就得手动把模型文件“搬”过去。最简单的办法是在能联网的机器上安装Ollama先pull好需要的模型比如qwen2.5:7b-instruct然后找到Ollama模型存放目录通常是~/.ollama/models整体压缩打包传到内网服务器后解压到相同位置。内网机器启动Ollama服务运行ollama list能看到模型就算成功。如果企业不允许任何有网设备接触业务环境也可以走另一条路从HuggingFace等平台手动下载GGUF格式的模型文件比如Qwen2.5-7B-Instruct GGUF再通过Ollama的Modelfile创建自定义模型。操作大致是写一个ModelfileFROM /data/models/qwen2.5-7b-instruct-q4_k_m.gguf TEMPLATE {{ .Prompt }}然后执行ollama create qwen2.5:7b -f Modelfile。这种方式的好处是模型文件可控能验证哈希值适合高安全要求的环境。启动后可以用ollama serve起服务默认监听11434端口。测试API是否正常curl http://127.0.0.1:11434/api/generate -d {model:qwen2.5:7b,prompt:你好}3.4 部署本地向量库和Embedding模型向量库用于企业文档的向量化存储和检索。我建议内网首选用Chroma或Qdrant它们轻量、支持Docker部署、API简洁足以支撑知识库问答。生产并发大也可以考虑Milvus但部署复杂度会高一些。以Qdrant为例内网部署只需要导入镜像然后启动容器docker run -d --name qdrant -p 6333:6333 -v /data/qdrant:/qdrant/storage qdrant/qdrantEmbedding模型则用bge-m3或更小号的bge-small-zh。如果有GPU可以像部署大模型一样把Embedding模型跑在Ollama或专门的推理服务上如果资源紧张也可以在Dify里选择本地Embedding模型路径让Dify自己管理向量化。我的经验是Embedding模型参数很小用CPU跑完全没问题关键是模型文件要提前下好并配置好路径避免运行时去公网下载。3.5 用Dify快速搭建企业知识库问答应用Dify是一个可以私有化部署的LLM应用开发平台支持知识库、工作流、Agent等功能。离线部署Dify需要准备它的全部镜像通常用一个有外网的机器把docker-compose里定义的镜像dify-api, dify-web, postgres, redis, weaviate等全部docker pull后再docker save打包到内网docker load并执行docker compose up -d。启动后在Dify后台配置模型供应商。选择Ollama类型填写内网地址比如http://host.docker.internal:11434这是从Docker容器访问宿主机的地址如果Ollama也跑在容器里则写容器名称或内网IP。填好模型名称和上下文长度保存即可。然后创建应用选择“聊天助手”。左侧“上下文”里关联一个知识库知识库里上传企业文档比如员工手册.pdf、运维操作手册.docx。点击“处理并索引”选择本地Embedding模型Dify会自动切分文档、向量化并写入向量库。这样应用就有了检索能力。最后在提示词里做一些约束比如“你是企业内部助手请基于知识库内容回答回答要简洁必要时说明出处。”保存后发布会生成一个对话Web页面和API接口团队成员直接访问链接提问。3.6 为Java/Python团队提供AI开发接口Dify和应用界面适合业务人员直接对话但很多企业还要让AI能力嵌入现有业务系统比如OA、ERP、客服后台。这时候需要把内网模型服务封装成接口提供给Java/Python团队调用。Ollama原生提供了兼容OpenAI格式的API所以Java后端可以用OpenAI Java客户端把base-url指向内网的http://127.0.0.1:11434/v1就能直接访问。示例代码var client OpenAI.builder() .baseUrl(http://127.0.0.1:11434/v1) .apiKey(ollama) .build();Python更简单import requests response requests.post( http://127.0.0.1:11434/api/generate, json{model: qwen2.5:7b, prompt: 请总结这段内容} )如果你想统一管控权限、做并发隔离可以在内网再加一层API网关把Ollama、向量检索、知识库逻辑封装为一个标准REST服务。这样普通后端开发完全不用理解大模型原理按照普通接口对接即可。这也是“降低AI开发门槛”落到实处的关键一环。4. 内网AI开发常见问题与排查记录4.1 内网没有外网依赖和模型怎么搬运这个问题问得最多。核心原则是找一台带外网的“摆渡机”把所有东西下载好打包拷贝进内网。软件安装包如Docker离线rpm/deb包。容器镜像docker save成tar内网docker load。大模型文件Ollama模型目录或GGUF文件。Python依赖通过pip download到目录内网pip install --no-index --find-links。搬运过程中最容易踩的坑是路径不一致。比如Ollama模型目录拷贝后权限或路径不对会导致ollama list看不到模型。解决方法是先在内网机器上启动一次Ollama生成目录结构再停止服务、覆盖文件、重启。另外镜像导入时要耐心等大文件加载完成不要在docker load过程强制中断。4.2 Windows Server 2016安装Docker失败怎么办很多企业内网服务器是Windows Server 2016标准版网上有大量吐槽帖。原因在于Docker Desktop从某个版本开始要求Windows 10 64位专业版或Windows Server 2019以上对Server 2016支持非常有限。就算强行用Docker Toolbox也是基于VirtualBox的老式Hyper-V方案性能和稳定性都很差。我的建议是不要和系统版本死磕。如果内网有虚拟化平台开一台最少2核4G的Linux虚拟机安装Ubuntu Server 22.04或Rocky Linux把Docker和AI应用全部跑在Linux里Windows服务器只做资源提供方。如果实在没有Linux环境至少升级到Windows Server 2019或2022再用Docker Desktop的Windows容器模式。记住Windows Server 2016跑容器不是不能但投入产出比太低后面维护会让你哭。4.3 内网GPU性能不足推理速度慢很多企业拿老旧的机器跑AI跑起来发现一个字一个字蹦等得心慌。这种情况先别急着加硬件可以从这几个维度优化换更小的量化模型比如从Q8降到Q4速度通常能提升2到3倍效果损失在可接受范围。减少上下文长度把Dify里的“上下文长度”从8192降到4096甚至2048降低显存/内存压力。关闭多余占用显存的程序包括桌面环境和无用的浏览器。如果是Ollama可以限制并发数比如设置OLLAMA_NUM_PARALLEL1避免多个请求同时抢显存。实在不行再考虑加卡。内网环境CPU推理也能跑但通常并发能力极差只适合开发测试。生产环境我建议至少有一块12G显存的GPU专门用来跑大模型另一部分CPU留给向量检索和应用服务。4.4 模型回答质量差不接地气有老板反馈模型是能跑起来但回答的和我们的业务对不上。原因一般不是模型笨而是RAG链路没调好。最常见的问题是文档切分不合理一句话被切开或者关键信息在多个章节里检索时只召回其中一部分。解决思路是按层级切分、适当增加重叠。Dify里可以调“切片长度”和“重叠长度”一般切片300到500字重叠50到100字比较合适。如果知识库里有大量表格、PDF扫描件需要先做OCR转成文本否则向量检索根本找不到内容。另外要给知识库设计“标题摘要”的元数据让检索阶段更容易匹配到正确片段。回答质量还可以靠“重排序”来提升。Dify支持配置rerank模型检索出Top50个片段后重排序挑出最相关的Top5效果比纯向量检索好很多推荐加上。4.5 团队缺乏AI开发经验怎么破这会涉及到组织推动的问题。我见过最快的落地方式是让一个后端工程师专门负责AI平台工具业务部门出一个人兼职整理知识库文档算法专家只做远程顾问。三个人三周就能把一个知识库问答应用上线。对普通工程师来说先不要碰LangChain源码不要碰模型微调不要在K8s上折腾。把Dify、Ollama、向量库这三样用好就能解决80%的实际问题。等大家对AI的能力边界有了真实感受再逐步引入Agent、工作流、复杂编排才不容易虎头蛇尾。4.6 数据安全与权限控制细节内网AI平台上线后权限控制很容易被忽略。企业知识库里可能有不同敏感级别的文档如果所有人都能问所有内容就会造成越权访问。合理做法是在Dify里创建多个知识库按部门或文档等级隔离。应用层面对接企业账号体系LDAP/AD控制谁能访问哪个应用。所有问答记录保存审计日志方便追溯。模型服务只开放给内网IP不要暴露到外网。数据安全并不只是“数据没出内网”就完了内部权限同样要细化否则等于把公司的资料库直接公放给全员。5. 一个月跑通内网AI开发的实践经验分享我帮一家中等规模的制造型企业搭过一整套内网AI知识库。他们的情况非常典型内网有几十台Windows服务器唯一一台能用的GPU是某员工自带的旧显卡数据散落在文件服务器、OA系统和个人电脑里没有任何人做过算法相关的工作。我们只做了一件事把员工手册、设备操作规程、维修案例、常见报错解决方案整理出来大约300多份文档做进RAG知识库然后用Dify发布了一个叫“智能制造问答助手”的应用。第一周搭环境Linux虚拟机、Docker、Ollama、Qwen2.5 7B量化模型、Qdrant、Dify全部就绪。第二周清数据把几百份Word、PDF、Excel统一转文本手工删掉大量废话和过期内容。第三周调检索和提示词反复测试不同切片长度、是否加重排序、系统提示词怎么写。第四周上线试用给车间主任和一线工程师演示让他们提问。最终效果是过去查一份设备维修手册要翻文件柜十分钟现在问一句就有答案还标了来源页码。这个过程中我有几个深刻体会第一内网AI开发最大的成本从来不是模型而是数据清洗。文档质量决定回答质量如果把一堆扫描件、加密PDF直接塞进去效果会惨不忍睹。第二先从一个特别小、特别具体的场景切入。不要一上来就做一个大而全的“企业大脑”那会陷入需求无底洞。从IT支持、行政问答、新人入职指引这类高频低风险的场景开始跑通一个再复制。第三低门槛工具不是玩具。Dify这类可视化平台在严肃业务场景下一样能扛住关键在于底层资源规划和权限设计做到位。不要因为“低代码”就看不上它它解决的恰恰是“没有算法工程师”的真实痛点。最后再分享一个小技巧内网AI环境建议把模型版本和知识库索引状态都记录下来每次更新文档后重新索引模型如果有新版本先在一个测试实例上验证确认无问题再替换生产实例。这样既能保持系统稳定又能持续迭代。如果你所在的企业也面临“数据不敢出网、AI没人会做”的困境别急着上高大上的平台先按照这条路线走一遍找一个具体问题、准备一台服务器、部署Ollama和Dify、扔进去几十份文档最快一周就能看到效果。等业务方说“这个真有用”之后再谈扩展和优化就顺理成章了。
