OCR cross-platform scheduling method and device based on deep learning and storage medium

Abstract

The invention belongs to the technical field of image recognition, and discloses an OCR cross-platform scheduling method and device based on deep learning and a storage medium, and the method comprises the steps: constructing a calling interface of a Go language application and a C + + OCR engine through a CGO bridging technology, and achieving cross-platform dynamic library adaptation and executable program compiling through Go construction labels; an engine pool is managed through a channel mechanism, and concurrent processing of OCR recognition tasks is achieved; calling a first OCR engine to generate a first recognition result containing confidence, and calling the multi-modal visual language model as a second OCR engine to generate a structured second recognition result when a triggering condition is met; and performing comparison verification on the field value of the second recognition result based on the original full text extracted by the first OCR engine, and selecting a fusion strategy according to a verification result to output a final recognition result. According to the invention, cross-platform deployment, high-concurrency processing and high-precision identification are realized, and the practicability and reliability of OCR application are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of image recognition, in particular to an OCR cross-platform scheduling method and device based on deep learning and a storage medium. BACKGROUND

[0002] As a core application in the field of image recognition, OCR (Optical Character Recognition) technology has a wide range of needs in scenarios such as invoice processing and document digitization. In particular, OCR solutions based on deep learning, such as Baidu PaddleOCR, have become the mainstream choice due to their high-precision text detection and recognition capabilities. However, existing deep learning OCR technologies rely heavily on the Python language ecosystem, which has many limitations in practical applications.

[0003] Firstly, deployment and distribution are difficult. OCR solutions in the Python environment require the installation of Python runtime, deep learning frameworks, and a large number of dependent packages, which is complex and difficult for ordinary users to adapt. At the same time, the packaged runtime environment is large in size, usually exceeding 500MB, which is not conducive to rapid deployment and distribution. Secondly, concurrent processing capability is limited. Python's Global Interpreter Lock (GIL) prevents true multi-threaded concurrency, resulting in performance bottlenecks in batch OCR recognition scenarios. Thirdly, there is insufficient cross-platform compatibility. The Python environment configurations for different operating systems (macOS, Windows, Linux) differ significantly, which can lead to compatibility issues and increase the technical threshold for cross-platform application development.

[0004] In addition, existing Go language OCR solutions are mostly wrappers for traditional engines such as Tesseract, with much lower recognition accuracy than deep learning models. While cloud OCR API is easy to deploy, it poses data security risks and network dependency issues. Single OCR engines have high misrecognition rates when dealing with difficult samples such as blurred, skewed, and low-contrast images, and lack effective result verification and error correction mechanisms. Multi-modal visual language models have strong structured information extraction capabilities, but they also have the risk of "hallucination" output, generating text information that does not exist in the generated image, which affects the reliability of the recognition results. These problems collectively restrict the application and promotion of OCR technology in cross-platform, high-concurrency, and high-precision scenarios. SUMMARY

[0005] The present application aims to provide an OCR cross-platform scheduling method and device based on deep learning and a storage medium to solve the problems raised in the background art.

[0006] According to one aspect of the present application, an OCR cross-platform scheduling method based on deep learning is provided, comprising the following steps: By CGO bridging technology, an calling interface between the Go language application and the C++ based OCR engine is constructed, the calling interface including a handle for managing the OCR engine life cycle; According to the target operating system, a dynamic library configuration corresponding to the label loading is built by Go, and a cross-platform executable program is compiled and generated; An engine pool is created in the Go language application, and a plurality of OCR engine handles are managed through a channel mechanism to process input OCR recognition tasks in a concurrent manner; A first OCR engine is called to process an input image to generate a first recognition result and a confidence level thereof; the first OCR engine is allocated by the engine pool; A multi-modal visual language model is configured as a second OCR engine; when the confidence level is lower than a dynamic threshold or a fuse of the second OCR engine is in a closed state, the second OCR engine is called to process the same input image to generate a second recognition result containing structured fields; The original full-text text of the input image extracted by the first OCR engine is obtained, and each field value of the second recognition result is compared and verified with the original full-text text to obtain a field verification result; According to the field verification result, a corresponding fusion strategy is selected to fuse the first recognition result and the second recognition result, and an final recognition result is output.

[0007] Preferably, the engine pool pre-creates a fixed number of OCR engine handles and places them in a buffer channel; when an OCR recognition task needs to be processed, a handle is obtained from the buffer channel; after the task is processed, the handle is returned to the buffer channel.

[0008] Preferably, the engine pool is managed based on a concurrent safe data structure, and engine instance identifiers are stored in the form of a queue or a channel, so that a plurality of recognition requests can be executed in parallel through different engine instance identifiers.

[0009] Preferably, the comparison and verification specifically includes: invoice number field verification: searching for an invoice number string in the second recognition result in the original full-text text; date field verification: converting a date value in the second recognition result into at least two predetermined format date strings, and searching in the original full-text text in turn; and amount field verification: searching for an amount numerical value string in the second recognition result in the original full-text text.

[0010] Preferably, the fusion strategy comprises: when all fields are verified, adopting a full consensus strategy, taking the second recognition result as the final recognition result; when part of the fields are verified, adopting a partial consensus strategy, taking the value of the second recognition result for the verified fields, and taking the value of the first recognition result or the second recognition result determined according to a predetermined rule for the unverified fields; when no field is verified, adopting a weighted fusion strategy, taking the first recognition result as the final recognition result.

[0011] Preferably, the fuse has three states of closed, open and half-open; the fuse records the number of consecutive failed calls of the second OCR engine, and when the number of failed calls reaches a first threshold, the state changes from closed to open; after the open state lasts for a preset time length, the state changes to half-open; in the half-open state, if the call is successful, the state returns to closed, otherwise the state returns to open.

[0012] Preferably, the second OCR engine is called in the following manner: a request conforming to the API specification of the multimodal visual language model is constructed, and the request contains the input image encoded by Base64 and a predefined structured output prompt word.

