Information Extraction practice questions

In the styles collection under the isHandwritten property.

Why it fails: The styles collection describes visual styling characteristics, not extracted field values.

In the paragraphs collection under the boundingRegions array.

Why it fails: Paragraphs contain raw text blocks, not typed, normalized field values.

In the analyzeResults object under the content property.

Why it fails: The content property contains the full concatenated string of all extracted text.

prebuilt-invoice

Why it fails: prebuilt-invoice is specialized for invoices and runs unnecessary extraction logic for generic documents.

prebuilt-read

Why it fails: prebuilt-read extracts raw text lines and words, but does not provide advanced layout structures like tables and selection marks.

prebuilt-document

Why it fails: prebuilt-document (general document) extracts key-value pairs and entities, which is heavier than layout-only processing.

PUT /documentintelligence/documentModels/{modelId}?api-version=2024-02-29-preview

Why it fails: This PUT endpoint is used for model creation/annotation storage, not model composition.

POST /documentintelligence/documentModels:train?api-version=2024-02-29-preview

Why it fails: Train is used for training a single model from labeled or unlabeled data, not composing existing models.

POST /documentintelligence/models:classify?api-version=2024-02-29-preview

Why it fails: There is no classify endpoint for model composition.

Enable the 'handwritten=true' query parameter in the API call header.

Why it fails: Handwritten text extraction is built-in and does not require a handwritten=true query parameter.

Train a custom neural model exclusively with handwritten signature samples.

Why it fails: Signatures are generally variable and difficult to extract as structured text fields; neural models extract text and key values rather than verifying signatures.

Deploy a separate Azure AI Vision Handwritten Text container and pipe its output into the Document Intelligence request.

Why it fails: Document Intelligence incorporates advanced OCR capabilities internally; an external container is redundant.

prebuilt-socialSecurityCard

Why it fails: prebuilt-socialSecurityCard does not exist in Azure AI Document Intelligence's model catalogue; the closest is prebuilt-idDocument, which extracts identity fields from US driver licences and similar cards. It is tempting because Social Security cards are real US documents, but no dedicated prebuilt model targets them.

prebuilt-architecturalDrawing

Why it fails: prebuilt-architecturalDrawing is not an Azure AI Document Intelligence prebuilt model. The catalogue covers invoices, receipts, IDs, business cards, W-2, health insurance cards and similar forms. It is tempting because custom neural models can be trained on drawings, but no prebuilt architectural model ships.

prebuilt-medicalChart

Why it fails: prebuilt-medicalChart is not offered as an Azure AI Document Intelligence prebuilt model; healthcare extraction is handled by Text Analytics for health instead. It is tempting because clinical documents are a recognised domain, but Document Intelligence's prebuilt set does not include a medical chart model.

All training documents must be converted to Microsoft Word (.docx) format prior to upload.

Why it fails: Supported formats include PDF, TIFF, JPEG, PNG, and BMP, not Word documents.

You must manually write a Python script to generate the labels.json file instead of using Document Intelligence Studio.

Why it fails: Document Intelligence Studio provides a graphical interface to label documents without writing manual JSON.

Training documents must all have identical pixel dimensions and DPI settings.

Why it fails: Neural models handle varying resolutions, layouts, and dimensions.

Global Administrator on the Microsoft Entra ID tenant

Why it fails: Global Administrator is an overly broad directory role not required for routine Document Intelligence tasks.

Network Contributor on the subscription virtual network

Why it fails: Network Contributor is unnecessary unless configuring specific private endpoints.

1 document

Why it fails: A single document is insufficient for training any custom machine learning extraction model.

50 documents

Why it fails: 50 documents is closer to the recommended maximum or older template-based model sizing, but not the minimum required.

100 documents

Why it fails: A minimum of 100 documents is not required; neural models are designed to learn effectively from smaller datasets starting at 5 documents.

Create a separate table label for each page fragment and concatenate them via post-processing code.

