7.2 Text, Language, Search, and Document AI Services

Text and document service boundaries

Many AWS AI scenarios begin with text, but the word text is not enough to select a service. A support ticket, a scanned contract, a product manual, a call transcript, a multilingual website, and an enterprise policy library are all text-related. They need different outputs. The practitioner should slow the conversation down and ask what the user expects to receive at the end of the workflow.

Amazon Comprehend is a managed natural language processing service. It is a good fit when the business wants to analyze text for insights such as entities, key phrases, language, sentiment, or classification. For example, a support leader might use Comprehend to understand complaint themes in tickets. The output is not a creative answer. It is structured insight that can be routed, counted, searched, or reviewed.

Amazon Translate is the fit when the primary need is language translation. A retailer might translate product descriptions for a regional launch, or an operations team might translate customer messages before routing. Translation quality still needs review for brand, legal, medical, or safety-sensitive content. Translate should not be treated as a complete localization program by itself.

Amazon Textract is the document AI fit when the input is a document and the business needs text, forms, tables, or key fields. It is commonly considered for invoices, receipts, tax forms, insurance forms, and other structured or semi-structured files. The decision is not simply OCR versus AI. The practitioner should ask whether the workflow needs field extraction, confidence thresholds, document type routing, downstream validation, and human review for low-confidence results.

Amazon Kendra is an enterprise search service. It is useful when employees or customers need relevant answers or documents from indexed content sources. Kendra is not the same as training a model. It focuses on search relevance, connectors, indexes, metadata, and access control. When a use case needs a conversational answer grounded in documents, Kendra or OpenSearch might be part of retrieval, while Amazon Q Business or Bedrock can provide the generative assistant layer.

The most common mistake is to choose a generative model when the business needs extraction. If an accounts payable system needs invoice number, date, vendor, total, and line items, a generated narrative is not the desired output. The team needs reliable extracted fields, confidence handling, validation rules, and exception queues. Textract, combined with workflow logic and possibly Amazon A2I for human review, is a more appropriate pattern.

The opposite mistake is choosing extraction when the user really wants synthesis. If a product manager asks for a digest of hundreds of customer comments, Comprehend can provide useful signals, but a foundation model might be better for a readable summary. The stronger design may use both: Comprehend for structured classification and Bedrock for summarization, with citations or source samples when decisions are important.

Search decisions require special care. Keyword search, semantic search, and generative answers are not the same user experience. Search returns documents or passages for a person to inspect. A generative answer writes a response that may need grounding and citation. A practitioner should ask whether the user must see source documents, whether permissions differ by user, whether the index must update frequently, and whether hallucination would create material risk.

Documents often contain regulated or sensitive data. Before approving any document AI pipeline, identify PII, financial data, health data, contracts, retention requirements, and cross-border constraints. Use IAM least privilege, encryption, logging decisions, and monitoring. If results flow into another system, decide who can correct extraction errors and whether corrected labels become future training or evaluation data.

A simple review workflow looks like this:

1. Classify the text or document source and sensitivity.
2. Choose the desired output: extracted fields, language translation, search result, summary, or generated answer.
3. Select the managed service that matches that output before considering custom ML.
4. Define confidence thresholds, fallback behavior, and human review for low-confidence or high-risk cases.
5. Test with real-looking documents, edge cases, poor scans, unusual languages, and known bad inputs.
6. Record cost, latency, accuracy, privacy, and operational ownership before expanding.

Skill Builder practice should compare services by output. Review a document extraction lab, a text analytics lab, and a search or generative AI lab if available in your training path. The goal is not to memorize every console screen. It is to recognize which service family solves which text problem and where the business must still supply governance.