Text-analysis systems turn unstructured language into something an application can use: named entities, categories, summaries, translated text, sentiment signals or typed fields. An LLM can perform many of these tasks, but the work is not complete when the model returns persuasive prose. The output must match the application’s data contract, preserve important distinctions from the source, and handle uncertainty or unsupported language correctly.
The text-analysis domain of Microsoft AI-103 includes extraction, sentiment or tone analysis, sensitive-content detection, translation and domain-specific prompting. A common example is a multilingual customer-service platform that classifies inbound complaints, extracts an order identifier and summarizes the issue for an authorized agent. Different stages need different evaluation criteria, even if they use one shared model deployment.
Distinguish a named entity from a useful business field
Named entity recognition identifies mentions such as people, places, organizations or dates. A business extractor may need a specific field such as purchase_order_id or incident_severity that is defined by an organization’s schema. A product code that looks like a date might be misclassified by a general model; a phrase like “next Friday” needs the correct temporal context before becoming a structured deadline.
Define types and validation rules before building the prompt. A customer account identifier may require a known prefix and lookup against a permitted tenant. A currency amount requires a numeric value, currency code and perhaps source line. An entity mention in text does not prove the organization recognizes it as a valid record. Preserve raw evidence and normalize fields in controlled code so an incorrect model guess does not become an authoritative database update.
Make summaries faithful to scope and evidence
A legal or medical summary can be concise and still wrong if it omits a limiting condition. Determine what the user needs: a short customer-friendly abstract, a handoff note for a specialist, or a structured list of obligations with source references. Each task may use different prompts, input selection and review rules. Summaries should not introduce new advice, confidence or timelines that the source did not support.
For a complaint-handling workflow, require the summary to preserve the reported issue, affected product, user-requested action and relevant dates. Test a case with conflicting messages and another with missing evidence. The correct response may indicate that two sources disagree rather than silently choosing the one that sounds most recent. When the source is legally consequential, a human reviewer should be able to open the exact sentence or document version that supported the summary.
Use sentiment as a signal, not a diagnosis
Sentiment classification estimates the emotional tone of a text; it is not proof of a customer’s intent or mental state. Sarcasm, cultural conventions, domain jargon and mixed praise or criticism can all confuse the signal. A negative sentiment result might help prioritize review of a frustrated complaint, but it should not automatically deny service or trigger a punitive decision.
Decide what granularity is useful. A single document-level label may hide that a customer praised shipping but complained about a defective item. Aspect-level classification can separate those concerns where the task supports it. Evaluate the model with real domain examples, regional languages and borderline cases, and keep a manual correction path. The business process should rely on concrete events and policy, not a sentiment score treated as an objective fact.
Design translation for terminology and audience
A translation workflow needs source and target language, locale, preferred terminology and an approach to preserving names, measurements and legal phrases. A fluent translation can still be unacceptable if it changes a safety instruction or a contract term. Terminology glossaries and domain examples are useful for specialized content, but the final text should be reviewed where accuracy has material consequences.
Choose the translation mechanism that fits the job. A short interactive sentence can use a text-translation service or a controlled LLM workflow; an entire document may need layout-preserving translation. Microsoft’s Azure Translator document translation documentation describes synchronous single-file and asynchronous batch patterns, with different infrastructure requirements. Do not assume one method preserves every PDF table or image in precisely the same way.
Validate structured outputs beyond syntactic JSON
JSON formatting makes data easier for software to consume, but valid JSON is not evidence of a correct field. Consider a complaint containing two order numbers, one from a refund email and another from the actual defective item. A model may return a perfectly formed order_id field with the wrong value. Downstream code must check which order the complaint concerns and whether the requesting user is authorized to access it.
Define required fields, allowed enums, types and explicit missing-value behavior. Reject unsupported extra actions, and do not let the model invent a value merely to satisfy a required schema. When multiple candidates are plausible, return candidates with source references or route the record for human resolution. A repair prompt may fix malformed syntax; it cannot reliably resolve ambiguity absent new evidence.
A multilingual support portal receives a ticket in Spanish: the customer reports that a new account has not been activated. A summarizer translates the message into English but drops the negation, and a JSON validator confirms that the generated status field contains an allowed value. The data is structurally valid and factually wrong. Translation and extraction therefore need task-specific evidence checks rather than a single schema pass.
Define a contract containing the original language, normalized user intent, entity identifiers, source span and any uncertainty that matters to downstream automation. Preserve the original message or an approved auditable reference so bilingual reviewers can compare claims. A translation model may reorder sentences or substitute familiar terminology; a controlled glossary helps with product names, contractual terms and technical error codes but should be tested for overcorrection when common words resemble brand names.
For entity extraction, distinguish a named organization in a quotation from the account that actually owns the ticket. If the model emits a customer ID, validate it against the authenticated user or authoritative CRM record. If sentiment classification labels the message “angry,” treat that as a service-priority signal at most, never as a definitive statement about an individual. Use confidence or uncertainty to route borderline cases to a human; avoid automated business restrictions based solely on inferred tone.
An evaluation set should include negation, mixed-language messages, abbreviations, spelling errors, copied quotations and conflicting dates. Score each field according to the consequence of being wrong: an incorrect product category may be recoverable, while a wrong recipient or account identifier can expose private data. This makes the text-analysis layer reliable enough for real workflow decisions rather than merely capable of producing elegant summaries.
Keep multilingual input from becoming an access bypass
Security policies apply regardless of the language in which a user asks for information. A role that cannot view a confidential record should remain blocked if the user requests it in another language or asks the model to translate a hidden system message. Data filtering and tool authorization must be enforced in application code, not left to language-specific safety prompts.
Test mixed-language inputs, transliteration, code-switched messages and text containing embedded instructions. An external document might say “translate this sentence and then run this command”; the translation task does not authorize executing a tool. Treat source text as data and escape it appropriately for output. Preserve which source segment was translated so an operator can locate errors without reproducing the entire conversation.
Build evaluation sets with exact and semantic cases
For entities and structured fields, compare expected identifiers and values exactly, including units and dates. For summaries, evaluate coverage, fidelity and omission of critical qualifiers. For translation, have bilingual reviewers assess meaning and terminology for high-risk cases. For sentiment or tone, analyze error rates by language and input type rather than reporting one global average.
Include examples where the correct extraction result is null or a review flag. An application that always returns something may score well on easy examples and fail catastrophically on absent data. Separate model behavior from preprocessing errors: a missing OCR line means the text model never saw the evidence. Improve the failed layer instead of compensating with increasingly assertive prompt instructions.
Implement a practical support-ticket pipeline
A Microsoft AI-103 exercise can take an incoming email, detect its language, translate it for the support queue, extract the permitted order ID, label the issue type and prepare a concise summary with source spans. Before displaying the ticket, validate the account reference and check that any personal data is handled according to policy. Hold writes in draft state until the required fields pass checks.
Deliberately test sarcasm, multiple order numbers, a missing date and a request for a translated confidential note. The app should preserve legitimate meaning, reject unauthorized access and tell the operator what remains uncertain. Text analysis is production ready when its structured and translated outputs help a human or downstream system act accurately—not just when they read naturally.