最近很多朋友在问同一个问题企业内部的制度文档、个人健康档案这类私有资料能不能在不把数据交给外部大模型服务的前提下做成一个可以自然语言对话的问答知识库更关键的是如果不会写复杂的 LangChain 代码还有没有一条可行的落地路径。LangFlow Ollama 是我个人比较推荐的一个组合。LangFlow 提供可视化的拖拽式编排界面负责把 RAG 流程中的文档加载、文本切分、向量化、检索、大模型生成等环节串联起来Ollama 则在本地运行开源大模型和嵌入模型保证数据和推理过程都在自己的机器上完成。二者配合可以在不写一行核心业务代码的情况下快速搭建一个本地知识库 RAG 应用。本文会从一个健康档案私有知识库的场景出发完整讲解 RAG 的核心概念、LangFlow 和 Ollama 的环境搭建、0 代码可视化流程配置、问答验证以及常见问题排查。不管你是刚开始接触大模型应用开发的新手还是已经用过 LangChain 但想提高效率的开发者都可以按照这篇文章的思路搭建一套自己的本地知识库。1. 背景与核心概念1.1 什么是 RAGRAG 的全称是 Retrieval-Augmented Generation也就是“检索增强生成”。它的核心思路很简单大模型本身的知识来源于训练数据没法覆盖企业内部文档、个人健康档案这类私有内容。RAG 的做法是在模型回答问题之前先从知识库中检索出与问题最相关的内容片段把这些片段作为上下文拼接到 Prompt 中再让大模型基于这些内容生成答案。这样做的好处非常明显缓解大模型幻觉问题。模型不再凭空编造而是尽量依据检索到的文档片段回答。支持私有数据问答。企业制度、健康档案、产品手册等资料不需要参与模型训练也能被模型“读取”。降低更新成本。文档变更后只需要刷新对应的向量索引不需要重新训练模型。数据私密性好。检索和生成都在本地完成时敏感信息不会离开自己的服务器。RAG 和微调是两条不同的技术路线。微调需要准备标注数据集、训练模型成本高且周期长RAG 则不需要改变模型权重更适合知识库频繁更新的场景。1.2 为什么选择 LangFlowLangFlow 是一个基于 LangChain 生态的可视化流程编排工具。它把 RAG 链路中常见的组件比如文档加载器、文本切分器、向量数据库、Prompt 模板、大模型节点等封装成一个个可以拖拽的图形节点。开发者只需要把节点拖到画布上用连线把节点之间的数据流串起来就能构建出一个可运行的 LLM 应用。对于不想写大量代码的人来说LangFlow 的最大价值在于“所见即所得”。你可以直接看到每一条数据处理链路调试某一个节点的输入输出也可以随时调整 Prompt 模板或者切换模型。它本质上降低了 RAG 应用的门槛让产品、测试、运维等角色也能参与搭建。1.3 为什么选择 OllamaOllama 是一个本地大模型运行工具支持在命令行下一键下载和运行多种开源模型比如 Qwen、Llama、Mistral、Phi 等。它把模型下载、环境依赖、推理服务封装成了简单的命令启动后会自动提供一套兼容 OpenAI 风格的 HTTP API方便 LangFlow 等上层应用调用。选择 Ollama 的理由可以总结为三点部署简单。一条命令就能拉取模型一条命令就能启动本地推理服务。资源可控。可以选择不同参数量、不同量化等级的模型适配从个人电脑到服务器。数据不出本地。所有推理都在本地完成适合健康档案、企业内部文档等敏感数据场景。1.4 LangFlow Ollama 的整体架构从整体上看这套本地知识库方案的运行方式可以理解为四个步骤文档进入流程通过 LangFlow 的文档加载节点读取本地文件。文本向量化将文档切分成片段交给 Ollama 提供的嵌入模型生成向量并写入向量数据库。检索用户输入问题后先把问题向量化再从向量库中找出语义最相似的片段。生成回答检索到的片段和用户问题一起送入 Prompt 模板最终由 Ollama 本地大模型生成答案。整个数据流完全在本地完成。LangFlow 负责流程编排Ollama 负责模型推理向量数据库负责相似度检索。这就是一套典型的最小化本地 RAG 架构。2. 环境准备与版本说明2.1 硬件与操作系统的基本要求运行本地大模型需要一定的硬件资源。一般来说8GB 内存可以运行 1.5B、3B 等小参数量模型16GB 内存可以较流畅地运行 7B 级别的量化模型。如果条件允许独立显卡会让推理速度明显提升。没有 GPU 时CPU 模式也能跑只是速度会慢一些适合个人体验和功能验证。操作系统方面Ollama 和 LangFlow 都支持 Windows、macOS 和主流 Linux 发行版。本文的示例环境以常见个人电脑为例Windows 和 macOS 用户同样适用。需要说明的是相关软件版本更新比较快后面的安装步骤以官方最新版本为准重点讲解配置思路。2.2 安装 Ollama 并下载模型Ollama 的安装非常简单建议从官方网站下载对应系统版本的安装包。安装完成后打开终端执行下面的命令验证ollama --version如果能看到版本号说明 Ollama 安装成功。接下来需要下载一个对话模型用于回答生成。以通义千问 Qwen2.5 系列为例可以先从一个小型模型开始ollama pull qwen2.5:3b执行完这条命令后Ollama 会自动从模型仓库下载模型文件。下载完成后可以用下面的命令快速测试ollama run qwen2.5:3b 你好请介绍一下你自己如果模型正常运行并输出文字说明本机的大模型推理链路已经打通。2.3 安装 LangFlow 并启动服务LangFlow 的安装方式以 Python 为主。这里建议先准备一个独立的 Python 环境避免依赖冲突。确保 Python 版本满足 LangFlow 的要求后使用 pip 安装pip install langflow安装完成后在终端执行下面的命令启动服务python -m langflow run启动成功后浏览器访问http://localhost:7860即可进入 LangFlow 的可视化界面。第一次进入可能需要创建一个管理员账号这个账号用于保护本地流程和配置数据。如果你的网络环境安装缓慢也可以考虑使用 Docker 方式运行 LangFlow。不同部署方式各有适用场景pip 方式适合本机快速体验Docker 方式更适合服务器环境以及后续的版本迁移。2.4 验证 Ollama 服务是否正常LangFlow 要调用 Ollama必须保证 Ollama 服务处于运行状态。通常情况下只要执行过ollama run或者后台运行了ollama serveOllama 服务就会监听本机端口。可以通过下面的命令检查curl http://localhost:11434/api/tags如果返回一段包含模型列表的 JSON 数据说明 Ollama 服务正常。LangFlow 里的 Ollama 节点默认也会连接这个地址所以这一步的验证很关键。3. RAG 的核心流程与节点拆解3.1 RAG 全流程拆解虽然 LangFlow 是图形化操作不用写代码但理解 RAG 的运行流程依然很重要。一个完整的 RAG 流程通常包括六个环节文档加载文本切分Embedding 向量化向量存储相似度检索Prompt 生成文档加载解决的是“数据从哪来”的问题。文本切分解决的是“怎么把长文档拆成适合检索的片段”。Embedding 负责把自然语言转换成向量语义相近的文本在向量空间中也更接近。向量数据库负责存储这些向量并提供快速的相似度检索。检索结果会拼接到 Prompt 中最后由大模型生成回答。在 LangFlow 中这些环节都被封装成节点。你不需要自己实现切分算法也不需要手写向量化代码只需要选对节点、配置好参数、正确连线即可。3.2 LangFlow 中的关键节点LangFlow 的节点面板里有非常多组件搭建本地知识库时最常用的是下面几类文档加载节点负责读取本地文件常见的是 File Loader 类型。文本切分节点负责把长文档拆分成固定大小的 chunk常见名称是 Splitter。向量存储节点负责把切分好的文本向量化并存储常见有 Chroma 向量数据库节点。嵌入模型节点负责生成文本向量可以连接 Ollama 的嵌入模型。大模型节点负责生成最终回答LangFlow 中通常叫 Ollama Model。Prompt 模板节点负责拼接系统提示词、检索上下文和用户问题。Chat Input 与 Chat Output负责接收用户输入和展示模型输出。这些节点之间的连线代表了数据流。比如文档加载节点输出的是原始文档对象它不能直接进入大模型必须先经过切分、向量化、入库。在搭建流程时务必保持节点前后数据类型一致。3.3 嵌入模型与向量库的选择嵌入模型是 RAG 链路中容易被忽视的一环。嵌入模型的质量直接决定检索结果是否准确。Ollama 提供了专门的嵌入模型比如nomic-embed-text可以用下面的命令下载ollama pull nomic-embed-text和对话大模型不同嵌入模型不负责生成回答它只负责把文本转换成向量。LangFlow 中的 Ollama Embeddings 节点会调用这个模型完成向量化工作。向量数据库方面LangFlow 内置支持 Chroma 等常见向量库。Chroma 是轻量级方案对于个人知识库和团队内部小规模知识库来说完全够用。它可以把向量数据和原始文本持久化到本地目录方便后续重启复用。正式的团队生产环境则可以评估 Qdrant、Milvus、pgvector 等更重型的方案但它们的接入思路基本一致。4. 0 代码搭建健康档案私有知识库4.1 准备知识库文档为了让流程更具体这里把场景设定为构建一份“健康档案管理知识库”。假设你手上有一份高血压健康管理知识文档里面记录了诊断标准、饮食建议、用药注意事项等信息。下面是一段用于演示的 Markdown 文档内容你可以把类似内容保存到本地文件中。# 高血压健康管理知识库 ## 1. 高血压诊断标准 在未使用降压药物的情况下非同日 3 次测量诊室血压收缩压大于等于 140mmHg 和/或舒张压大于等于 90mmHg可诊断为高血压。 ## 2. 生活方式干预建议 每日食盐摄入量建议控制在 5 克以下。减少高脂肪、高糖食物摄入适量增加蔬菜、水果、全谷物的比例。每周进行至少 150 分钟中等强度有氧运动。 ## 3. 常见降压药物注意事项 常见降压药包括钙通道阻滞剂、ACEI 类、ARB 类、利尿剂等。具体用药需要结合患者情况不可自行停药或换药。出现明显不适时应及时就医。 ## 4. 日常监测建议 建议每天早晚各测量一次血压并记录数值。测量前应安静休息 5 分钟避免饮茶、咖啡等刺激性饮品。 ## 5. 紧急情况处理 如果出现剧烈头痛、视力模糊、胸痛、呼吸困难等症状应考虑高血压急症可能需要立即就医。需要说明的是上面的内容只是用于演示 RAG 流程的示例文本不是权威医学建议。实际项目中知识库应该来自经过审核、有明确版权的内部资料。4.2 下载模型与嵌入模型在搭建 LangFlow 流程之前先把需要用到的模型准备齐全。打开终端依次执行下面的命令ollama pull qwen2.5:3b ollama pull nomic-embed-text第一条命令下载用于回答问题的对话模型第二条命令下载用于生成向量的嵌入模型。模型下载完成后LangFlow 的节点配置会自动发现这些本地模型。如果你的机器内存较小也可以选择参数量更小的模型比如qwen2.5:1.5b。模型越小生成速度越快但回答质量也会有所下降。具体选择需要根据自己的硬件情况权衡。4.3 在 LangFlow 中拖拽搭建流程打开浏览器进入 LangFlow 界面后新建一个空白项目。你会看到左侧组件面板和中间画布区。下面我们按照 RAG 的处理顺序把组件逐个拖入画布。第一个是要连接的数据链路。把文档加载节点拖入画布然后拖入一个文本切分节点再拖入一个向量存储节点。同时把 Ollama Embeddings 节点拖到画布中让它作为向量存储的嵌入模型。第二个是问答生成链路。把 Chat Input、Prompt Template、Ollama Model、Chat Output 这四个节点拖入画布并按顺序连线。两条链路在 Prompt Template 汇合向量存储的检索结果作为上下文传入 Prompt Template用户问题也传入 Prompt Template最终由大模型节点生成答案。拖拽连线的规则不算复杂但不同版本 LangFlow 的组件名称和端口位置会有些差异。核心原则是让文档从“加载 - 切分 - 向量化 - 入库 - 检索 - 生成”的链路保持完整。4.4 关键节点配置说明配置节点时需要关注几个核心参数。首先是文档加载节点你要把本地健康档案文件路径配置进去。LangFlow 的文档加载节点通常会要求输入文件路径或文件对象。然后是文本切分节点。这里需要设置 chunk size 和 chunk overlap。chunk size 表示每段文本的长度chunk overlap 表示相邻片段之间的重叠长度。本文示例设置的 chunk size 为 300chunk overlap 为 50适合知识库类文档。切分太小会导致上下文不完整切分太大又会降低检索精度需要后续根据问答效果调整。向量存储节点需要设置一个 collection 名称比如health_knowledge。这个名字相当于向量库中一个集合的标识。Ollama Embeddings 节点需要设置模型名称这里填入nomic-embed-text并确认 Ollama 服务地址是http://localhost:11434。Ollama Model 节点用来配置回答生成模型。模型名称填入qwen2.5:3b服务地址同样是 Ollama 的默认地址。如果 LangFlow 提示需要 API Key填一个任意非空字符串即可因为 Ollama 本地服务默认不校验密钥。Prompt Template 是决定回答质量的关键节点可以配置成下面这样你是一个健康档案知识库助手。请严格根据下面提供的知识库内容回答用户问题。如果知识库中没有相关信息请明确回答“知识库中暂无相关信息”不要编造。 知识库内容 {context} 用户问题 {question}花括号变量会在流程运行时被自动替换。{context}是检索到的文档片段{question}是用户输入的问题。4.5 运行问答验证节点配置完成后点击 LangFlow 右上角的运行按钮再打开 Playground 调试面板。试着输入“高血压患者应该如何调整饮食”。如果一切正常模型会结合之前加载的健康档案文档内容给出类似“每日食盐摄入量建议控制在 5 克以下减少高脂肪食物摄入适量增加蔬菜水果比例”的回答。这个回答不是模型自己凭感觉生成的而是从知识库文档中检索到相关内容后生成的。接着可以继续提问“常见降压药有哪些注意事项”观察回答是否来自知识库内容。如果需要测试多轮对话可以在流程中加入会话记忆组件不过在最小化 RAG 流程中先保证单轮问答链路跑通再考虑多轮上下文。5. 常见问题与排查思路5.1 LangFlow 页面打不开或启动很慢LangFlow 第一次启动时需要加载大量前端资源可能需要等待一段时间。如果浏览器访问http://localhost:7860一直转圈可以先确认终端是否有报错信息。一种常见情况是端口被占用。可以尝试换一个端口启动python -m langflow run --port 7861另外pip 安装 LangFlow 时如果缺少系统依赖也可能导致前端服务异常。建议使用干净的 Python 虚拟环境并按官方文档检查 Python 版本兼容性。5.2 Ollama 模型下载慢或失败模型文件通常比较大下载速度受网络环境影响明显。如果下载很慢可以考虑几种方案选择更小的量化模型例如把 7B 模型换成 3B 或 1.5B。使用 Ollama 的离线导入方式先从国内模型仓库下载 GGUF 格式的模型文件再通过 Modelfile 导入 Ollama。确认模型名称是否正确避免重复下载失败。离线导入的基本思路是编写一个 Modelfile 文件然后执行ollama create命令。不同模型的 GGUF 获取方式不同建议优先参考 Ollama 官方文档中的离线安装说明。5.3 节点连接 Ollama 报错在 LangFlow 中运行流程时如果 Ollama 相关节点报错“Connection error”或“Ollama server not found”首先检查 Ollama 服务是否还在运行其次检查节点里的 base URL 是否为http://localhost:11434。可以先用浏览器访问http://localhost:11434/api/tags如果无法打开说明 Ollama 服务没有启动。另外如果 Ollama 设置了其他监听端口LangFlow 节点中的地址也要同步修改。5.4 检索结果不相关或输出幻觉检索结果不好最常见的两个原因是文本切分策略不合适和嵌入模型不匹配。文本切分过大会导致每个片段包含太多无关信息检索出来的内容不够精准切分过小又可能截断语义。可以先调节 chunk size 和 chunk overlap观察检索召回效果。嵌入模型也很重要。如果发现很多问题检索不到相关内容可以尝试更换其他嵌入模型并重新执行一次向量化入库流程。不要忘记修改嵌入模型后之前生成的向量也需要重新生成否则向量库中仍是旧模型生成的向量。5.5 常见问题速查表问题现象常见原因解决思路LangFlow 页面无法访问服务未启动或端口被占用检查终端日志使用 --port 更换端口Ollama 模型下载失败网络不稳定或模型名错误使用较小模型或离线导入 GGUF 文件Ollama 节点连接失败服务未运行或地址配置错误确认服务状态核对 localhost:11434回答与知识库内容无关嵌入模型或切分参数不合适调整切分参数重新生成向量索引中文乱码文件编码不是 UTF-8将文档转换为 UTF-8 编码后再加载知识库更新后回答问题仍旧向量库仍使用旧索引重新执行切分和向量化入库流程6. 最佳实践与工程建议6.1 文档切分与预处理RAG 的回答质量很大程度上取决于文档预处理。健康档案这类文档结构清晰建议尽量使用按标题切分的策略保留原文结构避免强行按固定长度切断导致上下文丢失。对于 Markdown 文档可以优先考虑根据标题层级做切分再结合固定的 chunk size 做二次拆分。切分后的片段最好包含文档来源、章节信息等元数据这样在回答时可以知道答案来自哪份文档也方便后续审计。6.2 模型与硬件匹配策略大模型的选择不能一味追求参数规模。个人电脑上运行 7B 模型即使能跑起来速度也可能让人难以接受。建议优先考虑 3B 以内的小模型先保证流程通顺再根据效果决定是否升级硬件或换更大的模型。嵌入模型的选择同样重要。不同的嵌入模型适合不同的语言场景中文知识库和英文知识库可能需要不同的选择。实际应用中可以用一组测试问题对比检索召回效果而不是只看模型名气。6.3 数据隐私与访问安全健康档案属于高度敏感的个人数据。使用本地部署方案时要注意几个安全边界不要把健康档案数据上传到任何外部 API 服务本地部署的意义就在于数据不出内网。Ollama 默认监听本机地址如果没有特殊需求不要随意修改监听地址为0.0.0.0。如果确实需要局域网内多台机器访问建议在 Ollama 或 LangFlow 前面增加网关认证并在防火墙层面限制访问来源。定期备份知识库文档和向量库索引防止数据丢失。另外即便使用本地模型也要注意 Prompt 中可能包含敏感内容。不要把 API Key 等凭据写进 Prompt 模板和环境变量之外的地方防止配置导出后泄露。6.4 知识库更新与维护知识库不是建设完就结束了。文档内容更新后需要在 LangFlow 中重新执行一次入库流程。最稳妥的方式是先清空旧的向量集合再重新加载、切分、向量化避免新旧数据混合影响检索结果。建议给知识库文档做好版本管理每周或每月定期检查内容时效性。对于健康知识这种时效性强、影响面大的内容更要确保文档来源可靠、审核流程完善。6.5 企业级落地的扩展方向如果这套方案要扩展为团队级别可以考虑使用 Docker 部署 LangFlow 和 Ollama统一管理版本。引入外部的向量数据库用高可用架构替代本地的 Chroma。在 LangFlow 与用户之间增加一层问答接口服务统一身份认证、限流和日志记录。对文档做层级分权不同角色只能检索到授权范围内的知识库。把流程导出为 API 形式方便集成到企业微信群、钉钉或内部 Web 应用中。需要提醒的是生产化改造会比本地演示多出很多工程细节但核心的 RAG 链路依然可以用 LangFlow 这样的可视化工具来承载开发和维护成本都能控制在合理范围内。7. 总结与学习建议这篇文章从 RAG 概念讲起完整演示了 LangFlow Ollama 搭建本地健康档案私有知识库的全流程。通过文档加载、文本切分、向量检索、大模型生成这条链路可以在不写业务代码的情况下获得一个能回答私有文档问题的问答系统。沿着这条路线继续深入可以重点关注三个方向一是提示工程通过设计更精细的 Prompt 提升回答质量二是多轮对话设计在 LangFlow 中引入会话记忆组件让知识库助手具备连续对话能力三是了解 RAG 与 MCP、Agent 的区别RAG 解决的是模型如何获取私有知识的问题MCP 解决的是模型如何统一调用外部工具的问题而 Agent 则更强调模型自主规划任务和执行动作。知识库应用的价值不在于技术栈多复杂而在于是否能稳定、可控地帮助用户从文档中找到答案。如果你正准备给团队或自己搭一套私有知识库建议先挑一个小型文档集把这条链路完整跑通再逐步扩大知识范围和模型规模。动手搭一遍远比看教程记得牢。