标准文档那么厚,让AI帮我找答案

前几天去了一趟代工厂，期间发生一件事，让我萌生做一个IPC标准查询的应用。

当时我们的产品在生产，有个元器件（BGA）通过X-ray，发现存在空洞情况，我记着标准是小于25%，对方工厂的同事记得是小于30%。

既然存在争议，那就找到真实答案，说服对方。

当时在车间里，我想着先用手机在网上搜下答案（Class3），结果跟我俩的说法区别很大：

于是让对方取来电脑，并找到IPC最新版的电子档，先打开文件，查询目录，找到大章节，小标题，记住页数，往后翻，最后得到答案是：

结果证明对方是对的，我可能是记错了。。。，整个过程耗费差不多20分钟。

说句不好听的，这20多分钟，都够我中午睡一觉的，属实有点浪费。

毕竟自己在研究AI，于是我打算做个检索功能，然后配置到飞书端，随时随地使用手机就能查询官方标准，整个过程可能只要10秒钟。

既然想法有了，那就要行动起来。

我的目标是：随时随地可以查询到行业标准，节约时间成本。

大致的流程应该是：先确定主体逻辑流程，然后搭建知识库，最后验证测试，再发布到飞书。

看起来十分简单，我很快就把流程搭建完毕。

这时候的重点就是搭建知识库，由于我还不太了解其原理，先去官网看下介绍：

遇到概念性的内容，我会复制粘贴到Deepseek，让AI给我总结下，重点是看下面的案例（最小闭环），熟悉下流程。

学完直接动手，我把一份110页（截取的某一章节）的标准文档直接上传知识库，按照教程上的指引，设置好参数，信心十足的准备测试下。

其实我对知识库有一个完美的期待：输入一句话，知识库会精准检索到准确答案给我。

然而测试的结果是：

平心而论，有点失望，但我觉得这个问题应该有解。

把这个问题抛给AI，并且得到一个重要信息："文档预处理"

看了AI的详细介绍，我对预处理有了一个初步的了解。

这个预处理，让我想起电视剧"相爱十年"，超哥在天台卖唱片那个片段。

他之所以卖的好，纯粹是他把一大箱的唱片进行了分类，然后贴上便签（歌星/歌名）以便快速识别，只要顾客一说名字，他立马就能找到。

这个跟文档预处理简直有异曲同工之妙。

就像是去菜鸟驿站取快递，D1-3-38，你知道是D1货架，第3层，第38号，假如驿站没有提前预处理归类，我这个用户怕是得找上1~2个小时。

我的标准基本是模式是问题+答案，处理成QA（问答对），会比较高效。

但是在处理文档之前，得先弄个简单的问答对进行测试，看下效果。

我利用下方这些个问答对（只截了一部分，一共十多个QA对），导入知识库，并进行测试。

在分段策略与参数配置环节，持续验证测试2个小时后，终于成功：

这次可以正式开始，先用MinerU对标准文档进行MD处理，并整理成问答对的形式，然后上传到coze知识库，可以看到每个问答对都被明确的分块，并以【QA结束】区分。

分段策略及下面设置的召回参数，是我前面的验证得到的最优配置：

召回量"2"，最小匹配度"0.5"

然后就取下方这个QA问答对，进行测试

▲ 输出：

可以看出，正确答案是第一个，也就是说他的匹配度是最高的。

这时候可以在知识检索节点后的大模型，让模型引用用户的输入，并把知识检索的输出作为上下文去回答用户问题，这样会更精确。

我连续测试了15个问题，输出均符合预期。

做完这个应用后，发现有三个点是需要我特别注意的：

第一是文档预处理，尤其是大篇幅的，说实话处理完，还得核对一遍，这个不容有错。

第二是预处理文档的分段策略，我不断的尝试，才识别出有效的分段标识。

第三是节点配置里的参数，比如召回量，最小匹配度，需要调试几次，对照输出做适当调整。

工作中用到RAG的地方很多，我打算把所有的"厚"文档都让AI帮我搞定。