企业官网建设流程全解析

如果某天你所在的环境突然断网，而你手里正攥着一堆待处理的文档，需要AI帮你总结、翻译、问答——这时才发现，云端的那些大模型API全都用不了。这个场景不是科幻假设，我最近就实测了一遍：把内网服务器上的AI助手全部替换成LangChain+Ollama的本地模型方案，从对话、流式输出到知识库检索，全部离线完成。整个过程踩了不少坑，也攒下了一些可以直接复用的经验。

先说明白这个项目到底做什么：用LangChain作为应用编排框架，用Ollama作为本地模型的运行时环境，最终得到一个完全离线的AI助手。它能干的事包括多轮对话、流式输出、本地文档问答，所有数据都在本机流转，不需要把内容发给任何远端接口。适合三类读者：一是对数据隐私敏感的开发者，不希望对话内容传出本机；二是内网、实验室、生产环境这类没有外网但有算力的场景；三是想研究本地大模型技术栈，后续打算往模型优化、私有化部署方向走的人。

1. 整体方案设计：为什么是LangChain+Ollama

1.1 先把“离线”两个字拆清楚

很多人一听到“离线AI”，第一反应是“装个模型就行”。真做起来才发现，“离线”至少包含三层含义：

第一层是推理离线。模型权重存在本地硬盘，推理过程在本地CPU/GPU上完成，不需要调用任何云端推理接口。第二层是数据离线。对话内容、知识库文档、向量索引全部留在本机，不会因为请求第三方服务而把隐私数据带出去。第三层是应用链路离线。也就是从用户输入到Prompt组装、再到记忆管理和结果输出，整条管线都不依赖公网。

我选择的LangChain+Ollama组合，恰好能把这三层一次打通。LangChain负责上层的对话链、提示词管理、记忆和检索，Ollama负责底层的模型加载与推理服务。两件事各司其职，边界很清晰。

1.2 方案选型对比：为什么不是别的组合

做本地AI助手，市面上的路子不少，我实际比过几种，也简单列个对比：

我最终选LangChain+Ollama，核心原因是LangChain把“对话链”和“RAG检索”这些高频能力做成了标准接口，不需要我从零写一套prompt拼接逻辑。而Ollama把模型下载、加载、服务暴露这条链路封装得非常简单，一条命令就能启动一个本地推理服务，还能暴露OpenAI风格的接口，对开发者很友好。

1.3 架构组成与数据流向

整个系统的逻辑很简单，我先用文字描述一下：

用户发送消息后，LangChain的Prompt模板会把系统提示词、历史对话、可能的检索上下文组合成完整的输入；然后把输入交给ChatOllama实例，这个实例会连接本机的Ollama服务；Ollama加载模型后执行推理，把结果流式返回给LangChain；最后LangChain把回复内容输出给用户，同时把本轮问答追加到记忆里。

如果要接入知识库，就在Prompt组装之前增加一个环节：先把用户问题向量化，到本地的向量数据库里检索出最相关的片段，再把片段填充到Prompt的上下文槽位里。这就是标准的RAG流程，后面会专门讲。

这套结构的优势在于，每一层都可以独立替换。今天用的是Qwen系列模型，明天想换Llama系，只需要改动模型名；今天用Chroma做向量库，明天想切FAISS也只需要替换两行代码。这种松耦合带来的维护便利性，才是LangChain真正值钱的地方。

2. 基础环境准备：先把Ollama跑起来

2.1 安装与初始化

Ollama的安装在不同平台上的做法不大一样。Linux和macOS可以用官方安装脚本，Windows平台直接下载安装包。无论哪个平台，装完之后第一步都是确认命令行工具可用：

ollama --version

如果能正常输出版本号，说明安装成功。接着启动后台服务：

ollama serve

这个命令会启动一个默认监听在11434端口上的本地服务。注意，如果之前用过ollama run进入过交互式对话，服务可能已经起来了，不必重复启动。我在第一次部署时就是这里绕了一下，以为先ollama run之后就完事了，结果单独写代码调用时才发现服务根本没常驻。

验证服务是否正常，可以打开浏览器访问本机11434端口的根路径，或者直接在命令行用curl检查：

