把我的 26 篇软著文章喂成可检索素材库nomic-embed 本地知识库最小搭建记录写软著材料真正烦人的不是写是找。我这半年在 CSDN 上陆陆续续发了 26 篇软著相关的东西材料清单、格式规范、避坑、常见问答都有。可真到自己要改一份说明书的时候还是打开文件夹CtrlF 一篇篇翻翻到一半忘了刚才用的关键词重新来一遍。上周末花了两个晚上把这 26 篇 Markdown 喂进了一个本地知识库。现在在终端敲一句问题它直接告诉我「看第 12 篇的『源代码页数』那一节」不用再翻。为什么不直接把文章全贴给大模型先算笔账。26 篇平均 2400 字全贴进上下文大概是六万多个字符按中文粗估四万 token 上下。每次提问都重新塞一遍一是贵二是模型在长上下文里对中段的注意力会掉问到最后回答反而比只给一段还糊。所以路子反过来先把问题变成一次检索再把命中的那几段喂给模型。检索用本地模型做不花钱生成用哪个模型都行。一、让素材「能被切」比选模型重要检索质量的上限在切块这一步就定死了。我的做法就三条目录按主题分不按时间堆。docs 下开了四个子目录materials材料清单、format格式规范、flow流程时效、pitfall避坑。文件名保留日期前缀方便排序但归类看内容不看去重的时间。每篇只用一个##层级。一级#留给文章标题正文一律用##分节。这样切块时直接按##的位置切一块就是一个完整小主题语义不会断在句子中间。表格和代码块单独成块。混在正文里切经常一刀切在表格中间检索出来半张表等于没检。二、本地方案Ollama 拉一个 embedding 模型就够先不装向量数据库用一套很朴素的跑通Ollama 出向量余弦相似度做检索。拉模型我用的nomic-embed-text768 维中文效果够用模型体积不到 300MBollama pull nomic-embed-text建库时对每一块调一次接口把向量和原文一起写进一个 JSONcurl http://localhost:11434/api/embeddings -d { model: nomic-embed-text, prompt: 软著说明书的截图规范 }检索时把问题也转成向量和库里每一块算余弦相似度取分数最高的几块拼进提示词。整条链路上没有任何网络请求断网也能跑。三、踩过的三个坑一是切块别设固定字数。一开始我按 300 字硬切结果「页码规则」那一节被劈成两块检索出来只有后半段前半段的结论丢了。改成按##切块长从八十多字到九百多字不等反而更准。二是问题要带场景词。直接问「怎么弄」检索出来全是泛泛的流程图。改成「源代码不足 60 页怎么提交」这种带具体条件的命中率明显上来。三是相似度要给下限。只取 top 5 不看分数偶尔会把完全不相关的块混进去反而干扰模型。我给相似度设了一个阈值低于它的直接丢宁可少召回也不要噪音。四、这件事和「材料整理」是同一件事我做这个知识库的动机和我做软著材料辅助整理工具的动机是一样的软著申请真正耗时间的不是写是在一堆规范里定位到当前这一步该看哪一条。把规则沉淀成可检索的东西改材料的时候就不用凭记忆。下面这套目录骨架可以直接抄docs/ ├── materials/ 材料清单与盖章要求 ├── format/ 页眉、页数、字体、截图规范 ├── flow/ 实名、填报、受理、补正的时间线 └── pitfall/ 高频补正原因与对应改法自查清单每篇只有一个#标题正文统一用##分节表格、代码块不跨##边界建库用的检索测试问题要带具体条件页数、日期、名义给相似度设下限宁少召回也不放噪音建好库先断网测一遍确认全链路本地作者信可维做软著申请材料的辅助整理与规范生成。