Implement knowledge mining and document intelligence solutions practice questions

Use the 'Read' model instead of the 'Layout' model

Why it fails: The 'Read' model is for text extraction, not for reducing memory.

Use the cloud API instead of the container

Why it fails: The cloud API may have different costs but does not solve the memory issue.

Reduce the batch size in the client application

Why it fails: Batch size affects throughput but not container memory allocation.

Increase the batch size in the analysis request

Why it fails: Batch size does not affect accuracy.

Reduce the image resolution to 200 DPI

Why it fails: Lower resolution reduces OCR accuracy.

Use the prebuilt-tax.us model

Why it fails: Prebuilt models may not extract custom fields accurately.

The maximum page length is too small

Why it fails: The skill splits documents into pages; it does not fail due to size.

The default language code is not supported

Why it fails: 'en' is a supported language code.

The text split mode should be 'sentences'

Why it fails: 'pages' is a valid split mode.

Set continueOnError to false to ensure that if the skill fails for one document, the entire indexer run stops.

Why it fails: Setting continueOnError to false would cause the entire run to fail; it's better to set it to true to skip failures for individual documents.

Set the context property to '/document/pages/*' to process each page of the email individually.

Why it fails: Emails are not paginated; setting context to '/document' is appropriate to process the entire document.

The skill's 'name' property is set to '#1', which is invalid.

Why it fails: The name can be any string; '#1' is allowed.

The 'categories' property is misspelled; it should be 'entityCategories'.

Why it fails: The property 'categories' is correct for EntityRecognitionSkill.

The input source '/document/content' is incorrect; it should be '/document/text'.

Why it fails: The input source depends on the document parsing; '/document/content' is a common field.

Increase the batchSize to 10 to process more documents per invocation, reducing the number of total invocations.

Why it fails: Increasing batchSize would cause the function to receive more documents per call, making the timeout issue worse.

Increase the maxPageSize to 500 to reduce the number of API calls to Form Recognizer.

Why it fails: Form Recognizer has its own limits; increasing maxPageSize beyond the maximum supported will result in errors.

Remove the custom skill and use the built-in OCR skill in the skillset.

Why it fails: The built-in OCR skill may not integrate with Form Recognizer's advanced features; the question requires using the existing custom skill.

Configure the custom skill with a batchSize and set the indexer's maxFailedItems and maxFailedItemsPerBatch to allow retries.

Why it fails: Indexer failure thresholds control whether the run continues, not whether throttled calls are retried successfully. Setting maxFailedItems only tolerates more errors; it does not reduce the request rate or add backoff. The HTTP 429 responses would still cause missing enrichments, so this does not make the pipeline resilient.

Add a custom skill definition with a batchSize and increase the indexer's maxFailedItemsPerBatch.

Why it fails: batchSize controls how many documents are sent per call, but without addressing the throttling root cause, HTTP 429 responses persist. maxFailedItemsPerBatch merely permits more per-batch failures before stopping. This combination does not implement retry or rate limiting, so enriched fields would still be absent for throttled documents.

Increase the indexer batch size and set maxFailedItems to a higher value.

Why it fails: Larger batches increase concurrent calls to the custom skill, which worsens throttling rather than relieving it. Raising maxFailedItems only allows more documents to be skipped without failing the run; it does not fix the missing enriched fields because throttled calls still produce no output. The Function remains overwhelmed.

Configure the indexer to use the delimitedText parsing mode and set the first line as headers.

Why it fails: The delimitedText parsing mode is used for CSV or delimited files, not for scanned PDFs with images. This mode would not extract images or text from PDFs. It is intended for structured text files where fields are separated by delimiters. Using it here would result in no image extraction and incorrect text parsing.

Add a custom skill that calls the Azure AI Vision Read API directly and set the batch size to 1.

Why it fails: While a custom skill could call Azure AI Vision, this scenario specifically requires using the built-in OCR skill. The built-in skill is designed to work with normalized images from the document cracking phase. A custom skill would require additional code and would not automatically receive image data unless image extraction is enabled. Setting batch size to 1 does not address the missing configuration.

Create a separate indexer for images and use a file projection to store the extracted text.

Why it fails: A separate indexer for images is not required; the same indexer can handle both text and images if configured correctly. File projections are used to save enriched documents to a knowledge store, not to extract text for indexing. This approach adds unnecessary complexity and does not enable the built-in OCR skill to process images.

Define the API key in the indexer's configuration object and reference it from the custom skill by using a skillset variable.

