Busca en todas las páginas de la documentación
Amazon Comprehend is a managed natural language processing service reached entirely through the SDK. There is no console-driven pipeline you must click through first - every capability on this page is a client call.
The surface splits along two independent axes: pretrained versus custom, and real-time versus batch. Almost every confusing question about Comprehend ("why is this slow," "why do I need an endpoint," "why doesn't this classify my documents") comes from mixing up which side of these two axes you are actually using. This page builds the map so the rest of the section reads as detail, not surprise.
Start*Job, S3-to-S3, asynchronous).Every pretrained capability in Comprehend is exposed as a Detect operation: DetectEntities, DetectKeyPhrases, DetectSentiment, DetectDominantLanguage, and DetectPiiEntities (plus the lighter ContainsPiiEntities check). Call one of these with a client and a string of text, and you get back a scored, structured result in well under a second.
# --- Python (boto3) ---
import boto3
comprehend = boto3.client("comprehend", region_name="us-east-1")
resp = comprehend.detect_sentiment(
Text="The new dashboard is a huge improvement.",
LanguageCode="en",
)
print(resp["Sentiment"], resp["SentimentScore"])// --- TypeScript (AWS SDK v3) ---
import { ComprehendClient, DetectSentimentCommand } from "@aws-sdk/client-comprehend";
const comprehend = new ComprehendClient({ region: "us-east-1" });
const resp = await comprehend.send(new DetectSentimentCommand({
Text: "The new dashboard is a huge improvement.",
LanguageCode: "en",
}));
console.log(resp.Sentiment, resp.SentimentScore);No training job, no model artifact, no endpoint - the pretrained models are always on and shared across every AWS customer. This is the right starting point for the vast majority of text: reviews, support tickets, chat transcripts, articles.
Comprehend Custom exists for the minority of cases where the pretrained vocabulary is not enough - internal ticket categories, proprietary product names, industry-specific entity types a general model was never trained to recognize.
Custom has two flavors. A custom classifier (CreateDocumentClassifier) assigns one of your labels to a whole document (multi-class or multi-label). A custom entity recognizer (CreateEntityRecognizer) finds instances of entity types you define, the same way DetectEntities finds built-in types like PERSON or ORGANIZATION. Both are trained asynchronously from labeled examples you supply in S3, and both produce a versioned model ARN you then use for inference.
Inference against a custom model happens one of two ways:
CreateEndpoint) from the trained model ARN, then call ClassifyDocument or DetectEntities with that EndpointArn. Latency is comparable to the pretrained Detect calls, but the endpoint is billed by the hour whether or not you are actively calling it.StartDocumentClassificationJob or StartEntitiesDetectionJob pointed at the model ARN, with input and output S3 locations. No endpoint to provision or pay for between runs, but results land minutes later, not instantly.This same real-time-versus-batch split exists independently of custom models. Every pretrained Detect operation also has a batch twin - StartSentimentDetectionJob, StartKeyPhrasesDetectionJob, StartPiiEntitiesDetectionJob, StartDominantLanguageDetectionJob - that reads many documents from an S3 prefix, writes results to another S3 prefix, and reports progress through Describe*Job polling. Two axes, four quadrants: pretrained real-time, pretrained batch, custom real-time, custom batch.
One boundary trips people up more than any other: Comprehend detects, it does not rewrite. DetectPiiEntities returns entity types and character offsets into the string you sent - it does not return a redacted copy of your text. Masking, replacing, or dropping that sensitive text is logic you write, using the offsets Comprehend gives you. (The asynchronous PII batch job is the one exception - it can optionally write already-redacted output documents to S3, which the synchronous call cannot do.)
| Surface | Setup Required | Latency | Billing Shape |
|---|---|---|---|
| Pretrained Detect (real-time) | None | Sub-second, per call | Per unit of text processed |
Pretrained batch (Start*Job) | S3 input/output locations, IAM role | Minutes, async | Per unit of text processed |
| Custom classifier/recognizer, real-time | Trained model + hosted endpoint | Sub-second, per call | Training cost + hourly endpoint cost |
| Custom classifier/recognizer, batch | Trained model only | Minutes, async | Training cost + per unit of text processed |
The practical rule: start with a pretrained Detect call. Move to Custom only when you can point at specific documents the pretrained model mislabels. Move to a real-time endpoint only when a human or live system is waiting on the answer; otherwise a batch job is cheaper and simpler to operate, since nothing sits idle between runs.
DetectSentiment and DetectEntities are pretrained and handle general text well; Custom is only for labels or entity types the built-in models don't know.Detect* for one document, asynchronous Start*Job for many.LanguageCode; always check current per-operation language support before assuming a language works.No. The Detect operations are pretrained and always available - just create a client and call the operation with your text and a language code.
When the pretrained models genuinely miss your domain - internal category labels a classifier should assign, or entity types (product SKUs, internal codes) DetectEntities was never trained to recognize.
The synchronous DetectPiiEntities only returns types and offsets; your code masks the text. The asynchronous PII batch job can optionally write redacted output documents directly.
Only for real-time calls (ClassifyDocument, DetectEntities with an EndpointArn). Batch jobs (StartDocumentClassificationJob, StartEntitiesDetectionJob) call the trained model ARN directly with no endpoint.
Yes. A hosted endpoint bills by the hour for its provisioned inference units whether or not you send it traffic - delete it when you are done with a workload.
DetectPiiEntities returns every PII entity with type and offsets. ContainsPiiEntities is a cheaper yes/no-style check that returns labels and scores without offsets, useful for gating documents before deeper processing.
Yes. Every pretrained Detect operation has a batch counterpart (for example DetectSentiment and StartSentimentDetectionJob) that runs the identical model over many S3 documents instead of one string.
Labeled documents in S3 (a CSV or manifest), an IAM role Comprehend can assume to read that data, and a call to CreateDocumentClassifier specifying the mode (multi-class or multi-label) and language.
A classifier assigns a label to a whole document. A recognizer finds and tags spans of text as instances of entity types you define, the same shape DetectEntities returns for built-in types.
Default to batch unless something is actively waiting on the result. Batch jobs need no standing endpoint and are typically cheaper to operate for anything that can tolerate minutes of latency.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última actualización: 24 jul 2026