Text analysis requires choosing the result type before choosing a model. A complaint such as “Invoice 417 arrived late and the customer is upset” may require an invoice identifier, sentiment signal, summary or entity list; those outputs have different validation methods. A sentiment score cannot verify the invoice number, while an extracted identifier does not determine whether the customer is eligible for a refund. Set a simple contract for each field, preserve evidence from the original text and represent uncertainty when an item is absent. In third-party AI-901 text-analysis practice cases, demand an explanation of when to use entity extraction, key-phrase detection, sentiment analysis or generative summarization, and how to check the result. Avoid treating a fluent sentence as proof that every structured business fact was captured accurately.

Consider a fictional bike-repair support desk receiving: “The replacement brake lever arrived Tuesday, but I’m disappointed it still squeaks. My order is BR-1842.” A useful service might extract the order ID, recognize the negative sentiment and summarize the complaint for a technician. None of those outputs alone proves that the part is defective or that a refund should be issued. Keeping that boundary visible is part of good language-solution design.

Keywords and entities answer different questions

Keyword extraction identifies important terms or phrases representing what a passage is about: “brake lever,” “replacement,” and “squeaks.” It is useful for tagging, search and trend reporting. Named entity recognition identifies spans representing recognized categories such as people, locations, organizations or dates. Specialized fields such as an order ID may require a custom extraction rule or model rather than assuming an ordinary entity recognizer already knows your business identifiers.

In the repair message, “Tuesday” may be a date expression while “BR-1842” is a structured business identifier. A model could also mistake an inventory code for a person’s name when context is limited. Validate structured identifiers with deterministic checks: expected prefix, length, character set and existence in the authorized transaction system where permitted. Extraction is a proposal about source text; it is not the same as a successful database lookup.

Test fields separately. A good keyword list can omit a required order number. A correct entity span can still use the wrong label. When a downstream process needs a strict field, define a contract that represents missing information explicitly rather than forcing the model to invent one.

Sentiment analysis is not a diagnosis of intent

Sentiment analysis estimates whether text expresses a positive, negative, neutral or mixed opinion according to the service’s supported outputs. The bike customer sounds dissatisfied, but that does not establish that a repair is unsafe, that the customer requests a refund or that the order is fraudulent. A sentence such as “The brakes don’t make that terrible noise anymore” also illustrates why simple keyword matching can invert the meaning of a message.

Sarcasm, domain terminology, negation and multilingual phrasing complicate sentiment. A negative sentiment score is not a universal measure of urgency. Safety-related triage often needs a separate reviewed label with explicit criteria. “My brake cable snapped while riding” might be urgent even if the customer writes without obvious negative emotion. Do not use sentiment as the only basis for a consequential action.

Evaluate sentiment on real-looking fictional examples with known human judgments and inspect disagreement. If the application must support multiple languages, check actual supported locales and test translated expressions rather than assuming a language service treats every language equally.

Summarization and generation require source checks

A summary should preserve important facts while reducing length. For the repair ticket, it might say, “Customer reports that a replacement brake lever still squeaks; order BR-1842; arrived Tuesday.” It should not add “the lever is defective” if that was not established. Summarization is generative when the system composes a new explanation, so fluency is not evidence of accuracy.

Keep citations or source references for details that matter to support actions. An assistant may generate a reply, but the application must validate dates, order numbers, refund status and any promised delivery time against authoritative records. If a field is missing, the reply should state the gap or ask for clarification rather than fill it with a plausible value.

A useful validation set tests whether the summary retains the customer’s problem, correctly references the identified item and does not invent a resolution. Include conflicting and incomplete notes so the model learns to expose uncertainty. In a small application, a human can inspect a sample of generated summaries against the original messages.

Build a lightweight analysis pipeline

A basic text-analysis workflow has stages: receive authorized input, normalize only what is safe, choose the analysis operations, submit the input to a supported Foundry Tool or model, inspect the returned fields, validate critical results and display or store the approved output. The Azure AI Language service overview describes language workloads available as Foundry Tools; check the individual feature documentation and region/language support before creating a deployment.

