AI Transaction Detection

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.

Boundary Detector automatically locates the start of each transaction or repeating section within a document by analyzing its content for consistent anchor features. It is a core component of AI Transaction Detection, providing the intelligence and configuration needed to segment documents into meaningful, extractable units.

Overview

The Boundary Detector is designed for documents containing multiple, similarly structured transactions—such as payroll records, EOBs, or repeating form entries—where each transaction begins with a recognizable pattern or set of features. By configuring anchor detection parameters, users can automate the identification of transaction boundaries, even in documents with complex or variable layouts.

How It Works

1. Detection Window Selection:
   The detector selects a portion of document content to analyze, based on the configured detection window size. This window should be large enough to expose at least 10 repeating transactions to the LLM during boundary detection.

2. Anchor Detection via LLM:
   The detector constructs a prompt for the large language model (LLM), including a job description, schema, and any user-supplied instructions. The LLM is asked to identify a set of anchor features—such as static text labels, regular expressions, or structured field patterns—that reliably indicate the start of each transaction. The number of anchors and detection attempts are configurable for robustness.

3. Anchor Matching and Scoring:
   The detected anchors are matched against each line of the document. Each line is scored based on how many anchors it matches, and a minimum score threshold determines which lines are considered transaction boundaries. The detector repairs and adjusts hit counts to account for ambiguous or overlapping matches, ensuring accurate segmentation.

4. Section Instance Creation:
   For each detected boundary, a new section instance is created, representing a single transaction. These instances are returned for further processing or data extraction.

5. Iterative Detection and Fallback:
   If no valid boundaries are found, the detector can retry anchor detection with alternative strategies or updated instructions, up to the configured maximum number of attempts. Previous unsuccessful anchor sets are provided to the LLM to improve results.

Diagnostics and Logging

The Boundary Detector generates detailed diagnostic artifacts to support configuration, troubleshooting, and validation:

• Anchor Detection Logs:
  Chronological logs of each detection attempt, including anchor details, line offsets, regex status, reasons, and hit counts.

• Anchor Detection.txt:
  A text file showing line-by-line anchor match scores and boundary decisions for the analyzed content.

• Response Schema.json:
  The JSON schema used for anchor detection responses, aiding in prompt engineering and debugging.

• Timing Metrics:
  Timers for anchor matching operations, supporting performance analysis.

• Hierarchical Diagnostics:
  Child logs for each detection attempt, allowing users to review and compare multiple strategies and outcomes.

These diagnostics are accessible through the Grooper diagnostic interface and are essential for refining anchor selection, validating boundary detection, and optimizing performance.

Best Practices

• Use clear, consistent field labels in your documents to maximize anchor detection reliability.
• Adjust the minimum score and anchor count to balance sensitivity and specificity for your document type.
• Provide targeted instructions to the LLM if initial detection attempts are unsuccessful or produce ambiguous results.
• Review diagnostic logs to understand how anchors are matched and to troubleshoot segmentation issues.

For more information on configuring and using the Boundary Detector, refer to the Grooper documentation on AI Transaction Detection and Anchor-Based Segmentation.

Can be one of the following types:

Transaction Extractor provides AI powered data extraction for individual transactions detected by AI Transaction Detection.

This object configures and orchestrates the extraction workflow, including document quoting, prompt construction, batching, parallel execution, and data import. It is highly configurable, allowing users to tailor extraction behavior for different document types and business requirements.

Role in Grooper

• Used as part of AI Transaction Detection to automate the extraction of structured data from unstructured or semi-structured documents.
• Integrates with Data Model schemas, allowing you to target specific fields, tables, or sections for extraction.
• Supports custom instructions and quoting methods to optimize LLM understanding and output accuracy.
• Handles batching and parallelism to maximize throughput and efficiency for large or complex documents.

How It Works

1. Document Quoting:
   The extractor formats and annotates document content using the configured quoting method, providing the LLM with clear context for each transaction.

2. Prompt Construction:
   For each batch of transactions, a prompt is built that includes the quoted content, extraction schema, and any user-supplied instructions.

3. Batching and Parallelism:
   Transactions are grouped into batches according to the 'Transactions Per Operation' property. Multiple extraction operations can run in parallel, controlled by 'Max Degree of Parallelism', to improve performance.

4. LLM Extraction:
   The LLM receives the prompt and returns structured data for each transaction, matching the configured schema and instructions.

5. Data Import:
   Extracted data is mapped back to the document, aligning each transaction with its source content for review, validation, and downstream processing.

Configuration and Usage

• Select a quoting method that best preserves the structure and meaning of your document content.
• Use 'Extraction Instructions' to clarify requirements, handle edge cases, or provide document-specific guidance.
• Limit extraction to specific Data Elements using the 'Included Elements' property to improve accuracy and performance.
• Adjust batching and parallelism settings to balance throughput and resource usage for your environment.

Diagnostics and Logging

The Transaction Extractor generates detailed diagnostic artifacts to support configuration, troubleshooting, and validation:

• Extraction Logs:
  Chronological logs of each extraction operation, including prompts, responses, and timing metrics.
• Response Data.json:
  The raw JSON data returned by the LLM for each batch.
• Chat Log.jsonl:
  The full chat conversation with the LLM, including all prompts and responses.
• Data Import Timers:
  Timing information for data import and mapping operations.

These diagnostics are accessible through the Grooper diagnostic interface and are essential for refining extraction settings, troubleshooting issues, and validating results.

Best Practices

• Start with default settings and refine quoting, instructions, and batching based on extraction diagnostics.
• Use smaller batches for documents with highly variable or complex transactions.
• Review diagnostic logs to troubleshoot extraction issues and optimize prompt design.
• Monitor system performance and adjust parallelism to avoid overloading resources.

For more information, see the documentation for AI Transaction Detection, Data Model, and Quoting Method.