[0013] Another aspect of the present application also provides an OCR cross-platform scheduling device based on deep learning, comprising: A calling interface construction module is configured to construct a calling interface between a Go language application and a C++ based OCR engine through a CGO bridging technology, wherein the calling interface comprises a handle for managing the life cycle of the OCR engine; A dynamic library configuration module is configured to load a corresponding dynamic library configuration according to a target operating system by using a Go build tag, and compile a cross-platform executable program; An engine pool creation module is configured to create an engine pool in the Go language application, manage multiple OCR engine handles through a channel mechanism, and process input OCR recognition tasks in a concurrent manner; A first recognition processing module is configured to call a first OCR engine to process an input image and generate a first recognition result and a confidence level thereof; the first OCR engine is allocated by the engine pool; A second recognition processing module is configured to configure a multimodal visual language model as a second OCR engine; when the confidence level is lower than a dynamic threshold or a fuse of the second OCR engine is in a closed state, the second OCR engine is called to process the same input image and generate a second recognition result containing structured fields; A field verification module is configured to obtain an original full-text text of an input image extracted by the first OCR engine, compare and verify each field value of the second recognition result with the original full-text text, and obtain a field verification result. The result fusion module is used to select the corresponding fusion strategy based on the field verification result to fuse the first recognition result and the second recognition result, and output the final recognition result.

[0014] This application also provides a computer device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the deep learning-based OCR cross-platform scheduling method as described above.

[0015] In another aspect, this application provides a computer-readable storage medium having stored thereon computer program instructions that can be executed by a processor to implement the deep learning-based cross-platform OCR scheduling method described above.

[0016] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the deep learning-based cross-platform OCR scheduling method described above.

[0017] This application achieves seamless integration between Go applications and C OCR engines by defining a C language interface layer and CGO bridging technology, resolving interaction issues between different language ecosystems. Through cross-platform compilation rule configuration, it enables a single codebase to adapt to multiple operating systems, reducing deployment complexity. A channel-based engine pool enables efficient reuse and concurrent management of the OCR engine, enhancing the system's concurrent processing capabilities. By configuring a multimodal visual language model as the primary recognition engine, combined with dynamic confidence thresholds and circuit breaker mechanisms, it achieves intelligent scheduling of recognition tasks. Structured field comparison verification and multi-strategy result fusion effectively filter out false recognition results, improving the accuracy and reliability of the recognition results. Load monitoring and a primary recognition engine skipping mechanism ensure system stability under high load or primary recognition engine malfunctions. The entire methodology is complete and logically rigorous, fully meeting the needs of cross-platform, high-concurrency, and high-precision OCR recognition, providing an efficient and reliable technical solution for various OCR application scenarios. Attached Figure Description

[0018] Figure 1 A schematic diagram of a deep learning-based OCR cross-platform scheduling method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the image processing flow of the OCR engine provided in the embodiments of this disclosure; Figure 3This is a schematic diagram of the structure of a multimodal visual language model provided in an embodiment of the present disclosure; Figure 4 A schematic diagram of a cross-platform OCR scheduling device based on deep learning provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] It should be noted that all user information (including but not limited to user device information, user personal information, object information corresponding to device usage data, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, device usage data, etc.) involved in all embodiments of this disclosure are information and data authorized by the user or fully authorized by all parties.

[0021] This method is suitable for scenarios requiring high-precision OCR recognition on multiple operating system platforms (including macOS, Windows, and Linux), especially for extracting structured information such as invoices and documents. It supports batch concurrent image recognition and processing, and is compatible with various image types, including clear images, blurry images, low-contrast images, tilted and distorted images, and images with complex backgrounds. Implementing this method typically requires the following conditions: a Go language compilation and runtime environment, configuration of platform-specific dynamic link libraries for the target operating system, preparation of deep learning model files (text detection, text recognition, orientation classification, etc.) and character dictionary files, deployment of a visual language model or its API service that supports multimodal input, and ensuring that hardware resources can meet the requirements of multi-engine concurrent operation and model inference.

[0022] The implementation process of the deep learning-based cross-platform OCR scheduling method of the present invention will be described in detail below with reference to specific embodiments. It should be noted that this embodiment is only for explaining the present invention and is not intended to limit the scope of protection of the present invention. Conventional adjustments or substitutions made by those skilled in the art to each step without departing from the concept of the present invention should be included within the scope of protection of the present invention.

[0023] like Figure 1 As shown in the diagram, this invention discloses a cross-platform OCR scheduling method based on deep learning, including the following steps: S1. Using CGO bridging technology, a calling interface is built between the Go language application and the C++-based OCR engine. The calling interface includes a handle for managing the lifecycle of the OCR engine. S2. Based on the target operating system, use Go to build tags to load the corresponding dynamic library configurations and compile to generate a cross-platform executable program. S3. Create an engine pool in the Go language application, and manage multiple OCR engine handles through a channel mechanism to process the input OCR recognition tasks concurrently. S4. The first OCR engine is invoked to process the input image and generate a first recognition result and its confidence level; the first OCR engine is allocated through the engine pool. S5. Configure a multimodal visual language model as a second OCR engine; when the confidence level is lower than the dynamic threshold, or the circuit breaker of the second OCR engine is closed, call the second OCR engine to process the same input image and generate a second recognition result containing structured fields. S6. Obtain the original full-text of the input image extracted by the first OCR engine, and compare and verify the field values ​​of the second recognition result with the original full-text to obtain the field verification result. S7. Based on the field verification results, select the corresponding fusion strategy to fuse the first recognition result and the second recognition result, and output the final recognition result.

[0024] In some embodiments, for step S1, a calling interface between a Go application and a C++-based OCR engine is constructed using CGO bridging technology. The calling interface includes a handle for managing the lifecycle of the OCR engine.

[0025] Specifically, according to the embodiments of this disclosure, a C language interface layer is first defined. This interface layer serves as an interaction bridge between the Go language application and the OCR engine, realizing full lifecycle management of the OCR engine's initialization, invocation, result acquisition, and resource release. The C language interface layer includes an engine initialization interface, an image recognition interface, a result acquisition interface, and a resource release interface. Each interface adopts a unified function naming convention and parameter passing format to ensure the consistency and standardization of interface calls.

