这就是很多人在做知识库搭建教程时容易忽略的问题：你以为你是在喂数据，其实你是在喂垃圾。

别把 PDF 丢进去就以为那是知识库了

很多新手觉得，把一堆 PDF 扔进 RAG（检索增强生成）系统里，就能自动生成一个懂行的“私人助理”。这种想法太天真了。

实测发现，如果直接把未经清洗的文档丢进去，检索召回率（Recall）通常只有 40% 左右，模型给出的答案往往是“文档中未提及”或者干脆开始一本正经地胡说八道。

我总结了一个避坑逻辑，专门对付这种检索失效的情况：

| 处理步骤 | 错误做法 (Bad) | 正确做法 (Good) | 效果对比 |
| :--- | :--- | :--- | :--- |
| 文档清洗 | 直接上传原始 PDF | 转换 Markdown 并去除页眉页脚 | 语义切片准确度提升 60% 以上 |
| 切片策略 | 按固定字符数切片 (如 500 字/块) | 按语义段落 + 重叠区 (Overlap) 切片 | 彻底解决跨段落信息断层问题 |
| 索引方式 | 仅使用向量检索 (Vector Only) | 混合检索 (Vector + BM25) | 针对特定名词/编号的搜索精度暴增 |

如果你想研究更深层的底层逻辑，可以在 AI模型讨论 里看看大家对不同 Embedding 模型在中文语境下的表现测评，有些模型在处理长文本时的语义漂移简直离谱。

一个能跑通的 AI Agent 实战案例：自动化财务报表审计

我最近折腾了一个小工具，用来辅助审计初级人员核对发票和合同。这其实是一个很典型的 AI Agent 实战案例。

普通的对话机器人只会“问答”，而 Agent 会“行动”。我的逻辑是这样的：

1. 感知层：监听指定文件夹的新文件。
2. 思考层：调用 LLM 判断文件类型。如果是发票，进入“数据提取模式”；如果是合同，进入“条款风险模式”。
3. 工具层：调用 Python 脚本计算发票总额，并与 Excel 里的记录进行比对。
4. 输出层：如果金额不符，直接在钉钉/飞书发一条带红标的提醒。

这里有一个关键的代码片段，是解决“模型提取金额经常出错”的核心逻辑。我没有直接问“金额是多少”，而是强制要求模型输出 JSON 格式，并配合 Regex（正则表达式）进行二次校验：

import re
def extract_amount(text):
    # 严禁让模型直接给结果，先拿原始文本做正则二次验证
    pattern = r'¥\s?(\d+\.\d{2})'
    match = re.search(pattern, text)
    if match:
        return float(match.group(1))
    else:
        # 如果正则没匹配到，再启动 LLM 进行模糊逻辑推理
        return llm_fuzzy_extract(text)
这里的 llm_fuzzy_extract 是通过设置 Prompt 强制模型只输出数字

这种“规则 + 模型”的双保险策略，让我的 Agent 在处理复杂发票时的准确率从原来的 72% 直接拉到了 96% 以上。

知识库搭建里的“语义陷阱”

我发现很多人在搭建知识库时，最容易在“清洗数据”这一步偷懒。

举个例子，有些 PDF 文档里的表格，如果直接转成文本，会变成一堆毫无关联的数字。
错误效果：2023年1月 收入 5000 元 支出 2000 元
这种文本对于向量检索来说极其不友好，因为它失去了“时间-科目-金额”的结构化关联。

处理这种问题的终极解法是：把表格转成 Markdown 表格格式再入库。

我用 GPT-4o 把一组乱七八糟的扫描件表格转化成了标准的 Markdown，然后测试了一下检索效果。

这其实就是一种高质量的 资源分享，如果你能把这一套工作流固化下来，你的知识库就不再是一个“搜索框”，而是一个真正的“大脑”。

别被复杂的工具链给唬住了

刚接触 Agent 的时候，你可能会看到各种 Agent Framework（比如 LangChain, AutoGPT, CrewAI）。

讲道理，如果你的需求只是做一个简单的文档问答，真没必要把 LangChain 这种重型武器搬上来。它太重了，调试起来简直是噩梦。对于 80% 的日常办公场景，我建议先从最简单的 Python + OpenAI API 组合开始。

直接写几行逻辑判断，比去研究那套复杂的类继承关系要高效得多。

哪怕是一个只有 20 行代码的脚本，只要它能准确识别出你文档里的特定错误，它就比那些封装得天花乱坠的商业软件要有价值得多。