For the repair service, one implementation might use entity analysis for dates, a deterministic pattern for order IDs, sentiment analysis for customer-feedback trends and a model for a concise technician summary. Combining these functions can be appropriate, but each step should have its own failure signal. If sentiment analysis is temporarily unavailable, that should not prevent the application from preserving the original customer message and its order identifier.

Microsoft’s current Azure Language documentation distinguishes core features recommended for new development from legacy features supported for existing implementations. Named entity recognition appears in the core capability grouping, while key phrase extraction, sentiment analysis and summarization appear in the legacy grouping supported for existing implementations. These concepts nonetheless remain in the AI-901 objectives. Therefore, an exam candidate should understand what these tasks do without presenting every historical service endpoint as the recommended starting point for a new production project. Review current feature guidance before choosing a dedicated endpoint versus a supported Foundry model.

Do not mix classic Azure Language SDK examples indiscriminately with the current Microsoft Foundry project APIs. Depending on the feature, a solution can use a dedicated Foundry Tool endpoint or a compatible general model. Confirm which client, endpoint and authentication flow your chosen documented path requires. An example that correctly calls a model may still not be an example of a dedicated language-analysis service.

Handle language and privacy deliberately

Many text messages contain names, phone numbers, addresses or purchase details. Determine which fields the analysis actually requires and redact or protect unnecessary personal data. The model should not receive unrelated customer histories merely to classify the sentiment of one sentence. Protect logs and saved test results, because a transcript or extracted entity list may itself reveal private information.

Translation can support multilingual input, but terminology may change across languages. A part name that has a common everyday meaning can be translated incorrectly in a specialized repair context. Preserve the source text and mark generated translations when they are used as evidence. Do not equate the presence of language support with guaranteed translation quality or correct technical intent.

Users may phrase requests through speech recognition, which introduces another potential source of error. If a transcript turns “front brake” into “rear brake,” downstream analysis can be internally consistent and still wrong. Maintain provenance and use confirmation for important identifiers and safety-related facts.

Add a two-message contrast to the test set. “My order arrived, and the technician was helpful” may express positive sentiment while still referring to a previous service issue. “The technician was helpful, but the brakes remain unsafe” has mixed cues and potentially serious content that a simple overall sentiment label can obscure. A practical application might keep a separate reviewed safety classifier or escalation rule so a positive phrase cannot suppress a meaningful fault report. Compare both versions against human-labeled examples and inspect which component made the final triage choice.

Another useful check is entity boundary selection. In “Order BR-1842 arrived May 6 and brake model XR-10 rattles,” the order number, date and model identifier are three different fields. A generic recognizer may locate only the date. A deterministic pattern could recognize the order number, while a custom domain extractor could interpret the model code. Do not mark the entire NLP pipeline wrong merely because one service does not solve every field, and do not quietly fill the missing value through speculation.

Validate an example with positive and negative cases

Create a tiny test set: one straightforward complaint, one positive follow-up, one neutral scheduling question, one sarcastic sentence, one bilingual message, one message with no order number and one message containing an apparently malicious instruction. Define expected entity spans, order-ID behavior and sentiment assumptions separately. For the malicious text, verify that source content is treated as data rather than obeyed as a new system instruction.

Measure useful metrics instead of one vague “AI success” score. Did the identifier exactly match? Were required entities present? Was the customer opinion captured reasonably? Did the summary preserve the safety-relevant detail? Did any unauthorized information appear in the output? A disagreement or missing field can be routed to a person rather than silently accepted.

An AI-103 engineering article on Azure language and speech applications describes deeper implementation and validation patterns. AI-901 requires the foundational ability to choose a workload and explain a lightweight client, so do not confuse it with professional design of a large speech or multilingual processing platform.

Recognize what each text workload is for on AI-901

Microsoft’s AI-901 guide explicitly names keyword extraction, entity detection, sentiment analysis and summarization. Practice by looking at a sentence and deciding which output is requested: a topic label, a named span, an attitude or a concise account. Ask whether the output can be checked deterministically, needs human interpretation or should be tied to source evidence.

Text analysis provides useful signals, not automatic authority. A careful app knows the original statement, which analysis produced which field, what its limitations are and who may act on it. That is the foundation for trustworthy NLP solutions in Microsoft Foundry and a much stronger exam skill than memorizing a list of product names.