Implement AI solutions by using Microsoft Foundry practice questions

Placing few-shot examples in a chat-style request.

With chat-style APIs, few-shot examples are supplied as example user/assistant message pairs that follow the system message and come before the real user message; the model reads them as earlier turns that show the expected answer pattern. Fine-tuning is a different, permanent customization. Examples sent in an unrelated earlier request are not part of the context, and system messages after the user's question blur the request.

1. Recall that few-shot examples are part of the prompt for this one request.
2. In a role-tagged message list, a demonstration looks like a past user turn and the assistant's ideal reply.
3. Place those pairs after the system message and before the real user message.
4. Fine-tuning and separate requests do not put the examples into this request's context.

Exam tip: Few-shot in chat = example user/assistant pairs between the system message and the real question.

Grounding prompts in supplied data.

When answers must reflect information the model was not trained on, the most effective prompt technique is to provide grounding data, here the policy text, and instruct the model to answer from it. Telling a model not to invent facts is not enough on its own because it still lacks the facts. Output length and tone do not affect accuracy.

1. Note that the policy is newer than the model's training data.
2. The model cannot know facts it has never seen, so they must be supplied.
3. Put the source text in the prompt and tell the model to answer from it.
4. Length and tone settings do not make content more accurate.

Exam tip: Fresh or private facts: put the source in the prompt and tell the model to use it.

Reducing fabrication in grounded prompts: an 'out' and citations.

Microsoft's prompt guidance recommends giving the model an 'out', such as replying 'not found' when the answer is not in the provided text, and asking it to cite the source passage for its statements; both make it harder for the model to present invented content as fact. Longer answers, a bigger context window and a higher temperature do not address why the model fills gaps.

1. The source is already in the prompt; the failure is what happens when it is silent.
2. Give the model a permitted response for missing answers.
3. Require citations so each statement has to point at real source text.
4. Discard changes to length, context size or randomness.

Exam tip: Grounded prompts need an 'out' for missing answers and citations for the rest.

Specifying the output structure in a prompt.

When software consumes the reply, the prompt should state the exact output structure, here the JSON fields, and ideally show an example. Explicit structure makes the format far more consistent. A token limit truncates rather than shapes the reply, asking for brevity still allows plain sentences, and temperature 0 makes the model consistent without telling it which format to be consistent in.

1. The failure is about format, not length or randomness.
2. The model needs to know the exact structure the app expects.
3. Describe the fields and show an example reply.

Exam tip: If code reads the reply, specify the structure and show an example.

Recency bias and repeating instructions after long content.

Microsoft's guidance notes that models can be susceptible to recency bias: information at the end of a prompt can influence the output more than information at the start. With a long document between the instruction and the end of the prompt, repeating the instruction after the content (doubling down) is a recommended first experiment. Separators help rather than hurt, a token cap truncates the reply instead of refocusing it, and splitting into unlinked requests loses context.

1. Note the layout: a short instruction, then a very long block of content.
2. Recall that later text in a prompt can weigh more heavily (recency bias).
3. Restate the instruction after the content and compare the results.
4. Keep delimiters; they make the prompt clearer.

Exam tip: Long content pushes your instruction out of focus: say it again at the end.

Deploying a model before using it.

In Foundry, you deploy a model from the catalog to get a named deployment; the playground opens on that deployment and application code calls it by name. Fine-tuning, agents and hosted agent containers are later or optional steps. (Foundry also previews 'instant' models that skip deployment in limited regions, but deploying is the standard path.)

1. Picking a model in the catalog does not make it callable yet.
2. Deploy it to create a named endpoint target.
3. Use the deployment in the playground and from code.

Exam tip: Catalog model → deployment → playground and code.