Why it fails: Post-processing concatenation is inefficient and fails to leverage the model's native multi-page table extraction capabilities.

Exclude multi-page tables from the training set and rely solely on the prebuilt layout model for tables.

Why it fails: Custom template models are capable of learning multi-page tables if labeled correctly during training.

Convert all multi-page documents into single extremely long virtual pages before labeling.

Why it fails: Modifying document dimensions or virtual page sizes disrupts the spatial layout analysis of the Document Intelligence service.

Composed models require a separate Azure resource endpoint for each individual sub-model.

Why it fails: A single endpoint and model ID are used to invoke the composed model.

Composed models support an unlimited number of sub-models without any performance impact.

Why it fails: There are service limits on the maximum number of sub-models that can be combined in a single composed model.

An Azure SQL database

Why it fails: Not a requirement for training storage.

A pre-existing template model

Why it fails: Not a prerequisite.

A pre-installed local labeling agent

Why it fails: The Studio handles this natively in the cloud.

DOCX

Why it fails: Not supported.

PPTX

Why it fails: Not supported.

UserPermissions

Why it fails: Not included in result.

TrainingLogs

Why it fails: Only available during training.

Prebuilt invoice model

Why it fails: The prebuilt invoice model is tailored for invoices, not purchase orders. While purchase orders and invoices share some fields, the model may not accurately extract purchase order-specific fields like order number or vendor name. Using it would require additional mapping and likely result in lower accuracy, and it does not address the need for a custom model.

General document model with custom field extraction

Why it fails: The general document model extracts text and basic structure but does not support custom field extraction out of the box. You would need to build custom logic to identify and extract fields, which is not efficient and may not achieve high accuracy. It is not a trained model for specific fields, so it fails to meet the requirement for a custom model with minimal samples.

Custom neural model

Why it fails: Custom neural models require a larger number of labeled samples, typically at least 15, to achieve good accuracy. With only five samples, the model would likely underfit and produce poor results. Neural models are better suited for documents with varying layouts and complex structures, not for consistent layouts with minimal samples.

BeginAnalyzeDocumentAsync

Why it fails: BeginAnalyzeDocumentAsync belongs to the older FormRecognizerClient naming from the legacy SDK and is not the current method on DocumentAnalysisClient. Using it would not compile against the current Azure.AI.FormRecognizer package surface. The scenario requires the modern client, so this name is incorrect.

StartAnalyzeDocumentFromUriAsync

Why it fails: StartAnalyzeDocumentFromUriAsync begins analysis but expects a publicly accessible URL, not a local file stream. Since the scenario explicitly analyzes a local PDF, this method would require hosting the file first. It returns the same long-running operation pattern, but the input source is wrong for the stated requirement.

AnalyzeDocumentAsync

Why it fails: AnalyzeDocumentAsync is not a method exposed by DocumentAnalysisClient in the current Azure AI Document Intelligence SDK. The client surface uses StartAnalyzeDocument and its async variant, plus model-specific convenience methods. Calling AnalyzeDocumentAsync would fail to compile, so it cannot initiate the long-running analysis operation the scenario requires.

Set the 'pages' parameter to include all pages in the receipt.

Why it fails: The 'pages' parameter is used to limit analysis to specific pages, not to handle rotation or skew. Receipts are typically single-page, so setting this parameter is unnecessary for the scenario. It does not address the requirement to handle rotated or skewed documents, which the service manages automatically.

Enable the 'ocr.rotationCorrection' option in the analyze request.

Why it fails: Azure AI Document Intelligence automatically corrects rotation and skew as part of its OCR processing. There is no need to enable a specific option called 'ocr.rotationCorrection'; the service handles orientation internally. Adding such a parameter is not supported and would not affect the extraction results.

Use the general document model and then parse the fields manually.

