|
| 1 | +Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. |
| 2 | +SPDX-License-Identifier: MIT-0 |
| 3 | + |
| 4 | +# Language Support |
| 5 | + |
| 6 | +When implementing Intelligent Document Processing solutions, language support is a crucial factor to consider. The approach you take depends on whether the language of your documents is supported by the components leveraged in the workflow, such as Amazon Bedrock Data Automation (BDA) or LLMs. |
| 7 | + |
| 8 | +## Decision Process |
| 9 | + |
| 10 | +Below is the decision tree illustrating the suggested decision process: |
| 11 | + |
| 12 | +```mermaid |
| 13 | +flowchart TD |
| 14 | + Start[Documents] --> Q1{Language supported by<br/>Bedrock Data Automation - BDA?} |
| 15 | + |
| 16 | + Q1 -->|Yes| BDACheck{Document quality<br/>and structure<br/>suitable for BDA?} |
| 17 | + Q1 -->|No| Pattern2Direct[Pattern 2<br/>Bedrock FMs] |
| 18 | + |
| 19 | + BDACheck -->|Yes| Pattern1[Pattern 1<br/>Bedrock Data Automation - BDA] |
| 20 | + BDACheck -->|No| Pattern2Alt1[Pattern 2<br/>Bedrock FMs] |
| 21 | + |
| 22 | + Pattern1 --> Accuracy1{Accuracy meets<br/>requirements?} |
| 23 | + Pattern2Direct --> Accuracy2{Accuracy meets<br/>requirements?} |
| 24 | + Pattern2Alt1 --> Accuracy3{Accuracy meets<br/>requirements?} |
| 25 | + |
| 26 | + Accuracy1 -->|No| Pattern2Fallback[Pattern 2<br/>Bedrock FMs] |
| 27 | + Accuracy1 -->|Yes| Deploy1[Deploy] |
| 28 | + |
| 29 | + Accuracy2 -->|No| OptimizePath2{Issue source:<br/>Classification or Extraction?} |
| 30 | + Accuracy2 -->|Yes| Deploy2[Deploy] |
| 31 | + |
| 32 | + Accuracy3 -->|No| OptimizePath3{Issue source:<br/>Classification or Extraction?} |
| 33 | + Accuracy3 -->|Yes| Deploy3[Deploy] |
| 34 | + |
| 35 | + OptimizePath2 -->|Classification| Pattern3A[Pattern 3<br/>UDOP model for classification] |
| 36 | + OptimizePath2 -->|Extraction| FineTuning2[Pattern 2<br/>And model fine-tuning] |
| 37 | + |
| 38 | + OptimizePath3 -->|Classification| Pattern3B[Pattern 3<br/>UDOP model for classification] |
| 39 | + OptimizePath3 -->|Extraction| FineTuning3[Pattern 2<br/>And model fine-tuning] |
| 40 | + |
| 41 | + Pattern2Fallback --> Accuracy4{Accuracy meets<br/>requirements?} |
| 42 | + Accuracy4 -->|Yes| Deploy4[Deploy] |
| 43 | + Accuracy4 -->|No| OptimizePath4{Issue source:<br/>Classification or Extraction?} |
| 44 | + |
| 45 | + OptimizePath4 -->|Classification| Pattern3C[Pattern 3<br/>UDOP model for classification] |
| 46 | + OptimizePath4 -->|Extraction| FineTuning4[Pattern 2<br/>And model fine-tuning] |
| 47 | +``` |
| 48 | + |
| 49 | +## Pattern 1 |
| 50 | + |
| 51 | +> Pattern 1: Packet or Media processing with Bedrock Data Automation (BDA) |
| 52 | +
|
| 53 | +First, verify if your documents' language is supported by Amazon Bedrock Data Automation (BDA). If your language is supported by BDA, begin with Pattern 1 (BDA). |
| 54 | + |
| 55 | +At the time of writing (Sep 19, 2025) BDA supports the following languages: |
| 56 | + |
| 57 | +- English |
| 58 | +- Portuguese |
| 59 | +- French |
| 60 | +- Italian |
| 61 | +- Spanish |
| 62 | +- German |
| 63 | + |
| 64 | +> Important Note: BDA currently does not support vertical text orientation (commonly found in Japanese and Chinese documents). For the most up-to-date information, please consult the [BDA documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/bda-limits.html). |
| 65 | +
|
| 66 | +If BDA's accuracy doesn't meet your requirements for your specific scenario or language, proceed to Pattern 2. |
| 67 | + |
| 68 | +## Pattern 2 |
| 69 | + |
| 70 | +> Pattern 2: OCR → Bedrock Classification (page-level or holistic) → Bedrock Extraction |
| 71 | +
|
| 72 | +For this pattern, follow this structured implementation approach: |
| 73 | + |
| 74 | +```mermaid |
| 75 | +flowchart TD |
| 76 | + Start[Pattern 2] --> Q1{Is full OCR transcription required<br/>for your use case?} |
| 77 | + |
| 78 | + Q1 -->|Yes| RequiredOCR[Step 1A: Select required OCR backend] |
| 79 | + Q1 -->|No| OptionalOCR[Step 1B: Optional OCR path] |
| 80 | + |
| 81 | + RequiredOCR --> Q2{Document language<br/>supported by Textract?} |
| 82 | + Q2 -->|Yes| TextractReq[Use Textract backend<br/>] |
| 83 | + Q2 -->|No| BedrockReq[Use Bedrock backend] |
| 84 | + |
| 85 | + OptionalOCR --> Q3{Consider OCR for<br/>potential accuracy boost?} |
| 86 | + Q3 -->|Yes| Q4{Document language:<br/>supported by Textract?} |
| 87 | + Q3 -->|No| NoOCR[Disable OCR backend] |
| 88 | + |
| 89 | + Q4 -->|Yes| TextractOpt[Use Textract backend] |
| 90 | + Q4 -->|No| BedrockOpt[Use Bedrock backend] |
| 91 | + |
| 92 | + TextractReq --> ClassStep[Step 2: Classification and Extraction Models] |
| 93 | + BedrockReq --> ClassStep |
| 94 | + TextractOpt --> ClassStep |
| 95 | + BedrockOpt --> ClassStep |
| 96 | + NoOCR --> ClassStep |
| 97 | + |
| 98 | + ClassStep --> Q6{Document language:<br/>high-resource?} |
| 99 | + |
| 100 | + Q6 -->|Yes| StandardApproach[Select and test any model] |
| 101 | + Q6 -->|No| EnhancedApproach[Test multiple models<br/>Extend testing to 50+ docs] |
| 102 | + |
| 103 | + StandardApproach --> Q7{Classification and Extraction<br/>accuracy meet requirements?} |
| 104 | + EnhancedApproach --> Q7 |
| 105 | + |
| 106 | + Q7 -->|Yes| AssessStep[Step 3: Assessment Strategy] |
| 107 | + Q7 -->|No| Optimize[Consider fine-tuning] |
| 108 | + |
| 109 | + Optimize --> AssessStep |
| 110 | + AssessStep --> Deploy[Deploy] |
| 111 | +``` |
| 112 | + |
| 113 | +While comprehensive model selection guidance for different languages could constitute an entire documentation suite, understanding the fundamental challenges is essential for production deployments. The reality of modern language models presents a significant transparency gap where providers rarely publish detailed statements about language-specific performance characteristics or training data distribution across their model portfolio. |
| 114 | + |
| 115 | +### The High-Resource vs Low-Resource Language Divide |
| 116 | + |
| 117 | +The concept of language resources refers to the availability of training data, linguistic tools, and computational research investment for a given language. This divide creates a performance gap that persists across virtually all foundation models, regardless of their stated multilingual capabilities. |
| 118 | + |
| 119 | +**High-resource languages** such as English, Mandarin Chinese, Spanish, French, and German typically benefit from extensive training data representation, resulting in more reliable extraction accuracy, better understanding of domain-specific terminology, and stronger performance on complex document structures. |
| 120 | + |
| 121 | +**Low-resource languages** encompass a broad spectrum of languages with limited digital representation in training corpora. These languages require significantly more extensive testing and validation to achieve production-ready accuracy levels. The performance degradation can manifest in several ways: reduced accuracy in named entity recognition, challenges with domain-specific terminology, difficulty processing complex document layouts, and inconsistent handling of linguistic nuances such as morphological complexity or non-Latin scripts. |
| 122 | + |
| 123 | +### Practical Implementation Approach |
| 124 | + |
| 125 | +The absence of public performance statements from model providers necessitates an empirical approach to model selection. For high-resource languages, initial testing with 50-100 representative documents typically provides sufficient confidence in model performance. However, low-resource languages require substantially more comprehensive validation, often demanding 5-10 times the testing volume to achieve comparable confidence levels. |
| 126 | + |
| 127 | +When working with low-resource languages, consider implementing a cascade approach where multiple models are evaluated in parallel during the pilot phase. This strategy helps identify which foundation models demonstrate the most consistent performance for your specific document types and linguistic characteristics. Additionally, establishing clear performance thresholds early in the process prevents costly iteration cycles later in deployment. |
| 128 | + |
| 129 | +### OCR Backend Considerations for Language Support |
| 130 | + |
| 131 | +The choice of OCR backend significantly impacts performance for different languages, particularly when working with low-resource languages or specialized document types. The IDP Accelerator supports three distinct OCR approaches, each with specific language capabilities and use cases. |
| 132 | + |
| 133 | +#### Textract Backend Language Limitations |
| 134 | + |
| 135 | +Amazon Textract provides robust OCR capabilities with confidence scoring, but has explicit language constraints that must be considered during backend selection. Textract can detect printed text and handwriting from the Standard English alphabet and ASCII symbols. |
| 136 | +At the time of writing (Sep 19, 2025) Textract supports English, German, French, Spanish, Italian, and Portuguese. |
| 137 | + |
| 138 | +For languages outside this supported set, Textract's accuracy degrades significantly, making it unsuitable for production workloads. |
| 139 | + |
| 140 | +#### Bedrock Backend for Low-Resource Languages |
| 141 | + |
| 142 | +When working with languages not supported by Textract, the Bedrock OCR backend offers a compelling alternative using foundation models for text extraction. This approach leverages the multilingual capabilities of models like Claude and Nova, which can process text in hundreds of languages with varying degrees of accuracy. |
| 143 | + |
| 144 | +The Bedrock backend demonstrates particular value when the extracted text will be included alongside document images in subsequent classification and extraction prompts. This multi-turn approach often compensates for OCR inaccuracies by allowing the downstream models to cross-reference the text transcription against the visual content. |
| 145 | + |
| 146 | +#### Strategic OCR Disabling |
| 147 | + |
| 148 | +In scenarios where full text transcription provides minimal value to downstream processing, disabling OCR entirely can improve cost efficiency. This approach works particularly well when document images contain sufficient visual information for direct image-based only processing, or when the document structure is highly standardized and predictable. |
| 149 | + |
| 150 | +The decision to disable OCR should be based on empirical testing with representative document samples. If classification and extraction accuracy remains acceptable using only document images, the elimination of OCR processing can significantly reduce both latency and operational costs. |
| 151 | + |
| 152 | +### Model Families Mixing |
| 153 | + |
| 154 | +Using different model families for OCR versus classification and extraction can yield significant performance improvements, particularly for challenging language scenarios. For example, a deployment might use Claude for OCR text extraction while employing Nova models for subsequent classification and extraction tasks, optimizing for each model's particular strengths. |
| 155 | + |
| 156 | +This approach allows teams to leverage the best multilingual OCR capabilities for text transcription while utilizing different models optimized for reasoning and structured data extraction. The key consideration is ensuring that the combined approach maintains acceptable accuracy while managing the complexity of multi-model workflows. |
| 157 | + |
| 158 | +Other considerations: |
| 159 | + |
| 160 | +- For documents with poor quality (e.g., handwritten text) consider alternative Bedrock Backend instead of Textract |
| 161 | +- If accuracy requirements aren't met, explore model fine-tuning options |
| 162 | + |
| 163 | +## Pattern 3 |
| 164 | + |
| 165 | +> Pattern 3: OCR → UDOP Classification (SageMaker) → Bedrock Extraction |
| 166 | +
|
| 167 | +If Bedrock-based classification doesn't meet your requirements, implement Pattern 3 using Unified Document Processing (UDOP) classification. |
0 commit comments