Ask AI

The 'Model' property determines which LLM will process the prompt and generate responses for this Ask AI extractor.

Choose a model that is compatible with your LLM Connector and appropriate for your extraction scenario. Model selection impacts extraction quality, supported features (such as context length and structured output), and cost.

Configuration Guidance

• Use the drop-down to select from available models provided by your configured LLM Connector.
• Consider the model's context length when extracting from large documents; exceeding the limit may result in truncation or chunking.
• Some models may support advanced features such as function calling or improved JSON output.

Example

To use OpenAI's GPT-4 model, select gpt-4 from the list. For faster or less expensive extraction, you might choose gpt-3.5-turbo.

Changing the model can affect extraction accuracy, response time, and cost. Always validate extraction results after switching models.

Can be one of the following types:

The Chat Parameters class defines a set of options for tuning the behavior of LLM completion requests in Grooper. These parameters allow users to control the randomness, diversity, and topicality of generated responses, enabling tailored outputs for a wide range of scenarios.

Typical usage involves adjusting one or more parameters to guide the model’s output toward the desired style or content. For example, increasing randomness for creative tasks, or reducing repetition for summarization.

Configuration Guidance

• Adjust either 'Temperature' or 'Top P' to control randomness and diversity, but not both simultaneously.
• Use 'Presence Penalty' and 'Frequency Penalty' together to reduce repetition and encourage broader topic coverage.

Usage in Grooper

Chat Parameters are used throughout Grooper to influence LLM completions for document processing, data extraction, and other AI-driven tasks.

Impact

Proper configuration of ChatParameters can significantly affect the quality, creativity, and reliability of LLM outputs. Experimentation is recommended to find the best settings for your specific use case.

The 'Instructions' property defines the user query or directive that guides the LLM in extracting or transforming document content. This text is combined with the document context and sent as the main prompt.

Use clear, specific instructions to achieve the desired extraction or transformation. The quality and clarity of instructions directly impact the accuracy and structure of the LLM's response.

Configuration Guidance

• Phrase instructions as a direct question or command, such as What is the effective date? or Summarize this document in 3 bullet points.
• For structured output, explicitly request JSON and provide an example or schema if needed.
• Tailor instructions to the extraction goal, referencing specific document sections or data points.

Examples

• List the names of the parties.
• Return a JSON array of all invoice line items, including description, quantity, and amount.
• Extract the contract start and end dates as a JSON object.

Well-crafted instructions improve extraction reliability and reduce the need for post-processing.

The 'Preprocessing' property controls how the document text is transformed prior to being sent to the LLM. Preprocessing can improve extraction accuracy by clarifying document structure, normalizing whitespace, and highlighting layout features.

Configuration Guidance

• Enable tab marking to assist with table extraction or when working with columnar layouts.
• Use paragraph marking to allow extraction of values that span multiple lines within a paragraph.
• Adjust control character settings to match the formatting and structure of your source documents.

Example Scenario

If extracting data from a table with irregular spacing, enable tab marking so that the LLM receives \t characters at column boundaries, making it easier to generate structured output.

Proper preprocessing can significantly improve the quality and reliability of LLM-based extraction, especially for complex or poorly formatted documents.

Can be one of the following types:

This property allows you to specify a Value Extractor that isolates and filters the document content to be included as context in the prompt sent to the LLM. If not set, the entire document text in scope will be included by default.

Use this feature to narrow the input to only the most relevant portions of the document, improving prompt clarity and model performance. This is particularly useful when working with long documents or when only a specific section (e.g., a header, clause, or table) contains the information needed to answer the question or fulfill the instructions.

For example:

• If extracting an effective date, you might use a ClauseDetection extractor to isolate the "Term" section.
• If summarizing parties, a pattern-based extractor could be configured to include only the signature blocks.

The filtered content returned by this extractor is preprocessed (via the Preprocessing property) before being passed to the LLM.

Note: The extractor used here should return a single Data Instance or a set of instances that logically concatenate into coherent input for the LLM. Excessive or irrelevant content may reduce output quality due to token limitations. If no value is specified, all text content in scope will be included.

The 'Max Response Length' property sets an upper limit on the number of tokens the LLM may generate in its response.

This helps control the size, cost, and performance of LLM completions, especially when extracting large or verbose content.

• 1 token ≈ 4 characters for English text, but this can vary by language and content.
• If left blank, the model's default maximum is used, which may be quite large.
• Setting a lower value can prevent runaway responses or excessive usage charges.

Configuration Guidance

• Use a value that is large enough to accommodate the expected output, but not so large as to waste resources.
• For short answers or single-value extraction, 50–200 tokens is often sufficient.
• For summaries or structured data, increase as needed (e.g., 500–2000 tokens).

If the response exceeds this limit, it will be truncated by the LLM service. When using a JSON schema, this will result in invalid JSON.

The 'JSON Schema' property allows you to specify a JSON Schema that defines the exact structure of the LLM's response. When provided, the LLM is instructed to return output that conforms to this schema, enabling highly reliable and consistent extraction of structured data.

How It Works

• The schema must be a valid JSON object with "type": "object" and a "title" property.
• All expected properties, their types, and any validation rules should be defined in the schema.
• When a schema is set, the LLM is prompted to return only JSON matching the schema, and the extractor will parse and validate the response accordingly.