curl http://localhost:11434/api/tags

能返回模型列表JSON，就说明Ollama服务已经就绪。

2.2 模型选择与拉取

Ollama对模型的管理做得非常轻量。拉取模型只需一条命令：

ollama pull qwen2.5:7b

这条命令会从模型仓库把指定标签的模型下载到本地。下载完成后再执行ollama list就能看到本地已有的模型列表。

模型选型是本地部署的第一个重要决定点，我整理了这几档常见选择：

我的建议是：如果你主攻中文场景，优先qwen2.5系列；如果应用以英文为主又要较强的Agent能力，可以试试llama3.1。消费级显卡一般跑7B到8B的量化版本最舒服，再往上就要考验硬件了。

2.3 验证模型可用性

模型拉下来之后，先做一次最简单的交互验证：

ollama run qwen2.5:7b

进入交互界面后随便发一句话，比如“介绍一下你自己”，看模型能否正常回复。这一步能排除模型损坏、加载异常、显存不足等最基础的问题。

确认交互没问题后退出对话，保留后台服务，然后从代码侧做一个接口连通性测试。测试方法很简单，还是curl：

curl http://localhost:11434/api/generate \ -d '{"model": "qwen2.5:7b", "prompt": "你好", "stream": false}'

能返回包含response字段的JSON，说明推理链路是通的。走到这一步，环境基础就算打好了。

3. LangChain接入Ollama：三步搭起对话链

3.1 初始化ChatOllama

环境准备的第一步是安装Python依赖。我是在虚拟环境里操作的：

pip install langchain langchain-ollama

需要注意，LangChain最近版本迭代很快，不同版本的API细节有差异。我建议固定一个大版本，避免代码跑着跑着因为接口变更突然报错。我这里基于比较稳定的新版本写法，也就是用langchain-ollama这个专门的集成包。

接下来在Python里初始化模型：

from langchain_ollama import ChatOllama llm = ChatOllama( model="qwen2.5:7b", temperature=0.7, num_ctx=4096, ) resp = llm.invoke("请你用一句话解释什么是检索增强生成") print(resp.content)

这里的temperature控制的是生成随机性，取值0到2之间。做事实性问答时我建议调到0.2左右；做创意性写作可以提高到0.8以上。num_ctx是上下文窗口长度，直接影响模型能“记住”多少内容。默认值通常是2048，但如果要接知识库或长对话，4096起步才够用。

3.2 Prompt模板与链式调用

直接调用模型虽然简单，但真实项目里很少有人把裸模型扔给用户。我们通常需要给模型套上系统提示词，让它扮演特定角色、遵循输出格式。LangChain的ChatPromptTemplate就是干这个事的：

from langchain_core.prompts import ChatPromptTemplate prompt = ChatPromptTemplate.from_template( "你是一个严谨的技术助手。请回答用户问题。\n" "用户问题：{question}\n" "回答要求：言简意赅，如果存在不确定之处，请明确说明。" ) chain = prompt | llm result = chain.invoke({"question": "本地部署大模型有哪些优势？"}) print(result.content)

这里用|符号把Prompt和模型串成一条链，是LangChain新版的推荐写法。比较老的教程可能会教你用LLMChain或PromptTemplate，思路差不多，但API写法已经变了不少。网上搜索老教程时要注意版本匹配。

3.3 多轮对话与长期记忆

真正做AI助手，绕不开多轮对话。最朴素的做法是用一个列表把历史上的问答都记下来，每轮拼接成完整上下文再发给模型。但这样随着轮数增加，token消耗会越来越大。LangChain提供了记忆组件来管理这件事：

from langchain.memory import ConversationBufferMemory from langchain.chains import ConversationChain memory = ConversationBufferMemory(return_messages=True) conversation = ConversationChain(llm=llm, memory=memory) print(conversation.predict(input="我叫小林，是一名后端开发者")) print(conversation.predict(input="我刚刚介绍了自己，我叫什么名字？"))

我实测下来，第二句话模型能正确回答出“小林”。这就说明多轮信息被有效传递了，而不是每一轮都当成新对话处理。

