• 作者: 作者
  • 时间:
  • 分类: 文章

在现在的开发圈里，RAG（检索增强生成）似乎成了处理私有数据的“标准答案”。上来就是向量数据库、Embedding 模型、各种向量检索框架，配置一套下来，光是 GPU 资源和 API 费用就让人肉疼。

而且，很多时候我们遇到的需求其实很简单：就是想让 AI 在处理特定任务时，确切地“看到”某几段我指定的文字，并且比其他废话更重要。

如果你也像我一样，不想为了点小功能就搞个重型架构，不妨试试这种“手动构建 Context Engine”的土办法。虽然名字听起来很 Low，但在实际调优中，这种精确控制权往往比全自动的向量检索更顶用。

什么是“手动” Context Engine？

说人话，其实就是把“检索”这个环节自动化，换成了“半自动化的人工干预+脚本辅助”。

传统的 RAG 是这样子的：你扔进去一大堆文档 -> 系统自动切分成向量 -> 你提问 -> 系统去向量库里找相似度最高的 Top-K -> 扔给 AI。

这种方式有个痛点：有时候相似度是不准的。 比如你问“报错代码 500 怎么办”，向量检索可能会给你找出一堆包含“500”这个数字的文章，但偏偏漏掉了你笔记里那条冷门但关键的解决方法。

手动构建的核心逻辑是：既然我知道我知道什么，那我就把我知道的东西，整理成 AI 最容易消化的格式，塞给它。

具体落地实操

这里不谈理论，直接说怎么干。

1. 原始数据的“去油腻”清洗

别把你收藏的网页、PDF 直接丢进去。AI 也是有“消化不良”的。我们需要把那些 HTML 标签、广告弹窗文字、多余的 CSS 注释全部砍掉。

推荐做法： 如果你是搞技术文档的，建议统一转为 Markdown。Markdown 对大模型极其友好，无论是代码块高亮、标题层级还是列表结构，模型都能很好地理解语义权重。

对于非结构化文本（比如聊天记录、产品需求文档），写个简单的正则脚本，把时间戳、无意义的问候语（“你好在吗”、“收到”）全部过滤掉。Context 的窗口寸土寸金，每一 Token 都要花在刀刃上。

2. 建立你的“知识碎片”索引

很多人喜欢把所有东西都写在一个巨大的 .txt 里。千万别这样！

你要建立一种“碎片化”的思维。把一篇长文拆分成多个独立的逻辑块。比如一篇关于“Python 性能优化”的文章，你可以拆成：

  • fragment_01_loop_optimization.md
  • fragment_02_memory_leak_check.md
  • fragment_03_concurrent_processing.md

为什么这么做？ 因为在构建 Prompt 的时候，我们可以根据用户的提问关键词，精准地选择加载 fragment_02，而不是把整篇文章都塞进去。这就是手动检索的精髓——精准召回。

3. 权重与大小的黄金法则

这是整个手工流程中最重要的一步。

第一法则：重要信息靠前写。 虽然现在很多模型支持了“无限长”上下文，但事实是，模型对 Prompt 开头和结尾的注意力通常比中间要高。如果你有核心规则（比如“永远不要输出 YAML 格式”），请把它放在 System Prompt 的第一段或者 Context 的最开头。

第二法则：控制 Token 数量。 不要试图把 100 万字的文档一次性塞进上下文。哪怕是 2026 年的长文本模型，大量的噪音也会导致它“幻觉”频发。

我的经验值是：

  • 核心指令 + 必要示例：控制在 1000 tokens 以内。
  • 单次检索的外部知识片段：控制在 2000 tokens 以内，且片段数量不要超过 3-5 个。

4. 简单的拼接脚本

不需要复杂的编程语言，Bash 或者 Python 都能搞定。你只需要写一个简单的逻辑：

  1. 监听输入（比如用户的问题）。
  2. 关键词匹配（如果输入包含“数据库”，就去 database/ 文件夹下找）。
  3. 读取对应的 .md 碎片文件。
  4. 拼接成固定模板：
[Role Definition]
你是一个资深的技术专家，请依据以下 Reference 信息回答用户问题。

[Reference Information]
{这里插入脚本读出来的文件内容}

[User Question]
{用户的问题}

[Constraints]
- 如果 Reference 中没有答案，请直接说不知道，不要编造。
- 保持口语化。

这就够了。这种“伪”RAG 系统，在很多垂直场景下（比如公司内部的知识库问答、特定代码库的维护），效果往往比靠向量语义瞎猜要稳得多。

这种方法的优缺点

优点很明显：

  • 可控性强：你知道 AI 看到了什么，没看到什么。出了问题很容易排查是哪段文本写得不清晰。
  • 成本低：零向量数据库成本，零 Embedding 接口调用成本。纯文本处理，最便宜的云服务器都能跑。
  • 调试快：修改一段知识库内容，改一下 MD 文件就行，不需要重新训练索引。

缺点也得说清楚：

  • 维护成本随数据量线性上升：如果你有几千篇文档，手动整理碎片会累死。这时候确实该考虑 RAG 了。
  • 依赖关键词匹配：如果用户问的和你的文件名/标签词不对应，可能召不回来（但这可以通过给碎片打多标签解决）。

适用人群

如果你符合以下画像，这个方法非常适合你：

  1. 个人开发者：有一套自己常用的代码片段或技术笔记，想让 AI 帮你写代码时遵守这些规范。
  2. 轻量级团队：知识库主要集中在几十个核心文档上，不想搞复杂的 DevOps 流程。
  3. 调优强迫症：觉得标准 RAG 太“玄学”，想要对 Prompt 进行像素级控制的人。

总结

技术圈总是追逐新名词，但解决问题的办法不一定非要最新、最贵。手动构建 Context Engine 本质上是一种**“返璞归真”**的工程思维。

它承认了 AI 现阶段的局限性（理解力虽有但不够精准），并用最朴素的文本工程手段去补齐短板。有时候，多花点时间整理你的数据结构，比换个更牛的模型提升还要大。

下次再被 RAG 搞得头大时，不妨关掉向量数据库，打开记事本，试着亲手把你的知识“喂”给 AI。

标签: none

AI Skills Smart Station on Nick Launches

评论已关闭