1. 先算一笔账云会员的钱到底花在哪了很多人买 AI PC 的决策链条是这样的看到厂商宣传端侧大模型本地 AI 助手觉得新鲜下单用两周后发现真正干活的时候还是打开网页版对话工具每月续着会员。本地那个 AI 助手除了演示时亮过一次再没碰过。问题不在硬件在于本地知识库没搭起来。端侧大模型本身只是个会说话的脑子它不知道你的合同模板长什么样、不知道你项目的技术文档放在哪个目录、不知道你攒了三年的行业报告里写了什么。你每次问它它都只能给通用回答你自然觉得还不如云端的。云会员贵不贵按月付的对话工具会员一年下来少说几百块按量计费的 API 调用如果你把整份文档反复喂进去问问题token 消耗速度会超出预期。更关键的是你的文档一旦上传到云端就脱离了你的物理控制。合同、代码、内部资料这些东西适不适合往外传每个人心里有杆秤。本地知识库要解决的就是这件事让端侧模型能看到你自己的资料回答基于你的文档全程不出本机。华为和小米这两年的 AI PC 产品线硬件底子NPU、内存、存储已经够跑 7B 到 14B 级别的量化模型缺的只是软件层那套检索 生成的管线。这篇文章不讲虚的就讲三件事为什么本地知识库值得搭、用什么工具链搭、怎么在华为和小米的机器上把它跑顺。三步走完你大概率可以把那笔云会员的钱省下来。适合谁看手上有 AI PC 或者准备买、愿意花一个下午折腾、对命令行不排斥但也不是专业运维的人。零基础也能跟我会把每一步的意图讲清楚而不是甩一堆命令让你复制。提示本文所有操作都在本机完成不涉及任何外部网络服务的配置。模型文件、文档、向量数据全部存放在本地磁盘。2. 端侧模型 本地检索这套组合到底在干什么2.1 大模型为什么不知道你的文档先把原理说透后面操作才不会懵。大模型的知识来自训练数据训练数据有截止时间而且不包含你私人的文件。你问它我们公司报销流程是什么它只能编一个看起来合理的答案因为它压根没见过你们公司的制度文档。这就是所谓的幻觉——不是模型坏是它真的不知道。那为什么云端工具有时候能答对因为你在对话里把文档内容贴进去了或者平台做了检索增强。贴进去这种方式文档短还行几十页的 PDF 你贴不动而且每次问都要重贴token 哗哗地烧。检索增强生成RAG的思路是不把文档塞进模型而是先把文档切碎、转成向量、存进本地数据库你提问时系统先去数据库里捞出最相关的几段再把这几段和你的问题一起交给模型让它看着材料回答。模型还是那个模型但它手里有了参考资料。打个比方模型是个博学但没来过你家的朋友RAG 就是你在它进门之前先把家里的说明书摊在桌上。它不用背下整本书只要会翻到对的那一页就行。2.2 为什么是 Ollama LangChain Chroma 这套组合工具链的选择很多我选这套是因为它对个人用户最友好且三个组件职责清晰、互不绑架。Ollama负责跑模型。它的价值在于把模型下载、量化格式、推理引擎、API 服务这些脏活全包了。你不需要懂 GGUF 和 llama.cpp 的区别一条ollama pull就能把模型拉下来跑起来还自带一个兼容常见接口规范的本地服务端口。对华为和小米的 AI PC 来说Ollama 能吃到 NPU 加速最好吃不到也能靠 CPU 内存跑量化模型7B 级别在 16GB 内存的机器上是可以接受的。LangChain负责编排流程。文档加载、切分、向量化、检索、拼 prompt、调模型这一串动作如果手写代码量不小而且容易乱。LangChain 把这些抽象成组件你按需拼装。它的缺点是抽象层多、版本变动快但对个人项目来说省下的时间远大于踩坑成本。Chroma负责存向量。它是个轻量级向量数据库可以纯本地文件模式运行不需要单独起服务数据就存在你指定的目录里。文档几千份以内Chroma 完全够用检索延迟在毫秒级。三者关系用一句话概括Ollama 出脑子Chroma 出记忆LangChain 当调度员。2.3 华为和小米的 AI PC 在这套链路里扮演什么角色华为的 AI PC 产品线比如 MateBook 系列里带 NPU 的型号和小米的笔记本产品硬件层面都能满足这套链路的最低要求。关键看三个指标硬件指标最低要求舒适区间说明内存16GB32GB 及以上模型加载占大头7B 量化约 4-6GB存储20GB 可用100GB 以上模型文件 向量库 文档算力支持 AVX2 的 CPU带 NPU 或独显决定生成速度不影响能否跑华为机器上部分型号的 NPU 需要厂商提供的推理框架才能调用Ollama 默认走 CPU 或 GPU。实测下来CPU 跑 7B 量化模型生成速度大概每秒几个字到十几个字问答场景够用长文生成会慢。小米的笔记本如果带独显Ollama 能自动识别并加速速度会明显好一截。这里有个容易被忽略的点内存比算力更影响体验。内存不够模型加载失败或者频繁换页再强的 NPU 也救不回来。买机器时如果预算有限优先堆内存。3. 三步落地从装工具到能问答3.1 第一步把 Ollama 跑起来并选对模型先装 Ollama。官网下载对应系统的安装包Windows 和 macOS 都有图形化安装程序Linux 用脚本。装完之后终端里敲ollama --version能打印版本号就说明装好了。Ollama 安装后会自动在后台起一个本地服务默认监听本机的 11434 端口这个端口只对本机开放不对外。接下来选模型。这一步很多人会踩坑——盲目追大参数。14B、32B 听起来厉害但在 16GB 内存的机器上跑起来会非常吃力甚至加载失败。我的建议是16GB 内存选 7B 级别的量化模型比如qwen2.5:7b或同量级的中文友好模型32GB 内存可以上 14B 量化回答质量明显提升有独显且显存 8GB 以上可以尝试更大的模型Ollama 会自动分配拉模型的命令很简单ollama pull qwen2.5:7b拉完之后测试一下ollama run qwen2.5:7b进入交互界面随便问一句能正常回答就说明模型跑通了。输入/bye退出。注意模型文件动辄几个 GB第一次拉取需要耐心。拉下来的模型存在用户目录下的.ollama文件夹里换机器时可以直接拷贝这个目录省去重新下载。这一步的意图是先确认模型能独立工作。如果模型本身跑不起来后面接检索也是白搭。很多人跳过这步直接上 LangChain结果报错时不知道是模型的问题还是代码的问题排查起来很痛苦。3.2 第二步用 LangChain 把文档喂进 Chroma这一步是整个链路的核心。先装 Python 依赖pip install langchain langchain-community langchain-ollama chromadb版本迭代比较快如果某个包报导入错误优先检查版本兼容性必要时锁定版本。然后写一个最小的入库脚本。逻辑分四段加载文档、切分、向量化、存入 Chroma。from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_ollama import OllamaEmbeddings from langchain_chroma import Chroma # 1. 加载文档这里以 txt 为例PDF 需要换对应的 loader loader DirectoryLoader(./my_docs, glob**/*.txt, loader_clsTextLoader) docs loader.load() # 2. 切分。chunk_size 和 overlap 是关键参数 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_documents(docs) # 3. 向量化用 Ollama 提供的 embedding 模型 embeddings OllamaEmbeddings(modelnomic-embed-text) # 4. 存入 Chroma持久化到本地目录 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db ) print(f入库完成共 {len(chunks)} 个片段)这里有几个参数值得展开说因为它们直接决定检索质量。chunk_size是每个文本片段的长度。太小一段话被切碎语义不完整太大检索出来的片段包含太多无关信息干扰模型。500 字符左右是个经验值中文文档可以适当调小到 300-400。chunk_overlap是相邻片段的重叠长度。为什么要重叠因为切分点可能正好落在一个关键句中间重叠能保证这句话至少在一个片段里是完整的。一般取 chunk_size 的 10% 到 20%。separators是切分优先级。LangChain 会按列表顺序尝试先按空行切切不动再按换行再不行按句号。中文文档一定要把中文标点加进去否则会按字符硬切语义破坏严重。embedding 模型的选择也重要。nomic-embed-text是个轻量且效果不错的选项需要先用ollama pull nomic-embed-text拉下来。注意 embedding 模型和生成模型是两回事各拉各的。提示入库脚本只需要跑一次之后文档没变就不用重跑。如果文档更新了删掉chroma_db目录重新跑一遍即可不要试图增量更新容易出脏数据。3.3 第三步串起检索和生成做成能问答的脚本入库完成后写问答脚本from langchain_ollama import OllamaLLM from langchain_chroma import Chroma from langchain_ollama import OllamaEmbeddings from langchain.chains import RetrievalQA embeddings OllamaEmbeddings(modelnomic-embed-text) vectorstore Chroma( persist_directory./chroma_db, embedding_functionembeddings ) llm OllamaLLM(modelqwen2.5:7b) qa RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrievervectorstore.as_retriever(search_kwargs{k: 4}), return_source_documentsTrue ) while True: question input(\n你的问题) if question.strip() in (exit, quit): break result qa.invoke({query: question}) print(\n回答, result[result]) print(\n参考来源) for doc in result[source_documents]: print(-, doc.metadata.get(source, 未知))k4表示每次检索返回 4 个最相关的片段。这个值可以调k 太小可能漏掉关键信息k 太大则 prompt 变长、生成变慢。4 到 6 是比较平衡的区间。chain_typestuff是最简单的策略把所有检索到的片段直接塞进 prompt。文档片段多的时候可能超出模型上下文窗口这时候可以换成map_reduce或refine但速度会慢。个人使用场景stuff 通常够。return_source_documentsTrue让脚本返回参考来源。这个功能非常实用——当模型给出一个答案你能看到它是从哪几个片段推出来的方便验证真伪。没有来源追溯的 RAG本质上和裸模型没区别。跑通这个脚本你就有了一个完全本地的问答系统。问它你文档里的内容它会基于检索到的片段回答并告诉你出处。4. 实测中真正会卡住你的几个地方4.1 中文文档切分标点符号没配对语义全碎这是最常见的坑。默认的RecursiveCharacterTextSplitter分隔符是英文标点中文文档如果不改会按空格和英文字符切结果就是一句话被拦腰截断检索出来的片段读都读不通。解决办法就是上面代码里那样把中文标点加进 separators 列表并且放在英文标点前面。另外中文没有空格分词chunk_size 按字符算500 字符大概对应 250 到 300 个汉字这个量级比较合适。还有一个细节PDF 转文本后经常出现奇怪的换行和空格入库前最好做一次清洗把连续空行合并、去掉页眉页脚。清洗脚本不复杂但能显著提升检索质量。4.2 检索答非所问embedding 模型和生成模型不匹配有人换了生成模型但 embedding 模型没换或者反过来。这会导致向量空间不一致检索出来的片段和问题根本不相关。记住一个原则embedding 模型一旦选定入库和查询必须用同一个。如果你中途换了 embedding 模型之前入库的向量全部作废必须重新入库。这也是为什么建议把 embedding 模型名称写死在配置里别随手改。另一个原因是文档本身质量差。如果原始文档就是扫描件 OCR 出来的错字连篇embedding 出来的向量也是乱的。这种情况先修文档别怪工具。4.3 华为机器上的 NPU 调用别期待开箱即用华为部分型号的 NPU 需要专门的推理框架和驱动支持Ollama 默认不会自动调用。你在任务管理器里看到 CPU 跑满、NPU 闲着是正常现象。想让 NPU 参与推理需要关注厂商是否提供了对应的推理后端以及 Ollama 是否支持该后端。截至我写这篇的时候这条路对个人用户还不算顺畅。实际体验是CPU 跑 7B 量化问答场景完全可用不必为了 NPU 折腾到怀疑人生。等生态成熟了再说。小米的笔记本如果带独立显卡情况会好很多。Ollama 能识别 CUDA 或对应的加速框架自动把模型加载到显存生成速度提升明显。买机器时如果明确要跑本地模型独显比 NPU 更实在。4.4 内存不够时的降级策略16GB 内存跑 7B 模型同时开着浏览器和办公软件可能会卡。几个降级手段换更小的量化版本比如 4-bit 量化模型体积减半质量损失可接受问答时关掉不必要的大内存程序把 chunk_size 调小减少单次 prompt 长度用num_ctx参数限制上下文窗口Ollama 支持在调用时指定这些手段的本质都是在内存、速度、质量之间找平衡。没有银弹按自己的机器情况调。5. 省下的不只是会员费5.1 数据不出本机这件事值多少钱云会员一年几百块这是明面上的账。但真正的价值在于你的合同、代码、内部文档全程没有离开过你的硬盘。向量库存在本地目录模型文件存在本地目录问答过程在本地内存里完成。断网也能用。对于处理敏感资料的人来说这个属性本身就是刚需。不是说不信任云端而是有些东西压根不该有上传这个选项。5.2 从能用到好用几个提升体验的调整跑通之后可以做几件事让它更好用。建多个知识库。工作文档一个库个人笔记一个库用不同的 persist_directory 分开存。查询时按需切换避免不同领域的文档互相干扰检索。加一个简单的 Web 界面。LangChain 生态里有现成的对话界面组件几十行代码就能起一个本地网页比命令行舒服。界面只监听本机不对外暴露。定期更新文档库。文档变了就重新入库别偷懒。过期的知识库比没有知识库更危险因为它会用旧信息误导你。记录好用的 prompt 模板。RAG 的回答质量很大程度取决于你怎么组织 prompt。比如加上如果参考资料中没有相关信息请明确说明不知道不要编造这类约束能显著减少幻觉。5.3 这套方案不适合什么场景说句实在话本地知识库不是万能的。如果你需要的是超大规模文档的秒级检索几万份以上Chroma 会吃力得换更专业的向量数据库。如果你需要的是最强的推理能力本地 7B 模型和云端大模型差距明显复杂推理任务还是云端强。如果你完全不想碰命令行这套方案的学习成本对你来说可能偏高可以考虑厂商自带的 AI 助手虽然灵活性差但开箱即用。我的建议是本地知识库处理日常问答和资料检索复杂任务再考虑云端。两者不是替代关系是分工关系。省下的会员费是省在那些本来就不需要云端算力的场景上。搭这套东西花了我一个下午其中一半时间在踩切分参数的坑。跑顺之后查自己攒的资料再也不用翻文件夹问一句就有答案还带出处。华为和小米的 AI PC 硬件底子够用真正决定体验的是软件层这套管线搭得对不对。模型选小一点、切分参数调细一点、embedding 模型别乱换这三点做到基本就稳了。
AI PC本地知识库搭建：Ollama+LangChain+Chroma实战
1. 先算一笔账云会员的钱到底花在哪了很多人买 AI PC 的决策链条是这样的看到厂商宣传端侧大模型本地 AI 助手觉得新鲜下单用两周后发现真正干活的时候还是打开网页版对话工具每月续着会员。本地那个 AI 助手除了演示时亮过一次再没碰过。问题不在硬件在于本地知识库没搭起来。端侧大模型本身只是个会说话的脑子它不知道你的合同模板长什么样、不知道你项目的技术文档放在哪个目录、不知道你攒了三年的行业报告里写了什么。你每次问它它都只能给通用回答你自然觉得还不如云端的。云会员贵不贵按月付的对话工具会员一年下来少说几百块按量计费的 API 调用如果你把整份文档反复喂进去问问题token 消耗速度会超出预期。更关键的是你的文档一旦上传到云端就脱离了你的物理控制。合同、代码、内部资料这些东西适不适合往外传每个人心里有杆秤。本地知识库要解决的就是这件事让端侧模型能看到你自己的资料回答基于你的文档全程不出本机。华为和小米这两年的 AI PC 产品线硬件底子NPU、内存、存储已经够跑 7B 到 14B 级别的量化模型缺的只是软件层那套检索 生成的管线。这篇文章不讲虚的就讲三件事为什么本地知识库值得搭、用什么工具链搭、怎么在华为和小米的机器上把它跑顺。三步走完你大概率可以把那笔云会员的钱省下来。适合谁看手上有 AI PC 或者准备买、愿意花一个下午折腾、对命令行不排斥但也不是专业运维的人。零基础也能跟我会把每一步的意图讲清楚而不是甩一堆命令让你复制。提示本文所有操作都在本机完成不涉及任何外部网络服务的配置。模型文件、文档、向量数据全部存放在本地磁盘。2. 端侧模型 本地检索这套组合到底在干什么2.1 大模型为什么不知道你的文档先把原理说透后面操作才不会懵。大模型的知识来自训练数据训练数据有截止时间而且不包含你私人的文件。你问它我们公司报销流程是什么它只能编一个看起来合理的答案因为它压根没见过你们公司的制度文档。这就是所谓的幻觉——不是模型坏是它真的不知道。那为什么云端工具有时候能答对因为你在对话里把文档内容贴进去了或者平台做了检索增强。贴进去这种方式文档短还行几十页的 PDF 你贴不动而且每次问都要重贴token 哗哗地烧。检索增强生成RAG的思路是不把文档塞进模型而是先把文档切碎、转成向量、存进本地数据库你提问时系统先去数据库里捞出最相关的几段再把这几段和你的问题一起交给模型让它看着材料回答。模型还是那个模型但它手里有了参考资料。打个比方模型是个博学但没来过你家的朋友RAG 就是你在它进门之前先把家里的说明书摊在桌上。它不用背下整本书只要会翻到对的那一页就行。2.2 为什么是 Ollama LangChain Chroma 这套组合工具链的选择很多我选这套是因为它对个人用户最友好且三个组件职责清晰、互不绑架。Ollama负责跑模型。它的价值在于把模型下载、量化格式、推理引擎、API 服务这些脏活全包了。你不需要懂 GGUF 和 llama.cpp 的区别一条ollama pull就能把模型拉下来跑起来还自带一个兼容常见接口规范的本地服务端口。对华为和小米的 AI PC 来说Ollama 能吃到 NPU 加速最好吃不到也能靠 CPU 内存跑量化模型7B 级别在 16GB 内存的机器上是可以接受的。LangChain负责编排流程。文档加载、切分、向量化、检索、拼 prompt、调模型这一串动作如果手写代码量不小而且容易乱。LangChain 把这些抽象成组件你按需拼装。它的缺点是抽象层多、版本变动快但对个人项目来说省下的时间远大于踩坑成本。Chroma负责存向量。它是个轻量级向量数据库可以纯本地文件模式运行不需要单独起服务数据就存在你指定的目录里。文档几千份以内Chroma 完全够用检索延迟在毫秒级。三者关系用一句话概括Ollama 出脑子Chroma 出记忆LangChain 当调度员。2.3 华为和小米的 AI PC 在这套链路里扮演什么角色华为的 AI PC 产品线比如 MateBook 系列里带 NPU 的型号和小米的笔记本产品硬件层面都能满足这套链路的最低要求。关键看三个指标硬件指标最低要求舒适区间说明内存16GB32GB 及以上模型加载占大头7B 量化约 4-6GB存储20GB 可用100GB 以上模型文件 向量库 文档算力支持 AVX2 的 CPU带 NPU 或独显决定生成速度不影响能否跑华为机器上部分型号的 NPU 需要厂商提供的推理框架才能调用Ollama 默认走 CPU 或 GPU。实测下来CPU 跑 7B 量化模型生成速度大概每秒几个字到十几个字问答场景够用长文生成会慢。小米的笔记本如果带独显Ollama 能自动识别并加速速度会明显好一截。这里有个容易被忽略的点内存比算力更影响体验。内存不够模型加载失败或者频繁换页再强的 NPU 也救不回来。买机器时如果预算有限优先堆内存。3. 三步落地从装工具到能问答3.1 第一步把 Ollama 跑起来并选对模型先装 Ollama。官网下载对应系统的安装包Windows 和 macOS 都有图形化安装程序Linux 用脚本。装完之后终端里敲ollama --version能打印版本号就说明装好了。Ollama 安装后会自动在后台起一个本地服务默认监听本机的 11434 端口这个端口只对本机开放不对外。接下来选模型。这一步很多人会踩坑——盲目追大参数。14B、32B 听起来厉害但在 16GB 内存的机器上跑起来会非常吃力甚至加载失败。我的建议是16GB 内存选 7B 级别的量化模型比如qwen2.5:7b或同量级的中文友好模型32GB 内存可以上 14B 量化回答质量明显提升有独显且显存 8GB 以上可以尝试更大的模型Ollama 会自动分配拉模型的命令很简单ollama pull qwen2.5:7b拉完之后测试一下ollama run qwen2.5:7b进入交互界面随便问一句能正常回答就说明模型跑通了。输入/bye退出。注意模型文件动辄几个 GB第一次拉取需要耐心。拉下来的模型存在用户目录下的.ollama文件夹里换机器时可以直接拷贝这个目录省去重新下载。这一步的意图是先确认模型能独立工作。如果模型本身跑不起来后面接检索也是白搭。很多人跳过这步直接上 LangChain结果报错时不知道是模型的问题还是代码的问题排查起来很痛苦。3.2 第二步用 LangChain 把文档喂进 Chroma这一步是整个链路的核心。先装 Python 依赖pip install langchain langchain-community langchain-ollama chromadb版本迭代比较快如果某个包报导入错误优先检查版本兼容性必要时锁定版本。然后写一个最小的入库脚本。逻辑分四段加载文档、切分、向量化、存入 Chroma。from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_ollama import OllamaEmbeddings from langchain_chroma import Chroma # 1. 加载文档这里以 txt 为例PDF 需要换对应的 loader loader DirectoryLoader(./my_docs, glob**/*.txt, loader_clsTextLoader) docs loader.load() # 2. 切分。chunk_size 和 overlap 是关键参数 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_documents(docs) # 3. 向量化用 Ollama 提供的 embedding 模型 embeddings OllamaEmbeddings(modelnomic-embed-text) # 4. 存入 Chroma持久化到本地目录 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db ) print(f入库完成共 {len(chunks)} 个片段)这里有几个参数值得展开说因为它们直接决定检索质量。chunk_size是每个文本片段的长度。太小一段话被切碎语义不完整太大检索出来的片段包含太多无关信息干扰模型。500 字符左右是个经验值中文文档可以适当调小到 300-400。chunk_overlap是相邻片段的重叠长度。为什么要重叠因为切分点可能正好落在一个关键句中间重叠能保证这句话至少在一个片段里是完整的。一般取 chunk_size 的 10% 到 20%。separators是切分优先级。LangChain 会按列表顺序尝试先按空行切切不动再按换行再不行按句号。中文文档一定要把中文标点加进去否则会按字符硬切语义破坏严重。embedding 模型的选择也重要。nomic-embed-text是个轻量且效果不错的选项需要先用ollama pull nomic-embed-text拉下来。注意 embedding 模型和生成模型是两回事各拉各的。提示入库脚本只需要跑一次之后文档没变就不用重跑。如果文档更新了删掉chroma_db目录重新跑一遍即可不要试图增量更新容易出脏数据。3.3 第三步串起检索和生成做成能问答的脚本入库完成后写问答脚本from langchain_ollama import OllamaLLM from langchain_chroma import Chroma from langchain_ollama import OllamaEmbeddings from langchain.chains import RetrievalQA embeddings OllamaEmbeddings(modelnomic-embed-text) vectorstore Chroma( persist_directory./chroma_db, embedding_functionembeddings ) llm OllamaLLM(modelqwen2.5:7b) qa RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrievervectorstore.as_retriever(search_kwargs{k: 4}), return_source_documentsTrue ) while True: question input(\n你的问题) if question.strip() in (exit, quit): break result qa.invoke({query: question}) print(\n回答, result[result]) print(\n参考来源) for doc in result[source_documents]: print(-, doc.metadata.get(source, 未知))k4表示每次检索返回 4 个最相关的片段。这个值可以调k 太小可能漏掉关键信息k 太大则 prompt 变长、生成变慢。4 到 6 是比较平衡的区间。chain_typestuff是最简单的策略把所有检索到的片段直接塞进 prompt。文档片段多的时候可能超出模型上下文窗口这时候可以换成map_reduce或refine但速度会慢。个人使用场景stuff 通常够。return_source_documentsTrue让脚本返回参考来源。这个功能非常实用——当模型给出一个答案你能看到它是从哪几个片段推出来的方便验证真伪。没有来源追溯的 RAG本质上和裸模型没区别。跑通这个脚本你就有了一个完全本地的问答系统。问它你文档里的内容它会基于检索到的片段回答并告诉你出处。4. 实测中真正会卡住你的几个地方4.1 中文文档切分标点符号没配对语义全碎这是最常见的坑。默认的RecursiveCharacterTextSplitter分隔符是英文标点中文文档如果不改会按空格和英文字符切结果就是一句话被拦腰截断检索出来的片段读都读不通。解决办法就是上面代码里那样把中文标点加进 separators 列表并且放在英文标点前面。另外中文没有空格分词chunk_size 按字符算500 字符大概对应 250 到 300 个汉字这个量级比较合适。还有一个细节PDF 转文本后经常出现奇怪的换行和空格入库前最好做一次清洗把连续空行合并、去掉页眉页脚。清洗脚本不复杂但能显著提升检索质量。4.2 检索答非所问embedding 模型和生成模型不匹配有人换了生成模型但 embedding 模型没换或者反过来。这会导致向量空间不一致检索出来的片段和问题根本不相关。记住一个原则embedding 模型一旦选定入库和查询必须用同一个。如果你中途换了 embedding 模型之前入库的向量全部作废必须重新入库。这也是为什么建议把 embedding 模型名称写死在配置里别随手改。另一个原因是文档本身质量差。如果原始文档就是扫描件 OCR 出来的错字连篇embedding 出来的向量也是乱的。这种情况先修文档别怪工具。4.3 华为机器上的 NPU 调用别期待开箱即用华为部分型号的 NPU 需要专门的推理框架和驱动支持Ollama 默认不会自动调用。你在任务管理器里看到 CPU 跑满、NPU 闲着是正常现象。想让 NPU 参与推理需要关注厂商是否提供了对应的推理后端以及 Ollama 是否支持该后端。截至我写这篇的时候这条路对个人用户还不算顺畅。实际体验是CPU 跑 7B 量化问答场景完全可用不必为了 NPU 折腾到怀疑人生。等生态成熟了再说。小米的笔记本如果带独立显卡情况会好很多。Ollama 能识别 CUDA 或对应的加速框架自动把模型加载到显存生成速度提升明显。买机器时如果明确要跑本地模型独显比 NPU 更实在。4.4 内存不够时的降级策略16GB 内存跑 7B 模型同时开着浏览器和办公软件可能会卡。几个降级手段换更小的量化版本比如 4-bit 量化模型体积减半质量损失可接受问答时关掉不必要的大内存程序把 chunk_size 调小减少单次 prompt 长度用num_ctx参数限制上下文窗口Ollama 支持在调用时指定这些手段的本质都是在内存、速度、质量之间找平衡。没有银弹按自己的机器情况调。5. 省下的不只是会员费5.1 数据不出本机这件事值多少钱云会员一年几百块这是明面上的账。但真正的价值在于你的合同、代码、内部文档全程没有离开过你的硬盘。向量库存在本地目录模型文件存在本地目录问答过程在本地内存里完成。断网也能用。对于处理敏感资料的人来说这个属性本身就是刚需。不是说不信任云端而是有些东西压根不该有上传这个选项。5.2 从能用到好用几个提升体验的调整跑通之后可以做几件事让它更好用。建多个知识库。工作文档一个库个人笔记一个库用不同的 persist_directory 分开存。查询时按需切换避免不同领域的文档互相干扰检索。加一个简单的 Web 界面。LangChain 生态里有现成的对话界面组件几十行代码就能起一个本地网页比命令行舒服。界面只监听本机不对外暴露。定期更新文档库。文档变了就重新入库别偷懒。过期的知识库比没有知识库更危险因为它会用旧信息误导你。记录好用的 prompt 模板。RAG 的回答质量很大程度取决于你怎么组织 prompt。比如加上如果参考资料中没有相关信息请明确说明不知道不要编造这类约束能显著减少幻觉。5.3 这套方案不适合什么场景说句实在话本地知识库不是万能的。如果你需要的是超大规模文档的秒级检索几万份以上Chroma 会吃力得换更专业的向量数据库。如果你需要的是最强的推理能力本地 7B 模型和云端大模型差距明显复杂推理任务还是云端强。如果你完全不想碰命令行这套方案的学习成本对你来说可能偏高可以考虑厂商自带的 AI 助手虽然灵活性差但开箱即用。我的建议是本地知识库处理日常问答和资料检索复杂任务再考虑云端。两者不是替代关系是分工关系。省下的会员费是省在那些本来就不需要云端算力的场景上。搭这套东西花了我一个下午其中一半时间在踩切分参数的坑。跑顺之后查自己攒的资料再也不用翻文件夹问一句就有答案还带出处。华为和小米的 AI PC 硬件底子够用真正决定体验的是软件层这套管线搭得对不对。模型选小一点、切分参数调细一点、embedding 模型别乱换这三点做到基本就稳了。