[0026] The engine initialization interface creates an OCR engine object and returns a corresponding object handle. This handle is a pointer to the OCR engine object and serves as a unique identifier for all subsequent interface calls. The input parameters for the engine initialization interface include the paths to the text detection model file, text recognition model file, orientation classification model file, character dictionary file, and the number of inference threads. The text detection model file is used to locate text regions from the input image; the text recognition model file is used to recognize characters within the detected text regions; the orientation classification model file is used to determine and correct the tilt direction of the text; the character dictionary file provides the set of characters required for recognition; and the number of inference threads configures the number of parallel inference threads for the OCR engine, for example, it can be configured to 4 inference threads to balance inference speed and resource consumption.

[0027] The image recognition interface receives image data or image paths and invokes the OCR engine to perform recognition processing. The input parameters of this interface include the OCR engine object handle, image data or image path, and recognition parameter configuration. These parameters include image edge fill value, maximum image side length, text box confidence threshold, text box binarization threshold, text box expansion ratio, whether to perform orientation detection, and whether to perform angle detection. Optionally, the image edge fill value can be set to 50, the maximum image side length can be set to 1024, and the text box confidence threshold can be set to 0.6. The output parameter of the image recognition interface is a recognition success flag, indicating whether the recognition process was completed normally.

[0028] The result acquisition interface is used to retrieve the recognition result and corresponding confidence information from the OCR engine after the recognition process is completed. The input parameters of this interface are the OCR engine object handle and the result buffer. The output parameters include the text content of the recognition result, the text box coordinates, and the confidence information. The confidence information is the OCR engine's assessment of the credibility of the recognition result, with a value ranging from 0 to 1. It is calculated by weighting the text detection confidence and the text recognition confidence. For example, if the text detection confidence weight is 0.3 and the text recognition confidence weight is 0.7, the final confidence = text detection confidence × 0.3 + text recognition confidence × 0.7.

[0029] The resource release interface is used to destroy the OCR engine object, releasing the memory and computing resources it occupies. The input parameter of this interface is a handle to the OCR engine object. After the call, the OCR engine object will be destroyed, and the corresponding handle will no longer be valid, thus preventing resource leaks.

[0030] The creation of the OCR engine object handle is achieved by calling the engine initialization interface. During the call, the OCR engine loads the specified model file, initializes the inference environment, and allocates the required memory resources. If the model file is loaded successfully and initialization is completed, a valid OCR engine object handle is returned. If the model file fails to load or an exception occurs during initialization, an empty handle is returned, indicating that initialization failed.

[0031] In one embodiment, CGO bridging technology exposes the C language interface layer to the Go language, enabling data type conversion and function calls between the Go application and the OCR engine object handles. CGO is a technology provided by Go for interaction with C, allowing C code to be embedded in Go code and facilitating data transfer and function calls between the two languages.

[0032] Specifically, in Go code, header files for the C language interface layer are imported by importing C packages. These header files contain function declarations, data type definitions, and macro definitions for the C language interface layer. When importing header files, the CGO comment can be used to specify the header file path and compilation parameters, ensuring that the compiler can correctly find the header file and compile it.

[0033] Data type conversion is the core of the CGO bridge, enabling bidirectional conversion between Go and C data types. For basic data types, such as Go's `int` and C's `C.int`, or Go's `float64` and C's `C.float`, direct type casting is possible. For string types, Go's `string` needs to be converted to C's `char*`. During the conversion, C's string memory is allocated using the `C.CString` function, and memory is released using the `C.free` function after use to avoid memory leaks. For struct types, a struct type corresponding to the C interface parameter struct needs to be defined in Go, ensuring that the field order, data type, and field length are completely consistent to achieve complete data transfer of the struct.

[0034] In terms of function calls, Go applications directly call functions in the C language interface layer through C language function prototypes declared in CGO comments. For example, when calling the engine initialization interface, Go uses the C.OcrInit function to call the corresponding C language function, passing in the converted C language data type parameter, obtaining the returned OCR engine object handle, and converting it to the uintptr type in Go for storage and management.

[0035] To ensure the safety of data type conversion and function calls, data validity checks must be performed during the conversion process, such as checking whether strings are empty or whether structure fields meet the requirements. After a function call, the return value must be checked to determine whether the function call was successful. If the call fails, error handling should be performed in a timely manner to avoid abnormal program crashes.

[0036] This solves the technical problem that Go applications cannot directly call OCR engines implemented in C. By establishing a communication bridge between Go and C through CGO bridging technology, it achieves technical integration between different language ecosystems, enabling Go applications to utilize mature C OCR engine technology while leveraging Go's advantages in concurrent processing and cross-platform compatibility.

[0037] In some embodiments, for step S2, the corresponding dynamic library configuration is loaded using the Go build tag according to the target operating system, and a cross-platform executable program is compiled.

[0038] Specifically, cross-platform compilation rules are configured, and for different target operating systems, Go build tags are used to load the corresponding platform-specific dynamic link library configurations to generate an executable program adapted to that target operating system. Go's build tags are a conditional compilation mechanism that can filter out the code files to be compiled based on specified tags, thereby achieving differentiated compilation for different platforms.

[0039] Platform-specific dynamic link library configurations are provided for the three major operating systems: macOS, Windows, and Linux. For macOS, .dylib format dynamic libraries are linked. This format is specific to macOS. By setting the rpath loading path, the search path for dynamic libraries is specified, ensuring that the program can accurately locate and load the dynamic libraries at runtime. The rpath loading path can be set to the program's directory or a relative path. For example, the -Wl,-rpath,. / lib parameter sets the dynamic library search path to the lib folder under the program's directory.

[0040] For the Windows platform, linking .dll format dynamic libraries (DLLs) is done using the `SetDllDirectoryA` function, a Windows-specific DLL format. The `SetDllDirectoryA` function is a Windows API function that modifies the current process's DLL search path, adding the DLL's directory to the search path to ensure correct loading. In Go code, C code is embedded using CGO to call the `SetDllDirectoryA` function, setting the DLL search path during program initialization.

