Repository navigation
希望增加视觉大模型识别文本功能的API接口 #178
Description
作者你好！我尝试了一些视觉大模型路线的通用图片转文字功能实现作为OCR功能的替代，发现它们的识别准确性不错。希望能增加一些可通过BaseURL、API等方式配置的通用图片转文字功能实现的接口。我做了一些初步的尝试，通过python flask + ollama + deepseek-ocr制作了一个简易的本地通用转文字（当然，可能需要一张相对较好的显卡配置来运行）。我通过监听本地的6666端口通过了一些简单的OCR功能性测试。这个是我的测试图
这是一个简化版本的参考实现（当然，OLLAMA_URL可能需要调整为用户自己的OLLAMA地址，如localhost）：
虽然视觉大模型会损失绝大多数位置和字体的信息和文字块信息（它只会输出一段连续的文本），但是从准确性和语义理解方面都远超目前本地OCR和百度OCR的效果。希望将来能够增加一个支持类似于翻译源那样可以通过BaseURL、APIkey、Timeout、Prompt等属性来配置自己视觉大模型服务的方式。
Activity
C4a15Wh commentedon Dec 6, 2025
你好！您提到的VLM-OCR接口支持目前在功能排期列表中，不过优先级相对较低。
我们此前测试过如QwenVL系列、PaddleOCR-VL和DeepSeek-OCR在OCR场景下的识别能力，最后发现它们在复杂文本识别场景（如 漫画翻译）并没有表现出比传统方案更优的效果，同时输出复杂信息结构的能力并不稳定（尽管我们进行了微调），故最后对VLM执行复杂场景OCR的尝试仅停留在内部验证。
而在简单文本场景，DS-OCR的识别率确实相对更高，但性能、时间开销是不可忽视的问题，您用于测试的图片分辨率并不高，但随着图像分辨率和文本数量的增加，VLM实现的OCR会遇到较严重的性能瓶颈。而在分辨率较小、文本较少的情况下，它们的表现差距并没有大到无法接受。在实时翻译场景，显然我们需要在时间和质量间做一个取舍。此外VLM-OCR也有个缺陷，即它无法输出文本坐标/输出的不可靠，这会导致部分依赖坐标计算的功能不可用。所以最后使用VLM进行实时OCR的方案可能难以被直接支持。
C4a15Wh commentedon Dec 6, 2025
可以详细说明一下哪些场景会需要使用VLM-OCR代替传统OCR吗？我们希望了解
Tsqurt commentedon Dec 7, 2025
感谢您对各种翻译场景的详细说明！显然漫画翻译等场景目前的大模型技术还难以胜任。
接下来让我们仅就简单文本场景下进行讨论，我认为我们在视觉大模型的优势（例如识别率相对更高）上面以及问题（性能、时间开销）方面达成了部分的共识。目前PaddleOCR的识别准确率仍然有待提升，有个别字符会错误识别，例如“ご飯”经常被识别为"三飯"，进而导致翻译质量严重收到影响。提出此issue只是希望将这种取舍权交给用户。
另一方面也有隐私安全方面的考量，我觉得用户对于在线OCR的顾虑也应当被合理考虑。您的在线OCR的效果十分惊艳；百度OCR也是用户的一种选择。但是有时候出于个人隐私等因素，用户可能不希望将他的截图区域交给别人，而是希望付出更多硬件成本和技术成本来使得翻译服务本地化。
我理解您对于此功能在工期上的考虑：具备自行搭建VLM-OCR等替代方案的用户在总体用户比例中是少数，例如DeepSeek-OCR需要提供一张12G以上显存的显卡；然而，对于这些用户来说，进行这样的尝试的门槛并不算太高（毕竟python+flask的代码可以通过大模型去编写）。哪怕是极少数用户做出了这些尝试，这些尝试的经验也将是十分有价值的。我相信增加一个类似于百度OCR的通用API接口并非难事；或者最简单地——允许配置百度OCR的通信协议（HTTP/HTTPS）和地址（BASE_URL）。
对于您能够制作并分享本软件表示感谢！软件开发的成本不容忽视，我曾想为您提供一个对应功能的PR，但是由于本仓库并没有最新版本的代码，遂作罢。
PantsuDango commentedon Dec 7, 2025
采纳，后面更新会加上大模型ocr