Why it fails: The general document model extracts text but does not provide semantic field extraction for receipts. Manually parsing merchant name, transaction date, and total amount would be error-prone and time-consuming. This approach does not leverage the prebuilt receipt model's capabilities and would likely result in lower accuracy and increased development effort.

GET /documentModels/{modelId}/analyze

Why it fails: There is no GET /documentModels/{modelId}/analyze endpoint in Azure AI Document Intelligence. The analyze operation is initiated via POST, and results are retrieved via a separate GET endpoint that includes the result ID. Using this non-existent endpoint would result in an error and fail to retrieve the extracted data.

POST /documentModels/{modelId}/analyzeResults

Why it fails: The POST method is not used for retrieving results. The analyzeResults endpoint requires a GET request with the result ID. Using POST would not return the analysis results and is not a valid operation for this purpose. This option misuses the HTTP method and endpoint path, leading to failure in retrieving the extracted fields.

POST /documentModels/{modelId}/analyze

Why it fails: The POST /documentModels/{modelId}/analyze endpoint is used to submit a document for analysis. It initiates the analysis operation and returns a result ID, but it does not return the extracted fields directly. To get the results, you must subsequently call the GET endpoint with the result ID. Therefore, this is not the correct endpoint for retrieving analysis results.

Create a separate custom model for the final page and chain them using an orchestration model.

Why it fails: Orchestration models route a document to one of several custom models by classifying its type; they do not chain page-level models to assemble a single invoice's fields. It tempts for mixed document types, but here every document is an invoice, so a single custom model with correctly tagged fields suffices.

Split every multi-page invoice into individual single-page documents before uploading.

Why it fails: Splitting invoices destroys the multi-page context the model needs to associate a final-page field with its invoice, and it prevents learning cross-page relationships. It tempts when page-level extraction is the goal, but here fields span pages, so the full document must be uploaded and tagged as one unit.

Define all late-appearing fields as optional metadata parameters in the training configuration JSON file.

Why it fails: Document Intelligence custom extraction models have no optional-metadata parameter for fields; every tagged field is a schema field, and the JSON configuration defines the model's docTypes and field schema only. It tempts as a way to excuse absent fields, yet optionality is expressed by leaving a field untagged on documents where it does not appear.

Modify the orchestration model routing threshold in the Azure portal settings.

Why it fails: The routing threshold governs the confidence score at which a document is assigned to a component model; raising or lowering it cannot correct a component model that classifies its own document type wrongly. Threshold tuning applies when documents are misrouted between otherwise accurate models.

Switch the orchestration model from a template-based classifier to a neural classifier using the REST API.

Why it fails: Switching to a neural classifier changes the classification algorithm, but the stem states a component model is failing to classify, so the fault lies in that model's training data or labels, not the classifier type. Neural classifiers are chosen when template-based classification cannot handle layout variation.

Update the API version to bypass classification and force direct extraction via the general document model.

Why it fails: Forcing direct extraction with the general document model discards the classifier entirely, so invoices, work orders and purchase orders are no longer routed to their specialised component models and field accuracy collapses. The general model suits ad-hoc extraction from mixed documents where no trained component models exist.

Prebuilt receipt model

Why it fails: The prebuilt receipt model is trained on sales receipts and returns their fields, so it cannot extract tax-form fields regardless of layout consistency. It is tempting because prebuilt models need no training, but the scenario requires accurate extraction of tax-form data, which only a model trained on those forms provides.

Custom neural model

Why it fails: Custom neural models suit variable-layout documents with mixed text, tables and structure, and their training is slower than template-based approaches. It is tempting because neural models handle complex forms well, but for fixed-position fields a custom template model trains faster and returns higher accuracy, matching the stated requirement.

General document model

Why it fails: The general document model extracts key-value pairs and entities without training on your specific forms, so it cannot guarantee field-level accuracy for tax data. It is tempting as a zero-training starting point, but the scenario demands the fastest training and highest accuracy on a fixed layout, which a custom template model delivers.