Prompt engineering is the practice of expressing a task so a model receives the right instructions, information, and output expectations. Good prompting improves clarity, but it cannot replace missing knowledge, weak security, or incorrect application architecture.<\/p>\n
State what the model should do in direct language. Avoid burying the primary objective inside background text.<\/p>\n
Before optimizing prompts, distinguish generative AI from the other workload families in the AI-900 learning path<\/a> so prompting is not mistaken for the whole AI system.<\/p>\n Make it clear which text describes the task and which text is content to analyze. Delimit long documents or structured inputs.<\/p>\n This becomes especially important when user-provided or retrieved content may itself contain instructions.<\/p>\n Include the facts needed for the task, but do not assume that more context always improves output. Irrelevant content can create distraction and increase cost.<\/p>\n If the model needs current or private knowledge repeatedly, retrieval may be a better architecture than pasting large documents into every prompt.<\/p>\n Constraints can define audience, length, allowed sources, tone, fields, or decision rules. A constraint should exist because it matters to the application, not because longer prompts appear more sophisticated.<\/p>\n Prompt design belongs inside an application that also handles retrieval, tools, state, and evaluation; AI-102 solution overview<\/a> shows that wider solution boundary.<\/p>\n If downstream code expects JSON, a table, a fixed schema, or a short classification, say so clearly and validate the result.<\/p>\n Structured outputs reduce ambiguity, but application code should still handle invalid or missing fields.<\/p>\n Few-shot examples can show the desired mapping from input to output, especially when the task is difficult to describe compactly.<\/p>\n Choose examples that represent the real variety of inputs. Overly narrow examples can teach the model an accidental shortcut.<\/p>\n If an application is grounded in supplied material, require the answer to use that material and make unsupported claims visible.<\/p>\n Prompt behavior should be tested inside the whole application rather than only in an isolated playground; the Azure AI Engineer course<\/a> reflects that engineering perspective.<\/p>\n System-level instructions can define application behavior and policy, while user messages express the current request. Do not rely on prose hierarchy alone for security.<\/p>\n Authorization, tool permissions, and data access must be enforced outside the model.<\/p>\n Untrusted content may attempt to override instructions or persuade the model to reveal data or call tools in unsafe ways. Treat user and retrieved text as untrusted input.<\/p>\n Untrusted instructions should not inherit trust merely because they arrived through an expected channel; zero trust security<\/a> supports the same explicit-verification boundary.<\/p>\n Collect representative cases including ordinary requests, edge cases, ambiguous inputs, and adversarial examples. Compare prompt versions on stable criteria.<\/p>\n Repeatable evaluation is stronger evidence than a few impressive demos, and the AWS ML Engineer foundation<\/a> treats measurement as part of model engineering.<\/p>\n When refining a prompt, alter one major variable\u2014task wording, context, examples, or output rules\u2014and rerun the evaluation set. Otherwise you may not know what caused improvement or regression.<\/p>\n Long prompts can accumulate duplicated rules and contradictions. Organize reusable instructions, document why important constraints exist, and version changes.<\/p>\n Prompts become versioned application artifacts that need review, testing, and rollback; Azure DevOps guidance<\/a> supplies the software-delivery discipline for managing those changes.<\/p>\n If the model lacks the correct information, add retrieval or data access. If the output needs deterministic calculation, call a tool. If an action needs permission, enforce authorization.<\/p>\nSeparate instructions from data<\/h2>\n
Provide only relevant context<\/h2>\n
State constraints explicitly<\/h2>\n
Specify the output contract<\/h2>\n
Examples can demonstrate patterns<\/h2>\n
Ask for evidence when evidence matters<\/h2>\n
Use roles carefully<\/h2>\n
Prompt injection is an architecture problem<\/h2>\n
Evaluate prompts with a test set<\/h2>\n
Change one thing at a time<\/h2>\n
Keep prompts maintainable<\/h2>\n
Do not use prompting to solve data problems<\/h2>\n