[0041] For Linux platforms, linking .so format dynamic libraries is a Linux-specific dynamic library format. The search path for dynamic libraries is specified by setting the rpath loading path, for example, using the -Wl, -rpath, . / lib parameters to ensure the program can find the dynamic library file at runtime.

[0042] In Go code, platform-specific configuration files are created for different operating systems. Each configuration file specifies the corresponding operating system using the ` / / go:build` tag. For example, the configuration file for macOS uses the ` / / go:builddarwin` tag, the configuration file for Windows uses the ` / / go:buildwindows` tag, and the configuration file for Linux uses the ` / / go:buildlinux` tag. Each configuration file uses CGO comments to configure the corresponding dynamic library linking parameters, including the dynamic library path and linking options.

[0043] During compilation, the target operating system is specified by setting the GOOS environment variable. The Go compiler automatically selects the corresponding platform-specific configuration file, loads the appropriate dynamic library linking parameters, and compiles an executable program adapted to the target operating system based on the value of the GOOS environment variable and the build tags. For example, when compiling an executable program for macOS, setting GOOS=darwin causes the compiler to load the macOS platform configuration file, link the .dylib dynamic library, and generate an executable program suitable for macOS; when compiling an executable program for Windows, setting GOOS=windows causes the compiler to load the Windows platform configuration file, link the .dll dynamic library, and generate an executable program suitable for Windows.

[0044] This solves the problems of poor cross-platform compatibility and complex deployment of traditional OCR technology. By building tags and configuring platform-specific dynamic libraries using Go, a single codebase can be adapted to multiple operating systems. This eliminates the need to develop and maintain separate code for different platforms, reducing development costs and deployment difficulty, and improving the versatility and ease of use of the technical solution.

[0045] In one embodiment, for step S3, an engine pool is created in the Go language application, and multiple OCR engine handles are managed through a channel mechanism to process the input OCR recognition task concurrently.

[0046] Specifically, in Go applications, a channel-based engine pool is created. This pool pre-allocates and manages multiple OCR engine object handles through blocking channels, receiving external OCR recognition tasks. The core function of the engine pool is to reuse OCR engine object handles, avoiding the performance overhead caused by frequently creating and destroying OCR engines, while also supporting concurrent processing of multiple tasks, thus improving system processing efficiency.

[0047] The creation process of the engine pool includes initializing the buffer channel, pre-creating OCR engine object handles, and setting engine pool parameters. The buffer channel has a capacity of N, where N is the number of OCR engine object handles that the engine pool can manage. This capacity can be configured according to the concurrency requirements of the actual application scenario and the availability of hardware resources; for example, it can be configured to 8. The buffer channel is created using the `make` function in Go and is of type `chanuintptr`, used to store OCR engine object handles.

[0048] During the pre-creation of OCR engine object handles, based on the buffer channel capacity N, the engine initialization interface is called cyclically to create N OCR engine object handles. If creation is successful, the handle is stored in the buffer channel; if creation fails, the created OCR engine object handles are destroyed, the buffer channel is closed, and a creation failure message is returned to the engine pool. This pre-creation mechanism ensures that the engine pool has usable OCR engine object handles upon startup, enabling rapid response to external OCR recognition tasks.

[0049] Engine pool parameters include load threshold and idle timeout. The load threshold is used to determine the current load status of the engine pool. For example, it can be configured to 0.8. When the current load rate of the engine pool exceeds the load threshold, it indicates that the system is under high load. The idle timeout is used to reclaim OCR engine object handles that have been idle for a long time to avoid resource waste. For example, it can be configured to 300 seconds. When the idle time of an OCR engine object handle exceeds this value, it is destroyed and a new handle is created and stored in the buffer channel.

[0050] The management operations of the engine pool include acquiring, returning, and validating OCR engine object handles. When an external OCR recognition task is received, an idle OCR engine object handle is acquired from the buffer channel. The acquisition operation is implemented using the <-channel statement. If there is an available handle in the buffer channel, the handle is returned directly; if the buffer channel is empty, the acquisition operation is blocked and waits until a handle is returned to the buffer channel.

[0051] After the recognition task is completed, the OCR engine object handle is returned to the buffer channel. This return operation is implemented using the `channel<-` statement, storing the handle back into the buffer channel for subsequent recognition tasks. During the return process, the validity check module performs a status check on the OCR engine object corresponding to the handle, verifying whether the OCR engine is running normally and whether there are any resource leaks. If the handle is valid, it is returned normally; if the handle is invalid, the corresponding OCR engine object is destroyed, and a new OCR engine object handle is created and stored in the buffer channel, ensuring that handles in the engine pool are always available.

[0052] In addition, the engine pool also includes a shutdown mechanism. When the engine pool is no longer in use, all resources are released through the shutdown operation. All OCR engine object handles in the buffer channel are traversed, the resource release interface is called to destroy the corresponding OCR engine object, and then the buffer channel is closed to avoid resource leaks.

[0053] This solves the problem of insufficient concurrent processing capability of a single OCR engine. By using a channel-based engine pool, it achieves efficient reuse and concurrent management of OCR engine object handles. The blocking channel ensures thread safety, and the pre-creation mechanism reduces the time overhead of engine initialization, thereby improving the system's concurrent processing capability and response speed.

[0054] In some embodiments, for step S4, a first OCR engine is invoked to process the input image and generate a first recognition result and its confidence level; the first OCR engine is allocated through the engine pool.

[0055] Specifically, please refer to Figure 2 , Figure 2 This is a schematic diagram of the image processing flow of the OCR engine provided in this embodiment. In S201, in response to receiving an OCR recognition task, the task is parsed, and information such as image data, image paths, and recognition parameters are extracted. The source of the recognition task can be a local file, a network request, or a call from another application, and the image data format includes common formats such as JPG, PNG, and PDF.

