做本地知识库这件事最近一年多几乎是 RAG 入门者的必经之路。很多团队的第一步是“先装一个大模型把文档扔进向量库然后让模型自己回答”。从现象看这个流程没什么问题从工程结果看大部分人都会在中间卡住文档格式五花八门、切分参数不会调、检索出来的片段和问题不相关模型倒是很流畅但回答明显是编的。真正的问题不是“模型不够聪明”而是从文档到检索结果这一段工程链路还没有被系统梳理。这篇文章要聊的方案是 LangFlow Ollama 的组合Ollama 负责在本地提供开源大模型LangFlow 负责可视化拖拽编排 RAG 流程整个过程基本不写代码。我会用一个“健康档案私有知识库”作为例子把文档加载、文本切分、向量化、存储、检索、生成回答的完整链路走一遍同时讲清楚每一步为什么存在、容易踩什么坑、以及如何验证效果。如果你已经装过 LangFlow 和 Ollama只是没想清楚怎么把一堆文档变成可问答的知识库读完可以直接照着做。如果还没装环境准备部分也给了完整的安装命令。1. 你真正卡住的地方本地知识库不是“装个大模型”就行很多初次接触本地 AI 的开发者会把“本地大模型”和“本地知识库”混为一谈。这里要说清楚一个判断Ollama 本身只是模型运行环境它能让 qwen2.5 这类开源模型在本地跑起来但它不具备把你的资料变成可检索知识的能力。如果你想做的只是“本地聊天机器人”那 Ollama 加一个 WebUI 就够了。但如果你想让模型根据体检报告、门诊记录、企业内部手册、产品文档来回答具体问题你需要的是 RAG而不是一个能聊天的模型。为什么要区分这两个需求因为“知识库问答”对结果的要求完全不同。普通聊天可以让模型自由发挥而知识库问答要求模型“只根据你提供的资料回答”没有资料就不能编。健康档案这种场景尤其如此使用者问的不是“高血压是什么”而是“张三在过去一年的体检中血压有没有持续偏高”这种答案只能来自上传的档案不能来自模型的常识。下表可以直观看出直接对话和知识库问答的区别对比维度直接用大模型聊天本地知识库 RAG 应用模型知识来源训练时学到的通用知识你的私有文档 通用知识回答私密材料的问题无法做到模型没看过你的数据可以通过检索把资料放入上下文数据是否离开本地在线 API 方案会离开本地本地部署可不离开内网主要开发成本非常简单文档处理与检索调优典型工具链Ollama WebUIOllama 向量库 流程编排在工程实践里知识库问答真正费时间的是“文档怎么进知识库”而不是“模型怎么回答”。文档结构五花八门有人上传 PDF、有人上传 Word、有人直接用 Markdown内容有长段落、有表格、有重复性水印。如果不做清洗和切分检索出来的片段就会很混乱模型拿到混乱上下文回答自然不可靠。前 300 字已经说清楚了本文要讲的是“本地知识库 RAG 应用”核心判断是“先解决数据链路再谈模型”读者能收获的是一套从环境安装到效果验证的完整路径。2. 三大核心概念LangFlow、Ollama、RAG2.1 RAG为什么本地知识库必须靠它RAG 的全称是 Retrieval-Augmented Generation检索增强生成。它解决的问题是大模型训练完成后知识就固定了不可能知道你的内部资料。RAG 的做法是在模型回答问题之前先从你的文档库中检索出相关片段把这些片段和问题一起交给模型模型基于这些片段生成答案。如果你没有 RAG想让模型理解私有资料通常只有两条路一条是把资料拼进提示词但长篇文档会超过模型上下文窗口另一条是微调模型但微调成本高、周期长而且更新的资料不能立即生效。RAG 的工程链路可以拆成五步加载文档把 PDF、Word、Markdown 变成纯文本。切分文本把长文本切成合适大小的块便于检索。向量化用 Embedding 模型把文本块变成向量。存储与检索把向量存入向量库用户提问后做相似度检索。生成回答把命中的文本块与问题组装成提示词交给大模型。“检索增强”这四个字是关键。模型不需要记住你的全部文档只要在每次提问时拿到最相关的片段就能给出看起来像“懂你的资料”的回答。2.2 Ollama让开源大模型像本地服务一样可用Ollama 是一个本地模型运行工具它把模型下载、模型推理、API 暴露这些底层细节封装起来让开发者用几条命令就能在本地跑一个大模型。Ollama 有两个点对 RAG 特别重要。第一它不仅能跑对话模型也能跑 Embedding 模型。RAG 链路中的“向量化”步骤也需要一个模型这个模型通常不是大家熟悉的聊天模型而是一个专门的文本向量模型比如 nomic-embed-text。Ollama 可以把这类模型也作为服务暴露出来LangFlow 可以直接调用。第二Ollama 默认暴露一个 HTTP API端口是 11434。LangFlow 不需要直接操作底层推理代码只需要通过这个 API 向 Ollama 发请求。这意味着模型部分和流程编排部分是解耦的。从部署角度看Ollama 降低了本地运行开源大模型的门槛。过去你要自己下载模型权重、写推理脚本、处理 GPU 依赖现在ollama pull一条命令可以拉取模型ollama run可以直接启动一个类似命令行的对话环境。2.3 LangFlow把 RAG 的工程流程可视化LangFlow 是一个可视化流程编排平台底层基于 LangChain 生态但把组件做成了可视化节点。你可以用拖拽的方式把“文档加载”“文本切分”“向量库”“大模型”等节点连接起来形成一个数据流而不是写一整套链式代码。这一点很容易被误解成“不用懂技术也能做 AI 应用”。实际上LangFlow 降低的是编程门槛但并没有降低理解门槛。你仍然需要知道 RAG 的各个环节、每个参数的含义、数据从哪里来到哪里去。否则只是把节点连上并不知道为什么结果不对。LangFlow 也很适合做原型验证。你的知识库可能经常变化文档格式不同、切分策略不同、检索参数不同如果每次都写代码再跑一遍效率很低。在 LangFlow 里只要调整组件参数重新运行就能看到效果。2.4 顺带澄清RAG 和 MCP 不是同一个东西最近 MCP 这个概念很火也经常有人把 RAG 和 MCP 放在一起讨论。这里做个简单区分。RAG 解决的“知识获取”问题核心是“模型怎么得到它不知道的私有资料”。MCP 全称 Model Context Protocol解决的是“工具调用”问题核心是“模型怎么通过统一协议去调用外部工具和系统”。用一个类比来说RAG 是给模型递上一本参考书MCP 是给模型递上一个工具箱。两者可以配合使用RAG 给模型提供知识上下文MCP 让模型去执行具体操作比如查数据库、写一条记录、调用某个外部服务。如果你只是做本地知识库问答暂时不需要 MCP。先把 RAG 链路跑通后续再考虑让 Agent 调用工具。3. 方案选型为什么推荐 LangFlow Ollama而不是手写 LangChain 或换一个平台搭建本地知识库并不是只有 LangFlow Ollama 一条路。更常见的是手写 LangChain 代码或者用 Dify 这类可视化平台。这里给出一个选型判断而不是单纯罗列功能。手写 LangChain 的优势是灵活、可控、可测试适合最终要封装成生产服务的团队。但缺点是调试链路长你需要自己处理依赖版本、文本加载器、向量库接口、提示词模板、异常处理等等。如果只是做一个内部知识库这个成本是偏高的。Dify 是另一个热门方案它的产品化程度更高自带知识库管理、对话界面、权限和日志能力适合想要快速上线完整应用的团队。但 Dify 更像一个平台会约束你按它的规则来组织数据和流程。LangFlow 更接近“面向开发者的流程图工具”节点和连接更贴近 LangChain 的原始抽象。选型适合场景主要成本手写 LangChain Ollama最终要交付 API 服务需要深度定制编码和调试成本高Dify Ollama想要平台化界面和知识库管理团队愿意接受平台约束学习平台规则、扩展不灵活LangFlow Ollama快速验证 RAG 流程、中小规模内部知识库需要理解节点含义和参数我的判断是LangFlow Ollama 最适合“想要快速跑通又希望保留理解和控制权”的开发者。它不会替你生成一个完整产品但它能让你在半天内跑出一条可用的知识库问答链路并且 Flow 可以导出后续再迁移到代码实现。4. 环境准备与前置条件4.1 硬件建议本地跑大模型对硬件有基本要求。如果只是测试用 CPU 也可以跑但速度会慢。如果想要流畅体验建议满足以下条件内存16GB 以上32GB 更舒适。显卡显存8GB 以上可以跑 7B 级别的量化模型如果没有独立显卡选择 3B 或更小的模型。磁盘模型文件通常从 2GB 到 8GB 不等预留 20GB 空间比较稳妥。这里不写死具体版本和参数因为模型和依赖更新频繁。建议以“能跑动、速度可接受”为目标先小后大。4.2 安装 Ollama 并下载两个模型Ollama 支持 macOS、Linux 和 Windows。Linux 下可以直接用官方安装脚本curl -fsSL https://ollama.com/install.sh | shWindows 用户可以直接下载安装包安装完成后在终端执行命令。macOS 同理官方提供了.dmg安装包。安装完成后拉取两个模型一个对话模型用于最终回答一个 Embedding 模型用于向量化。# 拉取对话模型7b 是常用选择机器配置低可以用 3b ollama pull qwen2.5:7b # 拉取 Embedding 模型用于把文本转成向量 ollama pull nomic-embed-text # 检查本地已有模型 ollama list如果拉取速度很慢可以换一个网络环境稍后再试或者从同事的本地机器上导出模型文件后在内部网络导入。模型下载完成后后面所有流程都不需要联网调用模型。4.3 安装并启动 LangFlowLangFlow 建议通过 Python 环境安装。Python 版本建议使用 3.10 及以上具体兼容范围以官方文档为准。# 创建虚拟环境避免污染全局 Python python -m venv .venv # 激活虚拟环境Windows 下命令略有区别 source .venv/bin/activate # 安装 LangFlow pip install langflow # 启动 LangFlow python -m langflow run启动后浏览器访问http://127.0.0.1:7860会出现 LangFlow 的编辑器界面。如果 7860 端口被占用可以用--port参数换一个端口。LangFlow 也支持 Docker 方式启动。如果你熟悉 Docker可以用官方镜像运行但需要确认版本与系统兼容性。第一次使用建议直接用 Python 方式排查依赖更方便。4.4 验证 Ollama 服务可用LangFlow 接入 Ollama 前最好先手动验证一下 Ollama 是否正常工作。最简单的方式是看模型是否已加载ollama list如果列表里有qwen2.5:7b和nomic-embed-text说明下载成功。再用 curl 测试对话接口curl http://localhost:11434/api/chat \ -d {model:qwen2.5:7b,messages:[{role:user,content:你好}]}如果返回一段 JSON其中包含message字段说明 Ollama 服务正常。如果端口不通检查 Ollama 是否启动部分操作系统需要手动开启后台服务。5. 十分钟搭一个健康档案知识库核心流程拆解这里说的“十分钟”前提是 Ollama 模型已经下载完毕LangFlow 已经启动。从打开浏览器、拖拽节点、配置参数到第一次跑通问答十分钟是完全可实现的。5.1 明确业务场景我们的示例场景是健康档案私有知识库。假设你手头有一批门诊记录和体检报告想要问这些档案中的问题比如“这位患者目前服用什么药物”“过去三次血压检查结果分别是多少”“患者有没有需要复查的异常指标”这类问题有明确答案且答案藏在文档里。如果模型凭常识回答就会出错。所以我们要通过 RAG 约束它“必须基于资料回答”。这里要强调一个合规问题不要把真实患者信息直接丢进本地模型。演示过程建议使用伪造数据生产环境要做脱敏和权限控制。这个话题在最佳实践章节还会展开。5.2 RAG 五步流程在健康档案里的具体含义第一步加载。把健康档案文件载入系统。如果文件是 PDF最好先确认是文本型 PDF 还是扫描件。扫描件需要 OCR 处理否则加载出来的可能是乱码。第二步切分。档案中通常有“既往病史”“用药记录”“检查结果”等段落。切分时最好按语义边界切不要把一个完整就诊记录从中间切断。第三步向量化。把切分出的每个文本块用 Embedding 模型转成向量。这个向量代表文本的语义检索时通过向量相似度找到最相关的文本块。第四步检索。用户提问后系统把问题也转成向量和库中所有文本块做相似度比较返回最相关的几个块。第五步生成。把命中的文本块和用户问题拼成一个提示词交给大模型生成回答。提示词里要明确“只根据资料回答资料中没有就不要编造”。整个流程的本质是把“模型不认识你的文档”这个缺陷通过检索的方式补上。5.3 LangFlow 中的组件映射在 LangFlow 编辑器里上面的五步变成了下面这些节点流程步骤LangFlow 节点作用加载文档File Loader读入 Markdown、TXT、PDF 等文件文本切分Split Text按长度和重叠切分文本向量化Ollama Embeddings调用本地的 Embedding 模型存储与检索Chroma / Vector Store保存向量并根据查询相似度返回结果生成回答Ollama Model Prompt Chat Output组装提示词并调用对话模型组件连接时上游输出会直接成为下游输入。最常见的错误是把连接线接错导致下游拿到的不是期望的数据类型。遇到异常先点击节点查看中间输出。6. 完整示例一份健康档案 RAG 应用的搭建步骤6.1 准备演示文档为了演示先创建一份假的健康档案。内容建议用markdown或txt格式方便做首测。下面是一份可复制的示例# 张三健康档案演示数据非真实患者 ## 个人信息 姓名张三 年龄45岁 身高175cm体重82kg ## 既往病史 高血压确诊2年目前规律服用氨氯地平5mg每日一次。 无糖尿病史无药物过敏史。 ## 体检记录2025-01 血压145/95mmHg 总胆固醇5.8mmol/L 空腹血糖6.1mmol/L 建议低盐低脂饮食注意血压监测。 ## 体检记录2025-06 血压138/88mmHg 总胆固醇5.2mmol/L 空腹血糖5.8mmol/L 建议维持当前用药增加有氧运动。这是一份典型的私有资料。你希望模型能回答“张三最近的血压是多少”“张三吃的是什么药”这类问题。6.2 在 LangFlow 中拖拽核心流程打开 LangFlow 后新建一个 Flow按顺序创建两组节点。索引部分添加一个 File Loader 或 Text Loader 节点选择刚创建的health_record.md。添加 Split Text 节点连接在 File Loader 后面。添加 Ollama Embeddings 节点配置模型为nomic-embed-text。添加 Chroma 向量库节点把 Split Text 的输出和 Embeddings 的输出同时连进去。运行一次索引流程让文档写入向量库。问答部分添加 Chroma / Vector Store 的检索节点配置同样的向量库设置返回数量 k比如3。添加 Prompt 节点用来组装提示词。添加 Ollama Model 节点配置对话模型为qwen2.5:7b。添加 Chat Output 节点用于展示答案。连接关系大致是问题输入 - 检索器 - Prompt - Ollama Model - Chat Output同时检索器需要读向量库向量库需要 EmbeddingsEmbeddings 需要连接到 Ollama。6.3 关键组件配置先看 Embedding 节点。它的作用是调用 Ollama 的 Embedding 模型把文本变成向量。配置要点是模型名称必须和你实际拉取的模型一致比如nomic-embed-text。这里最容易犯的错是索引时用了一个 Embedding 模型检索问答时换了另一个 Embedding 模型导致向量空间不一致检索结果完全失真。再看 Split Text 节点。对中文健康档案建议初始配置chunk_size400chunk_overlap50。chunk_overlap的作用是让相邻文本块有重叠避免关键句正好落在两块交界处被丢掉。如果档案非常结构化每段就是一个完整小节可以不做过度切分直接按段落进入向量库。Prompt 节点是控制模型行为的关键。一个可用模板如下请根据以下资料回答问题。资料中如果没有相关内容请直接回答“资料中未找到该信息”不要编造。 资料 {context} 问题 {question}大模型对指令非常敏感这句话决定了模型是否“守住边界”。6.4 不靠界面时底层代码长什么样LangFlow 的可视化节点本质上是在串联 LangChain 生态中的组件。如果你后面要把流程封装成 API或者想理解可视化背后的逻辑可以参考下面的 Python 版本。这段代码不是为了让你在 LangFlow 里再敲一遍而是为了让你看懂节点之间的数据流。# 文件路径rag_demo.py # 依赖安装pip install langchain-ollama langchain-chroma langchain-text-splitters from pathlib import Path from langchain_chroma import Chroma from langchain_ollama import OllamaEmbeddings, OllamaLLM from langchain_text_splitters import RecursiveCharacterTextSplitter # 1. 读取文档 text Path(health_record.md).read_text(encodingutf-8) # 2. 切分文本 splitter RecursiveCharacterTextSplitter( chunk_size400, chunk_overlap50, ) docs splitter.create_documents([text]) # 3. 向量化 embeddings OllamaEmbeddings(modelnomic-embed-text) # 4. 写入向量库 vectorstore Chroma.from_documents( docs, embeddings, persist_directory./health_kb, ) retriever vectorstore.as_retriever(search_kwargs{k: 3}) # 5. 检索 生成 llm OllamaLLM(modelqwen2.5:7b) question 张三最近的血压是多少 context_docs retriever.invoke(question) context \n\n.join([doc.page_content for doc in context_docs]) prompt f请根据以下资料回答问题。资料中如果没有相关内容请直接回答“资料中未找到该信息”不要编造。 资料 {context} 问题 {question} answer llm.invoke(prompt) print(answer)运行这段代码后输出应该包含张三最近一次体检的血压数值。如果输出不在资料里基本可以判断是检索没命中或者提示词约束失效。6.5 运行与效果验证在 LangFlow 界面中运行索引流程后再切换到问答部分输入问题张三最近的血压是多少预期回答大概是根据资料张三在2025年6月的血压为138/88mmHg。为了判断系统是否真的在“用你的知识库”可以准备三组测试问题文档中直接能查到答案的问题比如“张三吃的是什么药”。需要跨段落推理的问题比如“两次体检之间血压有什么变化”。文档中没有答案的问题比如“张三的既往手术史是什么”必须回答“未找到”。第三类问题特别重要。如果模型开始编造手术史说明提示词没有约束住或者检索到的上下文误导了模型。7. 常见问题与排查思路本地知识库的坑大多集中在“模型下载、数据切分、向量检索、依赖冲突”这几类。下面整理成排查表问题现象可能原因排查方式解决方案Ollama 下载模型太慢网络原因或源不稳定先看ollama list确认是否真的没下载完成换网络环境、换时间段重试从同事处复制模型文件到本地LangFlow 启动后7860端口打不开端口被占用或者服务未启动成功查看启动日志netstat检查端口换端口启动python -m langflow run --port 7861输入问题后模型回答与资料完全无关才没执行索引流程切分参数不合理检索 K 太小确认向量库是否已有数据在检索节点查看命中的文本片段先跑索引流程调整 Split Text 参数增大 K 值中文回答质量差Embedding 模型对中文支持不足或者切分按英文标点切坏句子直接检查检索节点返回的中文片段是否完整中文场景测试 bge-m3 等中文本地模型按段落切分避免整句被切断老出现显存不足同时加载了对话模型和 Embedding 模型显存溢出查看 Ollama 进程列表确认模型加载情况换小参数模型一次只保留一个模型用 CPU 临时跑通流程PDF 加载后是乱码扫描版 PDF 没有文字层打开 PDF 检查是否能复制文字先做 OCR或者把关键档案转成 Markdown 文本LangFlow 节点提示缺少 Python 包部分向量库或文件加载器需要额外依赖看控制台报错信息缺少什么包名按提示执行pip install后重启 LangFlow更换文档后回答还是旧内容向量库中存有旧数据新文档没入库存好检索节点直接看一下召回内容清空或更换向量库目录重新执行索引这里想强调一个排查顺序问题出现时先确认检索结果对不对再怪模型。很多知识库效果不好问题不在大模型“能力弱”而是上下文根本没有检索到正确的资料。模型拿到错误的上下文就像让一个专家只看错误病历自然给不出正确答案。8. 从 Demo 到内部工具的工程建议8.1 文档治理知识库不是垃圾桶最大的误区是把所有文件一股脑丢进向量库。文档质量直接决定检索质量而检索质量决定回答质量。在上传前至少做三件事。第一去水印去页眉页脚避免每个文本块都混入无关文字。第二统一格式尽量转成无格式文本或结构清晰的 Markdown。第三拆分大文件一个几十页的 PDF 直接切块效果往往不如按章节拆分后的分册。健康档案类数据还要做脱敏。姓名、身份证号、详细住址属于敏感信息演示环境要用伪造数据生产环境需要先清洗再入库。否则即使模型跑在本地一旦流程被他人操作或日志外泄风险依然存在。8.2 切分方案要跟着内容结构走文本切分不是越短越好也不是越长越好。块太短语义不完整检索到的信息会缺失上下文块太长相似度命中时里面可能只有一小段相关内容其余都是噪音。推荐的切分策略是按“语义块”切。健康档案中的每个体检日期、每次就诊记录天然就是一个完整语义单元。你可以先按两次体检之间的分隔符切再用长度参数控制最大块大小。这种方案比纯按字符硬切要可靠得多。8.3 检索效果要有验证集不要用一两个问题测试完就说“可以了”。建议准备一个小的测试集包含二十条左右的问题每条问题对应正确的文档片段和期望答案。然后批量测试检索命中率。检索命中率是 RAG 应用最核心的指标。如果命中率低先调切分和 Embedding 模型不着急调大模型提示词。因为提示词只能让生成过程遵循给定资料不能让模型找到缺失的资料。8.4 安全与合规健康档案尤其要小心健康档案属于高度敏感数据。使用本地模型不等于绝对安全只是相比调用外部 API数据更少离开内部环境。但在生产环境中仍然要注意本地服务不应该无认证暴露给整个局域网Ollama 和 LangFlow 如果只需要本机访问尽量保持默认回环地址。档案文件在上传前做格式化和脱敏不要保留不必要的敏感字段。定期备份向量库和原始文档但要加密存储并设置访问权限。涉及真实患者数据时先确认有合法授权并且只处理与业务目标相关的字段。安全话题不是套话。在健康档案场景里一次用户隐私泄露可能意味着严重的合规问题。宁可功能少一点也不能跳过权限和审计。8.5 进一步生产化封装 API、加鉴权、留审计LangFlow 适合把流程跑通和验证效果但它本身不负责复杂权限管理和高并发。如果这个知识库要提供给同事或团队使用建议做三步升级把 RAG 流程封装成一个 API 服务可以用 Python 的 FastAPI也可以基于上面示例中的 LangChain 代码扩展。在 API 层加鉴权至少使用简单 Token更规范的做法是接入统一身份认证。记录查询日志和调用审计包括提问时间、用户、问题和返回结果。健康档案场景下审计为后续问题回溯提供依据。换一个通俗的说法LangFlow 是设计稿和原型生产服务是清晰地把它变成可以被别人安全使用的系统。9. 总结与后续学习方向这篇文章围绕“本地知识库 RAG 应用”做了一个完整的最小实践闭环。核心结论是LangFlow Ollama 是一条低门槛但有控制力的路线Ollama 解决模型供给LangFlow 解决流程可视化RAG 负责把私有资料变成模型可查询的知识。整个过程不需要写复杂代码但需要理解数据链路。如果你按文章顺序把环境装好、把健康档案样例跑通建议不要再急着换更大的模型。先做下面三件事第一把自己的真实业务文档清洗成统一格式思考哪些内容适合切成一个语义块。第二准备一个几十条问题的测试集反复看检索命中情况。第三把检索结果和生成结果分开观察遇到答非所问时先看检索片段。后面值得深入的方向包括多轮对话中如何结合历史会话优化检索、Agentic RAG 如何让模型自主决定要不要查库和调用工具、以及 LangFlow 与 Dify 在团队场景中的选型边界。RAG 和 MCP 的关系也会越来越紧密但现阶段先把基础链路做扎实更重要。把这篇收藏起来等到真正开始整理自己的文档时再对照着过一遍先洗数据再拖节点最后验证检索。别急着追求花哨功能知识库好不好用通常在你拖第一个组件之前就已经决定了。