Why it fails: Indexer configuration does not expose a general-purpose secret store that a custom skill can read. Indexer parameters are visible as plain text in the indexer definition, so placing the key there defeats the requirement to avoid storing it in the skillset.

Add the API key as a base64-encoded value in the custom skill's batch size property and decode it in the Azure Function.

Why it fails: The batchSize property controls how many documents are sent per skill invocation; it is not a channel for secrets. Encoding a key there would expose it in the skillset JSON and would also break batching behavior, so it is both insecure and functionally wrong.

Store the API key in Azure Key Vault and reference the secret by using a key vault secret URI in the custom skill's HTTP headers.

Why it fails: Azure AI Search does not resolve Key Vault secret URIs inside a WebApiSkill's httpHeaders values. The headers are sent as static strings, so the skill would transmit the literal URI rather than the secret, and the call would fail authentication.

Enable the indexer's cache and rerun the indexer.

Why it fails: Enrichment caching avoids reprocessing documents whose content has not changed, reducing cost and time. It does not change how skill errors are handled. Since the custom skill would still return failures on first processing, caching alone would not make the pipeline resilient to the transient API errors.

Set the batchSize property of the indexer to 1.

Why it fails: Reducing batch size limits how many documents are processed per batch but does not handle errors returned by the custom skill. A failing document would still cause the skill invocation to error. Batch size tuning addresses throughput and memory, not transient API failures, so it does not provide the required resilience.

Increase the indexer maxFailedItems value to a large number.

Why it fails: maxFailedItems controls how many document-level failures the indexer tolerates before stopping the run. A skill invocation error is not the same as a document failure, so raising this value does not prevent the custom skill error from failing the pipeline. It also allows more documents to be skipped silently, which may hide data quality problems.

A Collection(Edm.ComplexType) field with one subfield per entity type.

Why it fails: Complex collections are appropriate when each entity has multiple attributes, such as name plus type plus confidence. Here the requirement is simply to store entity strings individually and search them. A complex type adds unnecessary structure and does not improve individual searchability over a string collection.

A single Edm.String field marked as retrievable only.

Why it fails: A retrievable-only string field cannot be searched or filtered, so entities stored there would be returned in results but not queryable. It also holds only one value, which cannot represent multiple extracted entities per paper. This fails the requirement that entities be individually searchable.

A single Edm.String field with the entities concatenated into one value.

Why it fails: Concatenating entities into one string makes them searchable only as a combined phrase, so individual entity matching is unreliable and filtering on a specific person or organization is not possible. A collection field is required to preserve each entity as a separate searchable value in the index.

Store the raw JSON output of the skill in a string field and parse it at query time using a custom analyzer.

Why it fails: Storing raw JSON in a string field does not allow Azure AI Search to index the individual entity properties. Custom analyzers cannot parse JSON into structured fields at query time. This approach defeats the purpose of using a skillset to enrich and index structured data, and it would not support filtering or faceting on entity attributes.

In the index, define a field of type Collection(Edm.String) and concatenate the entity names into a single string.

Why it fails: A Collection(Edm.String) can store multiple strings but loses the structured information such as entity type and confidence. Concatenating entity names into a single string would prevent querying individual entities or their properties. This approach is not suitable when you need to preserve the entity structure for advanced search scenarios.

Use a shaper skill to flatten the entity collection into individual fields for each entity type, then map each to a separate string field.

Why it fails: Flattening the entity collection into separate fields per entity type would require knowing all possible entity types in advance and would limit the number of entities. It also loses the relationship between entity name and type. A complex collection field is more flexible and preserves the original structure without flattening.

Increase the indexer's batch size to ensure all documents are processed in a single run.

Why it fails: Batch size affects performance and throttling, not whether skill outputs are persisted to the index. Even with a larger batch, the OCR text remains unmapped and therefore absent from the index, so the raw content would still be unsearchable. This setting does not address the missing field mapping.

Enable the indexer's 'indexing parameters' to include the 'content' field from the data source.

Why it fails: The 'content' field from the data source contains only the binary PDF data or basic metadata, not the OCR-extracted text. Enabling content indexing does not map skill outputs. Without an explicit field mapping from the OCR skill, the searchable text from the scanned pages will still be missing from the index.

Change the Entity Recognition skill to use a different language model that also outputs the source text.

Why it fails: The built-in Entity Recognition skill extracts entities; it does not emit the full source text as an output. Changing its language model or parameters does not add a text output. The underlying issue is that the OCR output is never mapped into the index, not the entity skill's configuration.

Configure the custom skill's output with a targetName for each JSON property and map each target to an index field in the output field mappings.