[0056] In S202, an idle OCR engine object handle is obtained from the engine pool, and the corresponding OCR engine is called through the C language interface layer to perform image recognition processing. First, the image recognition interface is called to pass image data or image path, recognition parameters, and other information to the OCR engine. The OCR engine performs recognition processing according to a preset process: first, the text region in the image is located using a text detection model, and the coordinate information and confidence score of the text box are output; then, the text image block is cropped according to the text box coordinate information, and the tilt direction of the text image block is determined and corrected using an orientation classification model; finally, the corrected text image block is used to recognize characters using a text recognition model, and the text content is output.

[0057] In S203, after the recognition process is completed, the result acquisition interface is called to obtain the first recognition result and the corresponding confidence information. The first recognition result includes the recognized text content, text box coordinate information, and corresponding field information such as invoice number, invoice date, and amount; the confidence information reflects the credibility of the first recognition result and provides a basis for subsequent scheduling decisions.

[0058] In step S204, after recognition is complete, the OCR engine object handle is returned to the engine pool for subsequent recognition tasks to use. This return operation is implemented through the engine pool's return mechanism, ensuring the handle can be reused and improving the engine pool's resource utilization. If an anomaly occurs during recognition, such as OCR engine execution failure or result acquisition failure, the handle is also returned to the engine pool, and the anomaly information is recorded for subsequent troubleshooting.

[0059] In one embodiment, to improve the processing efficiency of recognition tasks and support batch recognition task processing, multiple OCR recognition tasks are placed in a task queue. Multiple OCR engine object handles in the engine pool process the recognition tasks in the task queue in parallel. The concurrent scheduling of tasks is achieved through the coroutine mechanism of the Go language. Each coroutine is responsible for processing one recognition task, obtaining a handle from the engine pool, performing recognition processing, and returning the handle, thereby achieving efficient processing of batch tasks.

[0060] In one embodiment, for step S5, a multimodal visual language model is configured as a second OCR engine; when the confidence level is lower than the dynamic threshold, or the circuit breaker of the second OCR engine is closed, the second OCR engine is invoked to process the same input image and generate a second recognition result containing structured fields.

[0061] Specifically, a multimodal visual language model is configured as the main recognition engine. The multimodal visual language model is an artificial intelligence model that can process image and text information simultaneously. It has powerful visual understanding and semantic reasoning capabilities and can extract structured information from images and output it in natural language or structured format.

[0062] In one embodiment, see Figure 3 , Figure 3 This is a schematic diagram of the multimodal visual language model structure provided in this embodiment. The specific structure of the multimodal visual language model includes an image encoding module, a text encoding module, a cross-modal fusion module, and an output decoding module. The image encoding module adopts a visual Transformer (ViT) architecture, which segments the input image into fixed-size image blocks, converts them into image embedding vectors through an embedding layer, and then extracts high-level features of the image through multiple Transformer encoders. The text encoding module uses a Transformer encoder to encode the input prompt text and generate text embedding vectors. The cross-modal fusion module uses a cross-attention mechanism to achieve deep fusion of image embedding vectors and text embedding vectors, capturing the correlation information between the image and the text. The output decoding module uses a Transformer decoder to decode the fused feature vectors and generate structured recognition results.

[0063] The training process of a multimodal visual language model includes two stages: pre-training and fine-tuning. The pre-training stage uses a large-scale image-text pairing dataset and trains the model through self-supervised learning, enabling it to learn the basic features of images and text and cross-modal relationships. The fine-tuning stage uses domain-specific datasets (such as invoice and document datasets) to fine-tune the pre-trained model, optimizing its ability to extract structured information in specific scenarios and improving recognition accuracy. During fine-tuning, the cross-entropy loss function is used to calculate the error between the model's predictions and the true labels, and the model parameters are updated using the gradient descent algorithm until the model converges.

[0064] The scheduling trigger conditions for the main recognition engine include two: first, the confidence level of the first recognition result generated in step S5 is lower than the dynamically calculated first confidence level threshold; second, the fuse of the main recognition engine is in a closed state.

[0065] The formula for calculating the first confidence threshold in dynamic calculation is as follows:

[0066] Where FirstConfidenceThreshold represents the first confidence threshold, BaseThreshold represents the base threshold, LoadFactor represents the load factor, and AdjustmentFactor represents the adjustment factor.

[0067] The base threshold is a preset fixed value that can be configured according to the recognition accuracy requirements of the actual application scenario. For example, it can be configured to 0.7. The setting of the base threshold needs to balance recognition accuracy and system overhead. If the base threshold is too high, too many recognition tasks will trigger the main recognition engine, increasing the system load; if the base threshold is too low, low-confidence erroneous results may not be corrected.

[0068] The load factor is determined based on the current system's computing resource utilization, which includes CPU utilization, memory utilization, and GPU utilization. The load factor ranges from 0 to 1; the higher the system's computing resource utilization, the larger the load factor. For example, if the CPU utilization is 70% and the memory utilization is 60%, then the load factor can be calculated as (70% + 60%) / 2 = 65% = 0.65.

[0069] The adjustment coefficient is a preset fixed value used to adjust the degree of influence of the load factor on the first confidence threshold. For example, it can be configured to 0.5. The larger the adjustment coefficient, the more significant the influence of the load factor on the first confidence threshold. Under high load, the first confidence threshold will decrease more, thereby reducing the number of calls to the main recognition engine and reducing the system load.

[0070] The calculation process of the first confidence threshold is executed in real time. After obtaining the confidence of the first recognition result each time, the corresponding threshold is dynamically calculated based on the current system computing resource utilization rate to achieve adaptive adjustment of the threshold.

[0071] The main recognition engine's circuit breaker is used to monitor its operational status, which includes three states: closed, open, and half-open. The circuit breaker accumulates the number of consecutive failed calls to the main recognition engine. When the number of consecutive failed calls reaches a preset failure threshold, the circuit breaker changes from closed to open. After remaining in the open state for a preset recovery time, the circuit breaker changes to half-open, allowing a single trial call. If the trial call is successful, the circuit breaker returns to closed; otherwise, it returns to open. The preset failure threshold can be configured, for example, to 5 calls, and the preset recovery time can be configured, for example, to 30 seconds. When the circuit breaker is in the closed state, it indicates that the main recognition engine is operating normally and can receive and process recognition tasks normally. When the circuit breaker is in the open state, it indicates that the main recognition engine has an anomaly and calls are temporarily suspended. When the circuit breaker is in the half-open state, a single trial call verifies whether the main recognition engine has recovered normally.

