夜雨聆风“ 文档处理OCR是一种相对比较简单，成本可控的处理方式。”
最近接到了一个新需求，分析word中的表格解析出其中的参数项，去做检索；需求说起来其实挺简单，文档解析+检索，而且检索还是已经做好的，现在只需要做个文档解析即可。
本来想着简单的文档检索也不是很复杂，就直接用markitdown把word文档转换成markdown格式，然后丢给模型分析，让模型完成检索即可。
但是在测试的过程中发现一个问题，word文档中有部分是旧格式的doc文档，不过这个也没什么，加一层处理即可；所以在处理文档之前，先加了一层文档转换，把旧格式的doc文档转成docx文档。
然后在测试的时候又发现了一个问题，那就是文档中存在pdf格式，不过pdf格式markitdown本身就支持，但是比较坑的一点是pdf中既然有扫描件，这个时候就没办法了，makritdown完全处理不了。
所以这时只能使用OCR来解决这个问题了，而且OCR不论是什么格式的都可以处理，使用起来比较简单，并且还没有上面乱七八糟的格式问题。
以上是我遇到的文档解析的问题，但这些都不是最主要的，只是文档处理的方式不一样而已。在实际开发过程中，我们需要根据不同的文档格式，选择合适的处理方法。
主要问题是，刚开始用markitdown做处理时，测试了几个文档没问题，就丢给测试去测试了；然后后面才遇到了doc和pdf扫描件的问题，然后第二天就直接改成了OCR进行处理，并且没有跟测试说。
然后第二天开会的时候，测试直接和我说是不是改什么东西了；昨天测试的时候，有好些数据项都识别不出来，但今天大部分都可以识别出来了。
当时听到这话的时候，我都惊呆了，换了一种文档处理方式，影响有这么大吗？效果有这么好吗？
其实在知识库中，文档处理一直是一个重难点，包括到现在依然没有完美的处理方式，哪怕是大厂出品，在某些情况下的效果依然是一言难尽。
原因就在于文档格式，内容，布局太复杂，而这些依靠代码很难处理的好；但是，不管使用哪种方式，做文档处理的主要目标就是尽可能的提取文档结构，保证文档内容的完整性。
并且，还要尽可能的去除文档噪音，减少噪音数据对整个文档处理结果的影响。
网络上其实有很多开源的知识库项目，然后也有很多在文档处理方面做的不错的项目，所以我们在实际应用过程中，可以根据具体的情况，使用不同的文档策略，选择不同的处理框架。
文档处理作为知识库的第一步，其效果直接影响到后续的全部流程；所以一个知识库系统，文档处理的开发时间要占百分之六十以上。