Why it fails: A WebApiSkill's outputs are defined by name and mapped to an enrichment tree node. You cannot declare multiple targetName values for one output to split JSON properties; the output is a single value. This approach would not separate the payload into sentiment, entities, and topics.

Use a conditional skill to evaluate the JSON response and route each property to a separate output field.

Why it fails: A ConditionalSkill evaluates a boolean expression and returns one of two values. It cannot parse JSON or route multiple properties to different outputs. Using it here would only select between two values, not decompose a complex payload into several fields.

Add a ShaperSkill to the skillset and set its inputs to the custom skill's output, then map the shaped output to the index fields.

Why it fails: A ShaperSkill consolidates multiple inputs into a single complex object, which is useful for projecting a hierarchical structure. However, it does not split a single JSON payload into separate fields; it would wrap the entire response, not extract individual properties like sentiment and entities.

Increase the model's confidence threshold to filter out low-confidence extractions from the new documents.

Why it fails: Adjusting the confidence threshold only changes which extracted values are returned or flagged; it does not improve the model's ability to recognize fields in the new layout. The underlying recognition remains poor, so raising the threshold would simply hide more results rather than fix accuracy.

Add the new branch documents to the training set and retrain the existing model without any new labels.

Why it fails: Retraining requires labeled data. Adding unlabeled documents does not teach the model the new field variations. Without labels for the new documents, the training process cannot learn the correct field locations or terminology, so accuracy on the new layout would not improve as needed.

Retrain the model from scratch using only the new branch office documents.

Why it fails: Retraining from scratch with only the new documents discards the knowledge learned from the original 200 documents, likely reducing overall accuracy and requiring a large new labeled dataset. The goal is minimal labeling effort, and starting over would demand significant new annotations without leveraging existing training.

Increase the number of training documents by adding 50 more unlabeled purchase orders.

Why it fails: Unlabeled documents do not provide the model with information about field locations or table structure. Adding them without labels will not teach the model how to extract product codes from tables. The model requires labeled examples to learn the mapping between document layout and field values, so this approach is ineffective.

Use the model's confidence scores to programmatically flag missing product codes and manually correct them in post-processing.

Why it fails: Post-processing corrections address symptoms but do not improve the model's extraction capability. Manually correcting every missing product code is labor-intensive and not a scalable solution. The goal is to improve extraction accuracy at the model level with minimal effort, which labeling table columns achieves more effectively.

Switch to the prebuilt invoice model, which automatically extracts line items from any document type.

Why it fails: The prebuilt invoice model is trained on invoices, not purchase orders, and may not recognize purchase order-specific fields or table structures. While it extracts line items, the terminology and layout differences could cause poor accuracy. It also does not allow customization for the company's specific product code format, so it is not the best choice.

Sentiment Analysis skill

Why it fails: Sentiment Analysis returns positive, negative or neutral scores for opinions, not key phrases. It would be correct where the requirement is gauging tone in reviews or feedback, but extracting key phrases across multiple languages requires the Key Phrase Extraction skill, which identifies salient terms per document.

Language Detection skill

Why it fails: Language Detection returns a language code per document; it identifies language but extracts no phrases. It would be correct as a preceding step where downstream skills need the detected locale, but the stated requirement is extracting key phrases, which Language Detection cannot produce.

Entity Recognition skill

Why it fails: Entity Recognition returns people, places, organisations and other typed entities, not key phrases. It would be correct where the requirement is identifying and classifying named entities such as companies or locations, but the stem asks for salient phrase extraction, which Entity Recognition does not perform.

The document resolution is too low

Why it fails: Low resolution can affect OCR but not the primary cause of low confidence.

The document layout is not analyzed

Why it fails: Layout analysis is always performed; it does not affect confidence scores.

The batch processing size is too large

Why it fails: Batch size does not affect confidence scores.

Set the 'defaultLanguageCode' to 'en'

Why it fails: This parameter sets the language, not image extraction.

Set the 'textExtractionAlgorithm' to 'printed'

Why it fails: This parameter controls text detection, not image extraction.

Set the 'lineEnding' parameter to 'space'

Why it fails: This parameter controls line endings, not image extraction.

Use the prebuilt-layout model to extract clauses instead

Why it fails: Prebuilt models do not extract custom clauses.

Increase the OCR confidence threshold in the analysis request

Why it fails: OCR confidence threshold does not affect layout adaptation.

Label 15 more contracts with the original layout and retrain the model

Why it fails: This does not address the new layout variation.