[0072] When any of the above scheduling trigger conditions are met, the image data for the OCR recognition task is submitted to the main recognition engine. The image data is submitted by Base64 encoding and converting it into a string format, which, together with predefined prompt text, constitutes a multimodal input message. The prompt text explicitly requires the main recognition engine to output structured recognition results, such as "Please analyze this invoice image, extract structured fields such as invoice number, invoice date, amount, and billing details, and return them in JSON format."

[0073] After receiving multimodal input messages, the main recognition engine extracts image features through the image encoding module and prompt word features through the text encoding module. These features are then fused by the cross-modal fusion module, and the output decoding module generates a second recognition result containing at least one structured field. The second recognition result is in JSON format, containing field names and corresponding field values, for example, {“invoice_number”:“12345678”,“invoice_date”:“20xx-01-15”,“amount”:“1234.56”}.

[0074] This solves the problem of insufficient recognition accuracy of a single OCR engine on difficult samples. By configuring a multimodal visual language model as the main recognition engine, its powerful visual understanding and semantic reasoning capabilities are utilized to perform secondary recognition on the first recognition result with low confidence, thereby improving the accuracy of structured information extraction. At the same time, a circuit breaker mechanism is used to monitor the operating status of the main recognition engine to ensure the stability and reliability of the system.

[0075] In some embodiments, for step S6, the original full-text text of the input image extracted by the first OCR engine is obtained, and the field values ​​of the second recognition result are compared and verified with the original full-text text to obtain the field verification result.

[0076] Specifically, the original text of the image extracted by the OCR engine in step S5 is obtained. The original text of the image is the text content obtained by the OCR engine through full-text recognition of the input image. It contains all recognizable text information in the image and has not undergone any field extraction or filtering processing.

[0077] The values ​​of each structured field in the second recognition result are compared and verified one by one with the original text of the image, and the verification pass rate is calculated. Verification pass rate = number of fields that pass verification / total number of structured fields × 100%, where the total number of structured fields is the number of structured fields contained in the second recognition result. For example, in the invoice recognition scenario, the total number of structured fields includes invoice number, invoice date, amount, billing items, etc., and is usually 3 to 5.

[0078] The one-by-one comparison and verification specifically includes invoice number verification, date verification, and amount verification. Corresponding verification methods are adopted according to the characteristics of different fields: Invoice number verification: Extract the pure digital sequence of the invoice number field from the second recognition result, remove any possible non-digital characters (such as spaces, hyphens, etc.), and obtain the standardized invoice number digital sequence. Search for this digital sequence in the original image text. If there is a substring in the original image text that is exactly the same as this digital sequence, it is determined that the invoice number field verification passes; otherwise, it is determined that the verification fails. For example, if the invoice number field value in the second recognition result is "1234-5678", the extracted pure digital sequence is "12345678". If the original image text contains "12345678", the verification passes.

[0079] Date verification: Convert the date field value in the second recognition result into at least two predefined date format strings. The predefined date formats include Chinese format (such as YYYY year MM month DD day), standard format (such as YYYY-MM-DD), compact format (such as YYYYMMDD), etc. Search for each format of the date string in the original image text in turn. If there is a match for any format of the date string in the original image text, it is determined that the date field verification passes; otherwise, it is determined that the verification fails. For example, if the date field value in the second recognition result is "2024-01-15", it is converted into two formats: "2024 year 01 month 15 day" and "20240115". If the original image text contains "2024 year 01 month 15 day", the verification passes.

[0080] Amount verification: Extract the numerical string of the amount field from the second recognition result, remove any possible non-numerical characters such as currency symbols (such as ¥, $), thousands separators (such as commas), etc., and obtain the standardized amount numerical string. Search for a substring containing this numerical string in the original image text. If it exists, it is determined that the amount field verification passes; otherwise, it is determined that the verification fails. For example, if the amount field value in the second recognition result is "¥1,234.56", the extracted numerical string is "1234.56". If the original image text contains "1234.56", the verification passes.

[0081] During the comparison and verification process, a string fuzzy matching algorithm is adopted, allowing for a small number of character differences or format differences between the field values in the original image text and those in the second recognition result. For example, the month or date in the date field may lack a leading zero, or the decimal point and comma in the amount field may be used interchangeably. The flexibility and accuracy of the verification are improved through a fault tolerance mechanism.

[0082] This solves the problem of "illusionary" output that may occur in multimodal visual language models. By comparing and verifying the structured fields of the second recognition result with the original text of the image extracted by the OCR engine, false information that does not exist in the image can be effectively detected from the output of the main recognition engine, ensuring the authenticity and reliability of the recognition results and providing a basis for subsequent result fusion.

[0083] In some embodiments, for step S7, based on the field verification result, a corresponding fusion strategy is selected to fuse the first recognition result and the second recognition result, and the final recognition result is output.

[0084] Specifically, based on the verification pass rate, one of several preset fusion strategies is selected to fuse the first and second identification results, outputting the final identification result. The preset fusion strategies include a full consensus strategy, a partial consensus strategy, and a weighted fusion strategy. Each strategy corresponds to a different range of verification pass rates, ensuring the accuracy and reasonableness of the fusion result.

[0085] The full consensus strategy is adopted when the verification pass rate is 100%, meaning that all structured fields in the second recognition result have passed verification in the original image text. This indicates that the second recognition result has been fully verified by the original image text, there are no "illusion" outputs, and it has extremely high reliability. The final recognition result directly adopts the second recognition result, and its confidence level is increased. The confidence level increase coefficient can be configured, for example, to 0.1. The increased confidence level = the confidence level of the second recognition result + 0.1. If the increased confidence level exceeds 1.0, it is calculated as 1.0.