Configuration Guidance

• Use the code editor to author or paste a JSON schema that matches your extraction requirements.
• Always include a "title" property (e.g., "title": "InvoiceLineItem").
• Define each property with its type (e.g., "type": "string", "type": "number").
• Optionally, add required, enum, default, or description fields for more precise control.

Example

Validation

• The schema is checked at runtime. If "type" is not "object" or "title" is missing, a validation error is raised.
• Invalid or incomplete schemas may result in extraction errors or unpredictable LLM output.

Usage Scenarios

• Extracting structured records such as parties, line items, or key-value pairs.
• Enforcing a consistent output format for downstream processing in tables or sections.
• Reducing post-processing by ensuring the LLM returns only the required fields.

Providing a schema is highly recommended for complex or multi-field extraction tasks.

The 'Parse JSON Response' property controls whether the extractor expects and parses JSON output from the LLM.

When enabled, the extractor will:

• Instruct the LLM (via the prompt or schema) to return only JSON.
• Parse the returned JSON into a hierarchy of Data Instances, with named children for each property or array element.
• Support both single-object and array-of-object responses, enabling extraction of tables, lists, or multi-field records.

Primary Goal: Data Table and Section Compatibility

The primary goal when parsing JSON to produce child Data Instances is to output a data instance hierarchy that matches the data layout of a Data Table or Data Section. This ensures that the extracted structure can be seamlessly consumed by a Table Extract Method or a Section Extract Method, supporting downstream structured extraction workflows in Grooper.

• Each object or array in the JSON is mapped to a Data Instance or a collection of instances, mirroring the row/field structure expected by tables and sections.
• This compatibility allows for direct use of LLM-extracted data in Grooper's table and section processing features, reducing the need for manual mapping or transformation.

Configuration Guidance

• Enable this property when you want to extract structured data, such as tables, lists, or objects with multiple fields.
• Ensure your 'Instructions' property clearly requests JSON output, and provide examples or a schema if needed.
• Use the 'Selector' property to extract a specific portion of the JSON (e.g., a nested array or object).

Example Prompts

• Return a JSON array of all parties, each with "name" and "role" fields.
• Extract the invoice header as a JSON object with "date", "number", and "total".

Output Structure

• If the LLM returns a single JSON object, one Data Instance is created with children for each property.
• If the LLM returns a JSON array, one Data Instance is created for each object in the array.
• This structure is compatible with downstream Table Extract Method and Section Extract Method operations.

Usage Tips

• For best results, instruct the LLM to return only JSON, without extra text or formatting.
• If using a schema, the extractor will validate and enforce the expected structure.
• If the response is not valid JSON, extraction will fail or produce no results.

This property is essential for reliable structured extraction using LLMs in Grooper.

The 'Selector' property specifies a JSONPath expression used to extract a specific portion of the JSON returned by the LLM when 'Parse JSON Response' is enabled. This allows you to target and extract only the relevant part of a potentially complex or nested JSON response.

Purpose and Usage

• Use the selector to isolate arrays, objects, or fields within the JSON that correspond to the data you want to extract.
• This is especially useful when the LLM returns additional metadata, summaries, or nested structures, and only a subset is needed for downstream processing.

How to Construct a Selector

• Prefix expressions with $ to indicate the root object.
• Use dot notation for nested access (e.g., $.data.items).
• Use wildcards (*) or filters to target arrays or conditionally included values.

Example

If the LLM responds with: { "summary": "Overview text...", "parties": [ { "name": "Alice" }, { "name": "Bob" } ] } Setting Selector to $.parties will isolate the array and generate one output instance per object inside it.

Configuration Guidance

• Leave blank to parse the entire JSON response.
• Use selectors to extract only the relevant array or object for Data Table or Data Section compatibility.
• Test your selector using sample JSON to ensure it matches the intended data.

Troubleshooting

• If the selector path yields no matches, no instances will be produced.
• Ensure the JSONPath expression is valid and matches the structure of the LLM's response.
• Use online JSONPath evaluators or Grooper's diagnostic tools to verify your selector.

The selector provides precise control over which part of the LLM's JSON output is treated as the extractable payload, enabling robust and flexible structured extraction workflows.

The 'Match All' property determines whether the extractor returns every matching instance of a value found in the source content, or only the single best match for each extracted value.

Purpose and Behavior

• When enabled (true), the extractor will search for and return all occurrences of each extracted value within the document context. This is especially useful when the LLM response may correspond to multiple locations in the document, such as repeated values, lists, or references that appear in several places.
• When disabled (false), only the single best-matching instance (typically the one with the highest confidence or best alignment) is returned for each extracted value. This is appropriate for unique values or when only one instance is needed.

Configuration Guidance

• Enable 'Match All' when extracting data that may appear multiple times, such as party names, repeated line items, or references in tables and lists.
• Disable 'Match All' for fields where only a single, most relevant value is required (e.g., invoice number, effective date).

Example Scenarios

• Enabled: Extracting all instances of a party name that may appear in both the header and signature block.
• Disabled: Extracting a unique contract number that should only appear once.

This property provides fine-grained control over how multiple matches are handled during extraction, supporting both single-value and multi-value use cases.