如果你的对话场景很长，建议换用ConversationSummaryMemory，它会把早先的对话自动总结成摘要，再拼进上下文，这样能在上下文窗口有限的情况下展开更长对话。不过代价是每轮多一次“总结摘要”的模型调用，延迟会略有增加。

3.4 流式输出：让响应不再干等

调用invoke时，模型会等全部生成完再一次性返回结果。在7B模型上，一段100字的回复可能要好几秒，用户盯着“转圈”非常煎熬。解决办法是流式输出：

for chunk in llm.stream("写一段关于离线AI的前景分析，200字左右"): print(chunk.content, end="", flush=True)

实测下来，流式模式下第一个字出现的时间大幅提前，体感上比“等全部结果”好非常多。如果是Web应用，可以把这些chunk直接通过WebSocket或SSE推给前端；如果是命令行工具，也能像ollama run那样一个一个字打出来。让我说句实在话：用户体验这块，流式几乎是必须做的。

4. 给离线助手装个本地知识库：RAG实操

4.1 为什么必须上RAG

本地模型有一个天然的短板：它的知识截止于训练数据，对你的私有文档、最新资料一无所知。如果你问它“某个内网系统怎么部署”，它多半会一本正经地编一个答案。RAG（检索增强生成）就是解决这个问题的标准方案：先到本地文档库里检索相关内容，再把检索结果作为参考资料让模型作答。

这个流程拆开来就是四步：文档加载、文本切分、向量化存储、检索问答。下面逐一走一遍。

4.2 文档加载与文本切分

假设我们有一个帮助文档help.txt，第一步是把它读进来：

from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter loader = TextLoader("docs/help.txt") documents = loader.load() splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？"], ) chunks = splitter.split_documents(documents)

这里的chunk_size和chunk_overlap需要花点心思。chunk_size决定了每一段文本的长度，太小会导致检索片段信息不完整，太大又会让Prompt被撑爆。500到800个字符是文档问答里比较常用的区间。chunk_overlap让相邻片段之间存在少量重叠，避免一个完整句子被从中间切开后检索不到关键信息。我一开始图省事把overlap设为0，结果好几处换行附近的句子检索效果明显变差，后来改成50才缓解。

4.3 向量化与向量库

文本要变成能被检索的形式，就得向量化。这里我用Ollama自带的嵌入模型，不需要额外申请什么服务：

from langchain_ollama import OllamaEmbeddings from langchain_chroma import Chroma embeddings = OllamaEmbeddings(model="nomic-embed-text") vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_db", ) retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

向量库我选的是Chroma。它对离线部署特别友好：数据落在本地目录，不需要单独启动数据库服务。k=4表示每次检索取最相关的4个片段，数量太少容易漏信息，太多又会冲淡主题，4到6是常见取值。

这里有一个重要提醒：一定要先确认本地已经拉取了nomic-embed-text这个嵌入模型：

ollama pull nomic-embed-text

忘了拉模型的话，第一条向量化代码就会报连接错误，排查起来容易误以为是网络问题，其实只是本地缺模型。这个坑我踩过，印象很深。

4.4 组装检索问答链

有了检索器之后，就可以把它和之前的Prompt模板、模型串成一条完整的RAG链：

def format_docs(docs): return "\n\n".join(doc.page_content for doc in docs) from langchain_core.runnables import RunnablePassthrough rag_chain = ( { "context": retriever | format_docs, "question": RunnablePassthrough(), } | prompt | llm ) answer = rag_chain.invoke("离线部署时需要注意哪些点？") print(answer.content)

这里用户问题会同时流向两个地方：一边直接放进Prompt的question槽位，一边被拿去检索出context上下文。然后Prompt带着问题和检索结果一起交给模型，模型就能基于文档内容作答，而不是凭空发挥。

我测过一个很典型的例子：把我自己的部署笔记塞进知识库，然后问“Ollama默认端口是多少”，模型能准确答出11434，并且会附加说明这是从部署笔记中总结的。而同一个问题直接问裸模型，答案往往含糊其辞。这就是知识库的价值所在。

4.5 知识库维护注意事项

RAG链路跑通只是起点，长期维护还有几件事要留意：