[0086] A partial consensus strategy is adopted when the verification pass rate is greater than 0% but less than 100%, meaning that some structured fields in the second recognition result pass verification while others fail. In this case, the corresponding values ​​from the second recognition result are used for the fields that pass verification, as these fields have been verified through the original image text and have high credibility. For the fields that fail verification, one value is chosen from the corresponding values ​​from the first and second recognition results. The selection criteria include the format standardization of the field value and its confidence level. For example, if the confidence level of the field in the first recognition result is higher than that in the second recognition result, and the format conforms to preset standards, then the field value from the first recognition result is used; otherwise, the field value from the second recognition result is used. This partial consensus strategy achieves complementary advantages between the two recognition results, improving the overall credibility of the final recognition result.

[0087] The weighted fusion strategy is adopted when the verification pass rate is 0%, meaning that all structured fields in the second recognition result fail verification in the original image text. In this case, it is determined that the main recognition engine may be producing a "phantom" output. The final recognition result prioritizes the first recognition result, but its confidence level is reduced. The confidence reduction coefficient can be configured, for example, to 0.9, and the reduced confidence level = the confidence level of the first recognition result × 0.9. If the confidence level of the first recognition result is low, the corresponding values ​​of the second recognition result can be used for some fields, taking into account factors such as field format standardization, but the confidence level of those fields must be marked as low.

[0088] During the fusion process, the field formats of the final identification results also need to be standardized to ensure that the field values ​​conform to preset requirements. For example, date fields should be uniformly formatted as YYYY-MM-DD, and amount fields should be uniformly retained to two decimal places. Simultaneously, the fusion strategy used during the fusion process, the source of each field, and confidence level information should be recorded to support subsequent result traceability and quality assessment.

[0089] The output format of the final recognition result can be configured according to actual needs, including JSON format, XML format, text format, etc. The output content includes the name of the structured field, field value, confidence information and fusion strategy identifier, etc., which facilitates subsequent application parsing and processing.

[0090] This solves the problem of insufficient reliability of a single recognition result. By dynamically selecting a fusion strategy based on the verification pass rate, the intelligent fusion of the first and second recognition results is achieved, giving full play to the advantages of the two recognition engines, effectively filtering false information, and improving the accuracy and reliability of the final recognition result.

[0091] In one embodiment, a load monitoring and main recognition engine skipping mechanism is also included. Specifically, the load monitoring step is used to periodically sample and calculate the current load rate of the engine pool. The sampling period for load monitoring can be configured, for example, to be 10 seconds, to obtain the operating status information of the engine pool through periodic sampling. The current load rate of the engine pool = (engine pool capacity - number of available OCR engine object handles in the buffer channel) / engine pool capacity × 100%. For example, if the engine pool capacity is 8 and the number of available handles in the buffer channel is 2, then the current load rate = (8-2) / 8 × 100% = 75%.

[0092] When the fuse is in an open or partially open state, or when the current load rate exceeds a preset load threshold, the main identification engine is skipped, and the process proceeds directly to step S8, outputting the first identification result as the final identification result. The preset load threshold can be configured, for example, to 80%. When the current load rate exceeds this threshold, it indicates that the system is under high load. Calling the main identification engine at this time would further increase the system burden, potentially leading to slower system response or abnormalities. Therefore, the main identification engine is skipped, and the first identification result is used directly as the final identification result to ensure system stability and response speed.

[0093] When the fuse is in the open state, it indicates that the main identification engine has experienced consecutive failures and is temporarily unable to provide normal service, so the main identification engine is skipped. When the fuse is in the half-open state, only a single trial call is allowed. If the current load rate is high or other conditions do not permit, the main identification engine can also be skipped, and the call can be made after the fuse state is restored to closed.

[0094] When skipping the main identification engine, the reason for skipping and the corresponding system status information, such as load rate and circuit breaker status, need to be recorded so that the system operation can be analyzed and the scheduling strategy can be optimized.

[0095] Therefore, this method achieves seamless integration between Go applications and C OCR engines by defining a C language interface layer and CGO bridging technology, resolving interaction issues between different language ecosystems. Through cross-platform compilation rule configuration, it enables a single codebase to adapt to multiple operating systems, reducing deployment complexity. A channel-based engine pool enables efficient reuse and concurrent management of the OCR engine, enhancing the system's concurrent processing capabilities. By configuring a multimodal visual language model as the main recognition engine and combining it with dynamic confidence thresholds and circuit breaker mechanisms, it achieves intelligent scheduling of recognition tasks. Structured field comparison verification and multi-strategy result fusion effectively filter out false recognition results, improving the accuracy and reliability of the recognition results. Load monitoring and a main recognition engine skipping mechanism ensure system stability under high load or main recognition engine malfunctions. The entire method is complete and logically rigorous, fully meeting the needs of cross-platform, high-concurrency, and high-precision OCR recognition, providing an efficient and reliable technical solution for various OCR application scenarios.

[0096] Please see Figure 4 , Figure 4 This invention provides a deep learning-based cross-platform OCR scheduling device 400. This device embodiment is related to... Figure 1 Corresponding to the illustrated method embodiment, this device can be specifically applied to various computer devices. The device specifically includes: The call interface construction module 401 is used to build a call interface between a Go language application and a C++-based OCR engine through CGO bridging technology. The call interface includes a handle for managing the lifecycle of the OCR engine. The dynamic library configuration module 402 is used to load the corresponding dynamic library configuration based on the target operating system using Go build tags, and compile it into a cross-platform executable program. Engine pool creation module 403 is used to create engine pools in Go language applications, and manage multiple OCR engine handles through a channel mechanism to process input OCR recognition tasks concurrently. The first recognition processing module 404 is used to call the first OCR engine to process the input image and generate a first recognition result and its confidence level; the first OCR engine is allocated through the engine pool. The second recognition processing module 405 is used to configure a multimodal visual language model as a second OCR engine; when the confidence level is lower than the dynamic threshold, or when the circuit breaker of the second OCR engine is closed, the second OCR engine is invoked to process the same input image and generate a second recognition result containing structured fields. The field verification module 406 is used to obtain the original full-text text of the input image extracted by the first OCR engine, compare and verify the field values ​​of the second recognition result with the original full-text text, and obtain the field verification result. The result fusion module 407 is used to select a corresponding fusion strategy to fuse the first recognition result and the second recognition result based on the field verification result, and output the final recognition result.

