三个月前的一个晚上，我坐在电脑前。对着刚搭好的 AI 知识库输入了第一个问题：「Redis Cluster 的 gossip 协议在节点故障时怎么处理的？」

这个问题的答案我自己写过——一篇 3000 字的专栏文章，就在知识库里。

但检索结果让我愣住了：前三名全是 StackOverflow 的社区回答。第四名是一篇两年前的公众号转载，我自己的原创文章排在第七位。

那篇原创是我花了两个周末写的，结构清晰、有源码分析、有压测数据。StackOverflow 那个回答只有 150 字。只说「gossip 协议会自动检测并移除故障节点」，聊胜于无。

那一刻我才意识到：技术选型只是搭了个壳。真正决定检索质量的，是你往壳里放了什么、怎么放的。

为什么大多数人只关注技术选型？

这半年 AI 知识库相关的讨论，几乎全部集中在向量数据库选型上——Milvus 还是 Qdrant？Embedding 模型用哪个？chunk size 设 512 还是 1024？rerank 要不要加，

这些当然关键，但它们只是 AI 知识库的「硬件」。就像你配了一台顶配电脑，装的操作程序和应用软件全是盗版——跑起来的体验依然一塌糊涂。

我在上篇文章里讲了为什么决定退掉所有 AI 订阅、自建个人知识库。后台收到不少私信，大部分在问向量数据库怎么选、embedding 模型哪个效果好。很少人问我的观点是，「码哥，你那些文章放进知识库之前，做了哪些处理？」

你的痛点：「我已经买好了硬件，却总是找不到想要的信息」——这正是内容组织缺失导致的搜索不准。

实际来说，我一开始也没处理。

第一批数据导入时我把 200 篇文章、几十个 GitHub Discussion 收藏、几百条随手记的笔记一股脑全扔了进去。chunk 策略用了个看起来很合理的 500 字切片。跑了一遍 embedding，觉得大功告成。

接下来就有了开头那一幕——检索结果被低质量内容淹没。

这不是向量数据库的问题，不是 embedding 模型的问题。说起来，是我自己在入库这一步就做错了。

再看我踩过的坑。三个失败的尝试

第一次尝试：全部平权

200 篇原创、30 篇收藏文章、几十个 GitHub issue 讨论，全都用同一套参数处理。从结果就是来看，你精心写的深度分析。和三年前随手收藏的一篇热点文，在向量空间里的「地位」完全一样。

检索程序不知道哪篇是你的心血，哪篇只是你顺手点了个收藏。

第二次尝试：按来源分类

我在文章上打了标签——「原创」「转载」「社区」。想着标签可以过滤，但实际用起来发现，标签只是给内容加了一个维度。检索的时候你不可能每次都手动筛选标签。而且标签太粗——一样是原创。10 000 字的深度专栏和 300 字的碎碎念仍然被放在一起，不公平。

第三次尝试：手动精选

我决定只放「我认为质量最高」的文章。花了两个晚上手动筛选，最终留下了 80 篇。效果确实好了不少——检索结果精准了很多。不过，但代价也明显的观点是，很多「质量一般但内容相关」的信息没了。比如有一次想查 Kafka 的配置参数，那篇收藏的 StackOverflow 回答被筛掉。我的原创又没涉及这个细节——检索结果直接为空。

关键体会：知识库不是收藏夹，不是一个「要么放、要么扔」的二元选择。不同类型的内容应该有不同的定位和权重，这就是“三层结构”的起点。其实，

三层结构完整视图

每层独立筛选标准与分块策略。 层与层之间逐级补充，实现精准召回与高效过滤。

第一层的观点是。原创内容——你的主要资产

反直觉这一层不需要再做筛选，你自己写的东西全部入库。

• 筛选标准：写过 = 入库。不用再筛，
• 优势：
  • 结构清晰——天然拥有 H2/H3 标题，可做「结构感知分块」；
  • 逻辑完整——每篇都有完整论证链条，AI 检索时能关联上下文；
  • 独特观点——区别于其他人的竞争优势。

目前库中已有 120 篇原创覆盖 Redis、Kafka、JVM、MySQL、算法、AI 与架构设计等领域。每篇按 H2/H3 自然切分，chunk 控制在 300 字左右，一篇通常切成 8–12 个 chunk。

分块策略：结构感知分块

• Avoid fixed‑size slicing.
• CUT along document hierarchy: each H2 → one chunk;if H2 exceeds 500 字，再按 H3 再细分.
• The result is a self‑contained “knowledge unit” that won’t be split mid‑concept.

说到第二层。日常摘要——你的信息过滤器

Your Pain Point： 大量阅读却没有消化，总是“收藏即入库”，导致检索时找不到真正想要的信息。

实施方法：

1. #1 与工作领域高度相关；
2. #2 完整阅读后才写摘要；
3. #3 加入个人判断。

通过这三条硬指标，每天能留下的大约只有原始收藏量的10%–20%。怎么说呢，这正是高信噪比入口。

Semi‑automatic Benefits：

• Your own wording aligns 娱乐ter with your query style。boosting semantic match.
• A/B test shows: 原文 chunk 命中率 ≈ 45%，自撰摘要命中率提高至 78%。

Slicing Strategy：模板段落分块

• Total length: 150–250 字；CUT by paragraph → each paragraph becomes a chunk.No hierarchical splitting needed—摘要本身已是精炼单元。老实说，

  第三层的观点是。社区智慧——你的外部精华库

  Your Pain Point： 外部资源杂乱无章，一旦导入就会淹没内部高价值信息。

  Sourcing Rules

  1. #1 时间验证： 仅收录发布超过 6 个月且仍被持续引用的非热点内容；#2 可复现方案： 必须包含代码/配置/步骤，可直接落地执行；#3 补盲区： 若已有同主题原创。则跳过相似社区内容，仅保留未覆盖领域。

     每周最多加入 15 篇精选，以免沦为“海报墙”。宁缺毋滥原则确保质量恒定在高位。

     Slicing Strategy：Q&A 对分块法

     • - 将问题与对应答案合并为单个 chunk；话说回来，- 若答案包含多个方案/步骤，则每个方案单独形成 Q&A 对；老实说，- 每个 chunk 控制在 400 字以内。以保证完整语义匹配，

       再看更新节奏。控制总量比疯狂收集更关键

       • * 层* → 每周 ≤ 15 篇，只保留对话中实际引用过的;* 季度清理* → 剔除过时、已被内部新稿取代或零命中的条目;

         至于常见错误，这些事做错。三层结构等于白搭

         1. Error 1 – 什么都往里扔： 存储成本低，却极大稀释检索精度，每多一条无关信息，好结果排名可能下降一位。Error 2 – 只收集不消化： 自动导入工具只能搬运原文味道。你用自己的话提问时难以匹配，从而产生“隔离效应”。l i> Error 3 – 结构混乱：&nb sp;同主题内容散落多个笔记工具，无统一目录或标签程序。使得向量检索无法得到结构化加持。l i> Error 4 – 从不清理：&nb sp;老旧框架常用方法仍占据排名，引导错误决策。l i>