我正在进行一个GCP Document AI项目。首先，让我说一下——OCR运行良好：-(。如果可能的话，我很想知道改进的可能性。
现在发生了什么
我编写了一个python模块，它将为通过门户上传或由系统中的代理收集的tiff文件完成OCR。该模块的编写方式避免了在本地使用原始文件内容，因为文件在云存储桶中很容易获得。但是，我要付出的代价是使用batch_process_documents()API而不是process_document()。
观察
这是一个明显的问题，因为如果通过内联API提交文档，大多数时间不到5秒就可以恢复OCR。但是，批处理(只有一个文档：-|(几乎每次都要花费45秒以上的时间。有时会超过一分钟或更长时间。
我正在寻找一个解决方案，以减少OCR调用时间。据我所知，内联API并不支持gcs-uris，所以我要么需要下载内容，通过内联API上传回来，然后进行OCR，要么我需要忍受性能的降低。
有没有人处理过类似的案件？或者，如果有任何方法可以在不使用批处理api或下载内容的情况下解决这个问题？感谢您的帮助。
根据您的要求，由于您的担忧与比较Document API的流程和批处理方法调用之间的响应时间时的延迟有关，因此使用单个文档，结果分别为5秒和45秒。
- process_documents((方法对可以发送的页数和文件大小有限制，并且每个API调用只允许一个文档文件
- batch_process_documents((方法允许异步处理较大的文件和批量处理多个文件
单个请求面向较小的数据量，这些数据量通常需要很短的时间来处理，但在处理大量数据时可能性能较低，另一方面，批处理请求被定向为处理更大量的数据，这将比单个请求具有更好的性能，但在处理少量数据时可能具有更低的性能。
关于您对这两个方法调用延迟的担忧，通过查看文档，我发现对于单个请求或同步("在线"(操作(即即时响应(，文档数据在内存中处理，而不是持久化到磁盘。在异步脱机批处理操作中，由于文件可能大得多，无法放入内存，因此文档将在磁盘中处理。这就是为什么异步操作比同步操作花费大约10倍的时间。
这些方法调用中的每一个都有一个特定的用例，在这种情况下，选择使用哪一个将取决于对您更好的权衡。如果时间响应很关键，并且您希望尽快得到响应，则可以拆分文件以适应大小，并将请求作为同步操作，同时牢记API的配额和限制。
此问题跟踪器中已提出此问题。我们目前无法提供ETA，但您可以在问题跟踪器中跟踪进展，您可以"启动"问题以接收自动更新，并通过参考此链接为其提供牵引力。
由于这是最初发布的，Document AI API添加了一个功能来在处理请求中指定field_mask，这限制了Document对象输出中返回的字段。这可以减少某些请求的延迟，因为响应的大小较小。
https://cloud.google.com/document-ai/docs/send-request#online-处理器