[0097] Based on the same inventive concept, this application also provides a computer device, the method corresponding to which can be the method in the foregoing embodiments, and the principle of solving the problem is similar to that method. The computer device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0098] The computer device can be a user device, or a device formed by integrating user devices and network devices through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and smart bands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0099] Figure 5 The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 502 or a program loaded from a storage portion 508 into a random access memory (RAM) 503. The RAM 503 also stores various programs and data required for system operation. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0100] The following components are connected to I / O interface 505: input section 506 including keyboard, mouse, touch screen, microphone, infrared sensor, etc.; output section 507 including cathode ray tube (CRT), liquid crystal display (LCD), LED display, OLED display, etc., and speakers, etc.; storage section 508 including one or more computer-readable media such as hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and communication section 509 including network interface card such as LAN (local area network) card, modem, etc. Communication section 509 performs communication processing via a network such as the Internet.

[0101] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 501, it performs the functions defined in the methods of this application.

[0102] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0103] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0104] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

Claims

1. A cross-platform OCR scheduling method based on deep learning, characterized in that, Includes the following steps: By using CGO bridging technology, a calling interface is built between Go language applications and C++-based OCR engines. The calling interface includes a handle for managing the lifecycle of the OCR engine. Based on the target operating system, use Go build tags to load the corresponding dynamic library configurations and compile to generate a cross-platform executable program; In a Go application, an engine pool is created, and multiple OCR engine handles are managed through a channel mechanism to process input OCR recognition tasks concurrently. The first OCR engine is invoked to process the input image, generating the first recognition result and its confidence level; The first OCR engine is allocated through the engine pool; Configure a multimodal visual language model as a second OCR engine; when the confidence level is lower than the dynamic threshold, or when the circuit breaker of the second OCR engine is closed, call the second OCR engine to process the same input image and generate a second recognition result containing structured fields; Obtain the original full-text of the input image extracted by the first OCR engine, and compare and verify the field values ​​of the second recognition result with the original full-text to obtain the field verification result; Based on the field verification results, the corresponding fusion strategy is selected to fuse the first recognition result and the second recognition result, and the final recognition result is output.

2. The OCR cross-platform scheduling method based on deep learning according to claim 1, characterized in that, The engine pool pre-creates a fixed number of OCR engine handles and places them into a buffer channel; when an OCR recognition task needs to be processed, a handle is obtained from the buffer channel; after the task is processed, the handle is returned to the buffer channel.

3. The OCR cross-platform scheduling method based on deep learning according to claim 1, characterized in that, The engine pool is managed based on a concurrent and safe data structure. Engine instance identifiers are stored in the form of queues or channels, enabling multiple recognition requests to perform OCR recognition processing in parallel by obtaining different engine instance identifiers.

4. The OCR cross-platform scheduling method based on deep learning according to claim 1, characterized in that, The comparison and verification specifically includes: invoice number field verification: searching for the invoice number string in the second recognition result in the original full-text text; date field verification: converting the date value in the second recognition result into a date string in at least two predetermined formats, and searching for it in the original full-text text in turn; amount field verification: searching for the amount value string in the second recognition result in the original full-text text.

5. The OCR cross-platform scheduling method based on deep learning according to claim 1, characterized in that, The fusion strategy includes: when all fields pass verification, a full consensus strategy is adopted, and the second identification result is used as the final identification result; when some fields pass verification, a partial consensus strategy is adopted, and the fields that pass verification adopt the value of the second identification result, while the fields that fail verification adopt the value of the first identification result or the second identification result selected according to a predetermined rule; when no fields pass verification, a weighted fusion strategy is adopted, and the first identification result is used as the final identification result.

6. The OCR cross-platform scheduling method based on deep learning according to claim 1, characterized in that, The fuse has three states: closed, open, and half-open. The fuse records the number of consecutive failed calls to the second OCR engine. When the number of failures reaches a first threshold, the state changes from closed to open. After the open state lasts for a preset time, the state changes to half-open. If the call is successful in the half-open state, the state returns to closed; otherwise, it returns to open.

7. The OCR cross-platform scheduling method based on deep learning according to claim 1, characterized in that, The second OCR engine is invoked by constructing a request that conforms to the multimodal visual language model API specification, the request containing the Base64 encoded input image and predefined structured output prompts.

8. A cross-platform OCR scheduling device based on deep learning, characterized in that, include: The API call construction module is used to build an API call between a Go application and a C++-based OCR engine through CGO bridging technology. The API call includes a handle for managing the lifecycle of the OCR engine. The dynamic library configuration module is used to load the corresponding dynamic library configuration based on the target operating system using Go build tags, and compile it into a cross-platform executable program. The engine pool creation module is used to create engine pools in Go language applications. It manages multiple OCR engine handles through a channel mechanism to process input OCR recognition tasks concurrently. The first recognition processing module is used to call the first OCR engine to process the input image and generate the first recognition result and its confidence level; The first OCR engine is allocated through the engine pool; The second recognition processing module is used to configure a multimodal visual language model as a second OCR engine; when the confidence level is lower than the dynamic threshold, or when the circuit breaker of the second OCR engine is closed, the second OCR engine is invoked to process the same input image and generate a second recognition result containing structured fields. The field verification module is used to obtain the original full-text text of the input image extracted by the first OCR engine, compare and verify the field values ​​of the second recognition result with the original full-text text, and obtain the field verification result. The result fusion module is used to select the corresponding fusion strategy based on the field verification result to fuse the first recognition result and the second recognition result, and output the final recognition result.

9. A computer device, wherein the computer device is characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A computer-readable medium having computer program instructions stored thereon, characterized in that, The computer program instructions can be executed by a processor to implement the method as described in any one of claims 1-7.

Images