第一，文档更新后要同步重建向量索引。Chroma的from_documents每次都会重新创建集合。如果后续要增量更新，可以改用vectorstore.add_documents的方式追加。第二，嵌入模型一旦选定，尽量不要中途更换，因为不同嵌入模型产出的向量空间不一致，换模型意味着全量重建索引。第三，定期检查本地磁盘占用，向量库看起来轻，文档一多体积涨得也很快。

5. 性能调优与常见问题排查实录

5.1 关键参数调优：把体验拉上去

本地模型部署最让人纠结的就是响应速度和生成质量。根据我这几天的实测，真正值得调的就几个点。

首先看并发参数。Ollama默认在同一时间只能处理一个请求，如果多个用户同时调用，后面的请求会排队。可以在启动服务时设置环境变量来打开并行能力：

OLLAMA_NUM_PARALLEL=2 ollama serve

这个值不建议调太高，毕竟显存和内存是有限的，并发处理2到4个请求已经是消费级硬件的舒适区了。调太高会导致单请求生成速度明显下降，甚至直接显存溢出。

其次是模型常驻问题。默认情况下，模型在处理完请求后会在内存里驻留一段时间，如果没请求了就自动卸载。这个驻留时间可以通过环境变量控制：

OLLAMA_KEEP_ALIVE=30m ollama serve

意思是模型空闲30分钟后才卸载。如果你做的是交互应用，建议把这个时间设长一点；如果机器内存紧张，可以设短一点，甚至设为0，用完立即卸载。

我用ollama ps命令观察过模型驻留情况，这个命令能显示当前加载的模型、占用的显存大小和处理状态。排查性能问题的时候非常有用。

然后是生成参数的微调。除了前面说的temperature，num_ctx也值得注意。如果发现模型“忘”了对话前面的内容，先看一眼num_ctx是不是太小。2048的窗口做知识库问答常常不够用，我会至少开到4096。窗口越大，KV Cache占用的显存也越多，这个要跟硬件配置权衡。

5.2 常见问题与解决方案速查

5.3 避坑清单与实操心法

最后分享几条常规文档里不会写的东西。

第一，模型版本要有意识地锁定。Ollama的模型标签机制支持固定版本，比如qwen2.5:7b-instruct-q4_K_M这类量化标签。不要在代码里用裸模型名到处拼，最好在环境配置里维护模型列表。否则某天拉取了新版模型，行为变化会导致应用表现莫名异常。

第二，RAG检索结果一定要做“来源可溯”。我实测过一个痛点：模型有时会在引用文档内容时掺入自己的“幻觉”，编出文档里没有的细节。解决办法是在Prompt里严格要求模型只基于上下文回答，并在输出时附带片段来源标记。虽然这没法100%杜绝幻觉，但能明显降低答错概率。

第三，不要忽视CPU推理场景。如果机器没有独显，7B模型用CPU跑也能出结果，只是速度大约能到每秒几个token。这种场景下，模型选择要更保守，优先选更小的量化版本；同时把num_ctx降到2048，减少计算量。强上大模型只会让体验变成“卡死式问答”。

第四，文本切分要跟着内容走。代码文档和技术笔记最好按函数、章节切分，常规的“固定字符数”切分虽然省事，但效果往往一般。我后来在切分器里额外加了代码块分隔符，检索命中率提升非常明显。别把切分当成一个无脑参数，它直接决定检索质量的上限。

这套方案跑下来，最大的体会是：本地AI助手不是“装个模型”那么简单，但也没有想象中那么难。难的部分在于把模型、框架、检索、记忆这些环节组装成一条能稳定运行的链路。一旦链路通了，你会发现自己对AI应用的控制力强了很多——模型随便换、Prompt随便调、数据全在自己手里，不再受制于外部服务的限额和延迟。

如果你也是刚开始折腾本地模型，我建议你先从最简单的对话链开始，跑通LangChain连接Ollama的流程，再逐步加上记忆和知识库。不要一上来就堆组件，每加一层都验证一次。现在这套组合已经成了我日常工作的默认工具，虽然还没达到顶尖云端模型的聪明程度，但胜在安心、可控、不花钱。下一步我准备把文档问答的检索质量再往上提一提，顺便试试让模型能自己调用本地的脚本工具，那应该是另一个有意思的话题了。