> This page is for version v2025-04-21. > For other versions, use one of these documentation indexes: > - v2026-02-09 (default): https://docs.extend.ai/2026-02-09/llms.txt > - v2025-04-21: https://docs.extend.ai/2025-04-21/llms.txt > - v2024-12-23: https://docs.extend.ai/2024-12-23/llms.txt > ## Documentation Index > Fetch the complete documentation index at: https://docs.extend.ai/llms.txt > Use this file to discover all available pages before exploring further. > > ## API version > The current API version is `2026-02-09`, served at the site root (no version prefix in URLs). > If this page URL contains `/2025-04-21/` or `/2024-12-23/`, you are reading an older API version. > Prefer the current docs at https://docs.extend.ai/llms.txt unless the user explicitly needs that older version. > Do not treat older-version pages as the source of truth for new integrations. # Best Practices: Advanced Options > Detailed guide to extraction configuration options including processor selection, chunking, merging, and parser settings. Extend offers several advanced configuration options to optimize extraction performance, accuracy, and cost. This guide provides detailed explanations of each option. > **Note** > > For a quick guide to reducing latency, see [Latency Optimization](latency-optimization). ## Extraction Performance vs. Light ![Extraction Performance vs. Light options](/_fern-files/_img/0301156fe0b665c9bbbfedf7298004979f5b664f8a36a6feae06d04265d1cfa7.webp) ### Extraction Performance **Best for:** Complex documents, high accuracy requirements, multimodal content **Characteristics:** * Higher accuracy for complex layouts * Better handling of handwritten content * More sophisticated reasoning capabilities * Parses documents as markdown for better performance ```typescript config: { "type": "EXTRACT", "baseProcessor": "extraction_performance" } ``` ### Extraction Light **Best for:** High-volume processing, cost-sensitive applications, simple document types **Characteristics:** * Faster processing * Lower cost per processor run * Good accuracy for straightforward extractions * Removes support for advanced visual features (e.g. figure parsing, signature detection, page rotation) ```typescript config: { "type": "EXTRACT", "baseProcessor": "extraction_light" } ``` --- ## Core Performance Settings ![Core performance settings in Extend Studio](/_fern-files/_img/27c0c7bb6a92db2796f7c9c0b50203c49f2c2164b2c2b690d1300f5638772b7b.webp) ### Bounding Box Citations Bounding box citations provide spatial location references for extracted values. While useful for highlighting and validation in review interfaces, they add processing overhead. For more details, see the [Citations](/2025-04-21/product/extraction/citations) documentation. **Configuration:** ```typescript config: { "type": "EXTRACT", "advancedOptions": { "citationsEnabled": false } } ``` ### Advanced Multimodal Advanced multimodal processing uses vision-language models to better understand visual elements in documents. While this adds latency, it is essential for: * Scanned documents * Handwritten content * Checks and forms * Poor quality images **Disable for:** * Clean, digital PDFs * Documents containing primarily text * Latency-critical workflows where visual understanding is not required **Configuration:** ```typescript config: { "type": "EXTRACT", "advancedOptions": { "advancedMultimodalEnabled": false } } ``` ### Model Reasoning Insights Model reasoning insights provide explanations for the model's decision-making process, which adds processing overhead. These are primarily useful for debugging and validation during development, and can be disabled in production. **Configuration:** ```typescript config: { "type": "EXTRACT", "advancedOptions": { "modelReasoningInsightsEnabled": false } } ``` --- ## Array Strategies Array strategies control how large arrays are extracted and merged across document chunks. The default (`none`) uses standard extraction behavior. ![Array strategy options in Extend Studio](/_fern-files/_img/f2ee320f65a8acc7a640b2ae7579f8fa11771709434f610df74fd73a20b391aa.webp) | Strategy | Latency | Description | | ----------------------------- | -------- | ---------------------------------------------------------------------------------------------- | | `none` | Standard | Default behavior. Arrays merged using intelligent (Performance) or confidence (Light) merging. | | `large_array_heuristics` | Lower | Optimized for very large arrays where latency matters. Uses simpler merging logic. | | `large_array_max_context` | Higher | Multiple passes through the document for maximum accuracy. Doubles credit cost. | | `large_array_overlap_context` | Medium | Maintains surrounding page context for each chunk to eliminate context loss at boundaries. | --- ## Page Ranges ![Page ranges settings in Extend Studio](/_fern-files/_img/27b4673df9a432de67d9fc22ad87f127dd22c750e74ec52b4863e7f86a8aa7d6.webp) For documents where you only need to extract from specific pages, limiting the page range reduces processing time by skipping unnecessary content. **Configuration:** ```typescript config: { "type": "EXTRACT", "advancedOptions": { "pageRanges": [ { "start": 1, "end": 5 } ] } } ``` **Use when:** * Relevant data is consistently located on specific pages * Processing long documents where only a portion is needed * Standardized document formats with predictable layouts --- ## Chunking & Merging Chunking and merging are essential pre-processing steps that optimize document processing by breaking large documents into manageable pieces and intelligently combining related content. ### Chunking Strategy ![Chunking options in Extend Studio](/_fern-files/_img/77b6f0e85473723f7ea8c961db61bd064791c189d5357eb0ab21980b86eb9980.webp) * **Standard:** Page-based chunking with heuristics (reduces chunk size for large tables, etc.) * **Semantic:** Uses AI to intelligently determine if pages can be split without breaking content relationships **Configuration:** ```typescript config: { "type": "EXTRACT", "advancedOptions": { "chunkingOptions": { "chunkingStrategy": "standard" } } } ``` ### Chunk Types * **Section:** Splits by logical sections (headings, subheadings). Preserves content structure. * **Page:** Groups by pages (25 by default). Standard chunking setting, works for most documents. * **Document:** Treats entire document as single chunk. Fastest for non-array extraction. \* *The default page chunk size can be smaller than 25 if large tables are present* ### Chunk Size ![Chunk size settings in Extend Studio](/_fern-files/_img/8de8c454e9350008c2003f540c16e40eca88daf1c18436ff422fce12edf3a3e0.webp) The optimal chunk size depends on your extraction type: * **For large array extraction:** Decreasing chunk size lowers latency by reducing intelligent chunking/merging overhead * **For non-array extraction:** Setting chunk type to `document` is fastest as it skips intelligent merging entirely * **General rule:** Larger chunks (20-25 pages) mean fewer processing calls and less overhead **Configuration:** ```typescript config: { "type": "EXTRACT", "advancedOptions": { "chunkingOptions": { "pageChunkSize": 25 } } } ``` ### Merging Strategy ![Merging strategy settings in Extend Studio](/_fern-files/_img/e70572260b9318b054544fcd6386fad14c60476a184995906923fb0ed285bec6.webp) When the same field is extracted from multiple chunks, the merging strategy determines which value to use. | Strategy | Speed | Description | | ------------- | ------- | ----------------------------------------------------------------------------------------------------------------------- | | `intelligent` | Slowest | Uses an additional LLM call to analyze all extracted values and select the most accurate one based on document context. | | `confidence` | Fast | Selects the value with the highest confidence score. | | `take_first` | Fastest | Takes the first non-null value found (earliest page). Best when authoritative values appear at the document start. | | `take_last` | Fastest | Takes the last non-null value found (latest page). Best when authoritative values appear at the document end. | **Configuration:** ```typescript config: { "type": "EXTRACT", "advancedOptions": { "chunkingOptions": { "chunkSelectionStrategy": "confidence" } } } ``` ### Chunking Tips & Common Issues **Table Splitting:** Large tables can reduce the default chunk size, especially when chunking by page. Test these options to preserve context across large tables: | Option | Setting | | ---------------- | -------------------------------- | | Merging strategy | Intelligent | | Chunk type | Section | | Parsing options | Enable table header continuation | --- ## Parser Configuration ### Parser Block Options ![Parser block options in Extend Studio](/_fern-files/_img/1d6b0290540210c8b5d6cd57285c8c46eddb424af55dc085773ffeec3cd058be.webp) **Figure Parsing:** Converts charts, diagrams, and images into text descriptions that extraction can read. Disable if your documents don't contain important visual elements. **Signature Detection:** Detects signatures on documents and determines whether they're signed. Disable if signature verification is not needed. **Agentic OCR:** Uses AI to fix OCR mistakes, especially for handwritten text or poor-quality scans. Adds processing time and cost. Keep disabled unless processing handwriting or poor scan quality. **Formula Parsing:** Detects mathematical formulas and equations and outputs their LaTeX representations. Disable if your documents don't contain formulas. ### Parse Engine ![Parse engine options in Extend Studio](/_fern-files/_img/f22500ee0440e518cffc845e2eff0320355a7000a4eb74cc0913c793cd992f0f.webp) The parse engine controls how documents are processed. **Performance** is the default and recommended for most use cases. **Light** is cheaper and slightly faster, but does not support all parsing features such as markdown and advanced table parsing. **Use Light when:** * Processing standard digital documents * Tables are simple or not critical * Cost and speed are priorities **Avoid Light when:** * Documents require advanced table parsing * Complex multi-column layouts * Markdown output is needed --- ## Parallel Extractors For large extractions or schemas, consider breaking a single extractor into multiple extractors that run in parallel. This is particularly effective when you have both simple top-level fields and complex array extractions. ![Workflow showing a financial document split into two parallel extractors](/_fern-files/_img/2e4b6854e457a23d1956ad8dc26335a8b85b61875cde67eb1be78450ac0f8f9d.webp) The workflow above shows an example where a financial document is split into two parallel extractors: one for high-level fields, and one for the financial line item details. These run in parallel and are later combined in the workflow output. **Use when:** * Documents have both simple fields and complex arrays * Array extraction is significantly slower than other fields * Total latency is critical to your use case --- ## Related Topics * Learn about [Field Names and Prompt Crafting](field-names-and-prompt-crafting) for schema setup * For a quick latency optimization guide, see [Latency Optimization](latency-optimization)