普通电脑搭一套高中九科 RAG 助手，我真正解决了哪些问题？

我想解决的问题很具体：高中九科教材、个人笔记和速记手册已经积累了不少，但查找知识时仍要在多个目录和几十本 PDF 之间来回翻。如果能直接提问、看到答案，同时知道答案来自哪本教材的哪一段，资料才真正形成可用的知识库。

这次我没有从头开发一套 RAG 平台，而是在普通 Windows 电脑上组合 AnythingLLM、本地中文嵌入模型、LanceDB 和 MiMo API。最终导入 127 篇笔记和九科 40 本教材，共形成 780 个文档、7,059 个向量块。

完整架构、脚本和验收边界放在高中学习 RAG 问答助手项目页。这篇文章主要讲选择背后的原因，以及实际落地时最值得记录的几个问题。

一、它目前是 RAG 助手，还不是 Agent

系统现在能做三件事：检索教材和笔记、基于召回片段生成回答、展示引用来源。它还不会自己规划学习任务、选择多个工具、连续执行并检查结果。

因此我把它定位为“高中学习 RAG 问答助手”。以后即使加入自动出题或笔记回写，只要流程仍由固定按钮触发，也不必急着叫 Agent。名称应该反映已经验证的能力，而不是未来愿景。

二、普通电脑为什么选择本地检索与云端生成

本机没有适合运行较大语言模型的独立显卡，但向量化和向量检索并不需要同等级算力。我最终把系统拆成两部分：

环节	运行位置	选型
文档、解析文本和向量库	本机	Obsidian、AnythingLLM、LanceDB
中文嵌入	本机	multilingual-e5-small
回答生成	云端 API	MiMo

这样做降低了本机推理负担，也保留了本地文档管理和检索能力。但必须把隐私边界说准确：教材、笔记和向量库保存在本机；生成回答时，问题与召回片段仍会发送给 MiMo API。

MiMo 官方文档说明其 API 提供 OpenAI 兼容调用格式；具体地址、模型和计费方式可能变化，配置时应以官方快速开始为准。

“本地知识库”不等于“所有数据都不出电脑”。如果资料包含个人信息、未公开试卷或其他敏感内容，应先脱敏，或者改用经过实际验证的本地模型。

三、最大的坑不是模型，而是 PDF 根本没有读完整

第一次把教材交给 AnythingLLM 后，界面显示上传成功，我以为最难的部分已经结束。随后检查解析结果，发现一本约 15 万字的语文教材只得到约 4 千词，主要剩下封面和版权页。

如果不检查中间结果，后续可能出现一种很迷惑的现象：模型回答得很流畅，却总是找不到教材正文。此时换 Prompt、换大模型都解决不了问题，因为正确内容根本没有进入检索链路。

我最后改用 pypdf 按页提取文字，再把每 10 页整理成一个 Markdown 分节。每节保留原始教材页码，再上传到 AnythingLLM。这个处理带来两个直接好处：正文完整进入索引，引用也能回到具体页段。

对于没有可靠文本层的扫描页，pypdf 仍然不够。它们需要进入 OCR 分支，并用人工标注样本检查错字、漏字、页序、表格结构和关键字段。

四、中文检索需要单独验证

AnythingLLM 的默认嵌入模型没有满足这批中文材料的检索需要。我改用本地 multilingual-e5-small 后重新建立向量，再用跨学科问题做主链路抽查。

问题	预期来源	抽查相似度
《沁园春·长沙》上阕写了哪些景色？	语文必修上册	0.89
三省六部制的内容与影响？	历史教材与笔记	0.90
细胞呼吸分几个阶段？	生物必修第一册	0.91
社会主义核心价值观的基本内容？	政治教材	0.91

这些结果说明检索链路已经工作、预期资料进入了靠前结果，但相似度只是当前模型空间里的排序分数，不等于答案正确率，也不是跨模型通用的质量刻度。

五、上传成功只是开始，入库必须对账

笔记和教材数量增加后，手工拖拽很难回答几个关键问题：哪些文件已经处理、哪些发生修改、哪些只上传却没有加入工作区、哪些文档没有生成向量。

我用脚本调用 AnythingLLM 的上传和工作区接口，并记录文件路径、哈希与处理状态。一次可靠的同步至少要核对：

• 符合规则的源文件是否全部进入台账；
• 上传后的文档是否加入正确工作区；
• 每份有效文档是否存在向量；
• 同一路径是否出现旧版本或重复副本；
• 同步结束后再次扫描，是否还有新增或变化文件。

接口返回成功只说明某一步请求被接收。只有源文件、台账、工作区文档和向量状态一致，才能说这次同步闭环。

六、后续可以怎样优化

当前版本已经跑通教材与笔记导入、中文检索、云端生成和引用展示。继续优化时，我不会先盲目增加教材数量，而是从实际使用中最影响体验的地方逐步改进。

第一步是按学科拆分工作区。九科材料全部放在一个库中便于统一提问，但资料继续增加后，跨学科内容可能相互干扰。按语文、数学、英语等学科划分检索范围，可以让问题先进入更明确的材料集合。

第二步是改善教材处理。文字版 PDF 继续保留按页提取和页码标记；扫描版教材增加 OCR，并把公式、表格、图片说明和多栏排版作为单独处理对象。解析失败的页面记录下来，方便人工补录或重新扫描。

第三步是优化回答方式。可以为不同学科准备不同提示模板，例如数学强调步骤和条件，语文强调原文依据，历史强调时间线与因果关系。回答中继续保留引用来源，让使用者能随时回到教材核对。

第四步是完善日常维护。把新增笔记自动同步、失败任务重试、重复文档识别和备份恢复做成固定流程，减少每次手工检查的成本。

最后再增加学习功能，例如根据教材章节自动生成练习题、把错题整理成复习卡、将有价值的问答回写到 Obsidian。做到这一步后，它才会从“能查资料”逐渐变成真正参与学习过程的助手。

七、这次搭建真正得到的结论

一套个人学习知识库并不需要从零开发，也不一定需要高性能显卡。真正影响结果的往往是更基础的工程环节：材料有没有读完整、中文嵌入是否合适、来源能否追溯、批量同步能否对账、验收是否使用未见样本。

工具可以快速搭起来，长期价值来自持续使用和维护。对学习场景来说，能引用教材只是起点；更方便地找到资料、回到原文、整理错题并沉淀笔记，才是这套系统继续迭代的方向。

完整项目记录、架构、脚本清单和当前限制见项目详情页。