如果某天你所在的环境突然断网而你手里正攥着一堆待处理的文档需要AI帮你总结、翻译、问答——这时才发现云端的那些大模型API全都用不了。这个场景不是科幻假设我最近就实测了一遍把内网服务器上的AI助手全部替换成LangChainOllama的本地模型方案从对话、流式输出到知识库检索全部离线完成。整个过程踩了不少坑也攒下了一些可以直接复用的经验。先说明白这个项目到底做什么用LangChain作为应用编排框架用Ollama作为本地模型的运行时环境最终得到一个完全离线的AI助手。它能干的事包括多轮对话、流式输出、本地文档问答所有数据都在本机流转不需要把内容发给任何远端接口。适合三类读者一是对数据隐私敏感的开发者不希望对话内容传出本机二是内网、实验室、生产环境这类没有外网但有算力的场景三是想研究本地大模型技术栈后续打算往模型优化、私有化部署方向走的人。1. 整体方案设计为什么是LangChainOllama1.1 先把“离线”两个字拆清楚很多人一听到“离线AI”第一反应是“装个模型就行”。真做起来才发现“离线”至少包含三层含义第一层是推理离线。模型权重存在本地硬盘推理过程在本地CPU/GPU上完成不需要调用任何云端推理接口。第二层是数据离线。对话内容、知识库文档、向量索引全部留在本机不会因为请求第三方服务而把隐私数据带出去。第三层是应用链路离线。也就是从用户输入到Prompt组装、再到记忆管理和结果输出整条管线都不依赖公网。我选择的LangChainOllama组合恰好能把这三层一次打通。LangChain负责上层的对话链、提示词管理、记忆和检索Ollama负责底层的模型加载与推理服务。两件事各司其职边界很清晰。1.2 方案选型对比为什么不是别的组合做本地AI助手市面上的路子不少我实际比过几种也简单列个对比方案优点缺点适用场景商用云端API效果好、接入快数据出网、按量付费、断网即停原型验证、无敏感数据LangChain Ollama完全本地、工程化友好、生态成熟受本机算力限制、模型能力弱于顶级云端内网部署、隐私敏感、长期运营原生Python推理脚本配合transformers等自由度最高、可精细控制需要自己处理缓存、批处理、服务化开发量大研究实验、算法调优直接跑Ollama不带框架简单直接难做记忆、工具调用、知识库检索单机随便聊几句我最终选LangChainOllama核心原因是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:7b70亿8GB以上中文效果好、综合能力均衡llama3.1:8b80亿8GB以上英文生态好、工具调用能力强mistral:7b70亿8GB以上轻量、速度快qwen2.5:14b140亿16GB以上中文能力更强、更接近商业模型体验我的建议是如果你主攻中文场景优先qwen2.5系列如果应用以英文为主又要较强的Agent能力可以试试llama3.1。消费级显卡一般跑7B到8B的量化版本最舒服再往上就要考验硬件了。2.3 验证模型可用性模型拉下来之后先做一次最简单的交互验证ollama run qwen2.5:7b进入交互界面后随便发一句话比如“介绍一下你自己”看模型能否正常回复。这一步能排除模型损坏、加载异常、显存不足等最基础的问题。确认交互没问题后退出对话保留后台服务然后从代码侧做一个接口连通性测试。测试方法很简单还是curlcurl 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( modelqwen2.5:7b, temperature0.7, num_ctx4096, ) 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_messagesTrue) conversation ConversationChain(llmllm, memorymemory) 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, flushTrue)实测下来流式模式下第一个字出现的时间大幅提前体感上比“等全部结果”好非常多。如果是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_size500, chunk_overlap50, 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(modelnomic-embed-text) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db, ) retriever vectorstore.as_retriever(search_kwargs{k: 4})向量库我选的是Chroma。它对离线部署特别友好数据落在本地目录不需要单独启动数据库服务。k4表示每次检索取最相关的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_PARALLEL2 ollama serve这个值不建议调太高毕竟显存和内存是有限的并发处理2到4个请求已经是消费级硬件的舒适区了。调太高会导致单请求生成速度明显下降甚至直接显存溢出。其次是模型常驻问题。默认情况下模型在处理完请求后会在内存里驻留一段时间如果没请求了就自动卸载。这个驻留时间可以通过环境变量控制OLLAMA_KEEP_ALIVE30m ollama serve意思是模型空闲30分钟后才卸载。如果你做的是交互应用建议把这个时间设长一点如果机器内存紧张可以设短一点甚至设为0用完立即卸载。我用ollama ps命令观察过模型驻留情况这个命令能显示当前加载的模型、占用的显存大小和处理状态。排查性能问题的时候非常有用。然后是生成参数的微调。除了前面说的temperaturenum_ctx也值得注意。如果发现模型“忘”了对话前面的内容先看一眼num_ctx是不是太小。2048的窗口做知识库问答常常不够用我会至少开到4096。窗口越大KV Cache占用的显存也越多这个要跟硬件配置权衡。5.2 常见问题与解决方案速查现象可能原因解决办法调用时报连接错误Ollama服务没启动先执行ollama serve再用curl检测11434端口请求时显存溢出模型过大或num_ctx过大换小参数模型调低num_ctx关闭其他占显存的程序中文回答夹杂乱码模型对中文支持一般换qwen系列中文模型或在Prompt中明确“请用简体中文回答”首次生成特别慢模型正在加载这是冷启动现象尽量用keep_alive把模型常驻多用户请求排队并发数限制设置OLLAMA_NUM_PARALLEL一般2即可知识库答案与问题无关嵌入模型不合适或分块不合理换bge系列嵌入模型调整chunk_overlap增大k值模型回复很快但废话很多Prompt约束不足在系统提示词里明确输出格式、字数限制拉取模型时进度卡住网络波动等待重试或换源Ollama通常支持断点续传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的流程再逐步加上记忆和知识库。不要一上来就堆组件每加一层都验证一次。现在这套组合已经成了我日常工作的默认工具虽然还没达到顶尖云端模型的聪明程度但胜在安心、可控、不花钱。下一步我准备把文档问答的检索质量再往上提一提顺便试试让模型能自己调用本地的脚本工具那应该是另一个有意思的话题了。
如果某天你所在的环境突然断网而你手里正攥着一堆待处理的文档需要AI帮你总结、翻译、问答——这时才发现云端的那些大模型API全都用不了。这个场景不是科幻假设我最近就实测了一遍把内网服务器上的AI助手全部替换成LangChainOllama的本地模型方案从对话、流式输出到知识库检索全部离线完成。整个过程踩了不少坑也攒下了一些可以直接复用的经验。先说明白这个项目到底做什么用LangChain作为应用编排框架用Ollama作为本地模型的运行时环境最终得到一个完全离线的AI助手。它能干的事包括多轮对话、流式输出、本地文档问答所有数据都在本机流转不需要把内容发给任何远端接口。适合三类读者一是对数据隐私敏感的开发者不希望对话内容传出本机二是内网、实验室、生产环境这类没有外网但有算力的场景三是想研究本地大模型技术栈后续打算往模型优化、私有化部署方向走的人。1. 整体方案设计为什么是LangChainOllama1.1 先把“离线”两个字拆清楚很多人一听到“离线AI”第一反应是“装个模型就行”。真做起来才发现“离线”至少包含三层含义第一层是推理离线。模型权重存在本地硬盘推理过程在本地CPU/GPU上完成不需要调用任何云端推理接口。第二层是数据离线。对话内容、知识库文档、向量索引全部留在本机不会因为请求第三方服务而把隐私数据带出去。第三层是应用链路离线。也就是从用户输入到Prompt组装、再到记忆管理和结果输出整条管线都不依赖公网。我选择的LangChainOllama组合恰好能把这三层一次打通。LangChain负责上层的对话链、提示词管理、记忆和检索Ollama负责底层的模型加载与推理服务。两件事各司其职边界很清晰。1.2 方案选型对比为什么不是别的组合做本地AI助手市面上的路子不少我实际比过几种也简单列个对比方案优点缺点适用场景商用云端API效果好、接入快数据出网、按量付费、断网即停原型验证、无敏感数据LangChain Ollama完全本地、工程化友好、生态成熟受本机算力限制、模型能力弱于顶级云端内网部署、隐私敏感、长期运营原生Python推理脚本配合transformers等自由度最高、可精细控制需要自己处理缓存、批处理、服务化开发量大研究实验、算法调优直接跑Ollama不带框架简单直接难做记忆、工具调用、知识库检索单机随便聊几句我最终选LangChainOllama核心原因是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:7b70亿8GB以上中文效果好、综合能力均衡llama3.1:8b80亿8GB以上英文生态好、工具调用能力强mistral:7b70亿8GB以上轻量、速度快qwen2.5:14b140亿16GB以上中文能力更强、更接近商业模型体验我的建议是如果你主攻中文场景优先qwen2.5系列如果应用以英文为主又要较强的Agent能力可以试试llama3.1。消费级显卡一般跑7B到8B的量化版本最舒服再往上就要考验硬件了。2.3 验证模型可用性模型拉下来之后先做一次最简单的交互验证ollama run qwen2.5:7b进入交互界面后随便发一句话比如“介绍一下你自己”看模型能否正常回复。这一步能排除模型损坏、加载异常、显存不足等最基础的问题。确认交互没问题后退出对话保留后台服务然后从代码侧做一个接口连通性测试。测试方法很简单还是curlcurl 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( modelqwen2.5:7b, temperature0.7, num_ctx4096, ) 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_messagesTrue) conversation ConversationChain(llmllm, memorymemory) 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, flushTrue)实测下来流式模式下第一个字出现的时间大幅提前体感上比“等全部结果”好非常多。如果是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_size500, chunk_overlap50, 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(modelnomic-embed-text) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db, ) retriever vectorstore.as_retriever(search_kwargs{k: 4})向量库我选的是Chroma。它对离线部署特别友好数据落在本地目录不需要单独启动数据库服务。k4表示每次检索取最相关的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_PARALLEL2 ollama serve这个值不建议调太高毕竟显存和内存是有限的并发处理2到4个请求已经是消费级硬件的舒适区了。调太高会导致单请求生成速度明显下降甚至直接显存溢出。其次是模型常驻问题。默认情况下模型在处理完请求后会在内存里驻留一段时间如果没请求了就自动卸载。这个驻留时间可以通过环境变量控制OLLAMA_KEEP_ALIVE30m ollama serve意思是模型空闲30分钟后才卸载。如果你做的是交互应用建议把这个时间设长一点如果机器内存紧张可以设短一点甚至设为0用完立即卸载。我用ollama ps命令观察过模型驻留情况这个命令能显示当前加载的模型、占用的显存大小和处理状态。排查性能问题的时候非常有用。然后是生成参数的微调。除了前面说的temperaturenum_ctx也值得注意。如果发现模型“忘”了对话前面的内容先看一眼num_ctx是不是太小。2048的窗口做知识库问答常常不够用我会至少开到4096。窗口越大KV Cache占用的显存也越多这个要跟硬件配置权衡。5.2 常见问题与解决方案速查现象可能原因解决办法调用时报连接错误Ollama服务没启动先执行ollama serve再用curl检测11434端口请求时显存溢出模型过大或num_ctx过大换小参数模型调低num_ctx关闭其他占显存的程序中文回答夹杂乱码模型对中文支持一般换qwen系列中文模型或在Prompt中明确“请用简体中文回答”首次生成特别慢模型正在加载这是冷启动现象尽量用keep_alive把模型常驻多用户请求排队并发数限制设置OLLAMA_NUM_PARALLEL一般2即可知识库答案与问题无关嵌入模型不合适或分块不合理换bge系列嵌入模型调整chunk_overlap增大k值模型回复很快但废话很多Prompt约束不足在系统提示词里明确输出格式、字数限制拉取模型时进度卡住网络波动等待重试或换源Ollama通常支持断点续传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的流程再逐步加上记忆和知识库。不要一上来就堆组件每加一层都验证一次。现在这套组合已经成了我日常工作的默认工具虽然还没达到顶尖云端模型的聪明程度但胜在安心、可控、不花钱。下一步我准备把文档问答的检索质量再往上提一提顺便试试让模型能自己调用本地的脚本工具那应该是另一个有意思的话题了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
