VLM OCR

The Data Generator object configures how Grooper uses large language models (LLMs) to generate structured data from unstructured document content. It is embedded as a property within various Grooper features that leverage generative AI, such as advanced data extraction, document classification, and content transformation.

Configuration Guidance

• Choose a model that matches your accuracy, speed, and cost requirements.
• Use structured output mode whenever possible for the most reliable results.
• Adjust chat parameters to fine-tune the LLM's behavior for your specific use case.
• Lowering the 'Temperature' can improve consistency and reduce variability in responses, especially for structured data extraction.
• Increase 'Max Tries' if you encounter intermittent failures or unparseable responses.

How It Works

When Grooper performs an extraction using a Data Generator:

1. The extraction schema (as a JSON object) and system/user messages are sent to the LLM.
2. The LLM is prompted to return data in the required JSON format.
3. If 'Use Structured Output' is enabled and supported by the model, the LLM is given explicit instructions to return strictly valid JSON matching the schema.
4. Grooper parses the LLM's response and maps it to the extraction schema.
5. If the response is invalid, incomplete, or a transient error occurs, Grooper retries the request up to 'Max Tries'.

This approach enables robust, schema-driven extraction from a wide variety of document types, even when traditional rule-based methods are insufficient.

Diagnostics and Logging

When extraction is performed, Data Generator logs diagnostic artifacts to aid in troubleshooting and auditing:

• Chat Log.jsonl: A line-delimited JSON log of all messages exchanged with the LLM during extraction.
• Response Data.json: The raw JSON data returned by the LLM for each extraction attempt.
• LLM Completion Operation: Timing and performance metrics for each LLM request, recorded in the diagnostic log.

These artifacts are available in the extraction diagnostics and can be used to review LLM interactions, analyze failures, and optimize configuration.

The schema must include:

• A "bounds" object for each detected element, using normalized coordinates (0–1) relative to the processed image.
• Optionally, a "tooltipText" property at the same level as "bounds" for custom annotation text. Example: { "tooltipText": "Custom tooltip text", "bounds": { "x": 0.25, "y": 0.40, "width": 0.10, "height": 0.05 } }

Can be one of the following values:

A combination of the following flags:

The Error Disposition property determines the system's response to errors that occur while executing the activity.

• Flag: The affected Batch Folder or Batch Page will be flagged for review.
• Log: The error will be written to the Grooper event log.
• Stop: Processing will halt, the Batch will be set to an error state, and all pending tasks will be deleted.

You can combine multiple options using the IssueDisposition flags.
Adjust this property to match your organization's error handling and escalation policies.

If the number of consecutive errors reaches this value, a critical stop will occur and the Activity Processing service will halt further processing.

• Use this property to prevent runaway failures and to ensure that persistent errors are escalated for review.
• Set to a higher value to allow more retries before stopping, or to a lower value for stricter error control.

Can be one of the following values:

The Concurrency Mode property determines whether the activity can be executed in parallel across multiple Batch Objects, or if it must run sequentially.

• This setting affects which Processing Queue the activity is submitted to and how tasks are distributed.
• Choose the appropriate mode based on the activity's thread safety and resource requirements.