Large Language Models Best Practices

01Purpose and scope

This manual supports the course Large Language Models. It describes how practitioners select, adapt, evaluate, and operate large language models in technical work, and it is written as a reference for the daily decisions that come up when a model is part of a product, an internal tool, or an analysis workflow.
The scope covers prompt design, retrieval of outside documents, light adaptation of model behavior, evaluation against a defined task, deployment and monitoring, and the documentation that keeps these pieces understandable to other people. It does not attempt to teach the underlying mathematics of transformer architectures or to survey the research literature, although a working practitioner benefits from a basic understanding of tokens, context windows, sampling settings, and the general fact that output is probabilistic.
The manual has limits. It does not replace qualified professional judgment, approved internal procedures, or required authorization. Where a model touches medicine, law, finance, tax, or safety-critical operations, the guidance here is a starting point only, and the people accountable for those domains must set the final requirements. Where rules depend on jurisdiction, check the current authoritative source for your location rather than relying on a summary written here.

02Core principles

Start from the task, not the model. A useful question is what a person would do without the model, how long it takes, what a wrong answer costs, and who sees the output. Those answers determine whether a language model is the right tool, whether a smaller or cheaper model will do, and how much checking is required before anyone relies on the result.
Treat model output as a draft that needs verification unless the task has been shown to be reliable under test conditions. Language models produce fluent text whether or not the content is correct. They can invent citations, misstate figures, and follow instructions that appear inside retrieved documents. Build the workflow so that a person or a deterministic check reviews anything that matters before it leaves the system.
Keep the system around the model simple enough to explain. Many failures come from layers that nobody can trace: a chain of prompts that call each other, retrieval that silently truncates documents, and post-processing that rewrites answers. Prefer a small number of components with clear inputs and outputs, and log what went in and what came out.
Measure before changing anything. A prompt edit that looks better on three examples may be worse across the full distribution of inputs. Establish a baseline on a representative test set, then compare each change against it.

03Planning and preparation

Begin by writing a one-paragraph task statement. It should name the input, the expected output format, the user or downstream system, the acceptable error rate in plain terms, and the escalation path when the model is unsure or fails. Teams that skip this step usually end up arguing about quality without agreeing on what quality means.
Collect a working set of real examples before choosing an approach. Aim for a few hundred labeled cases if the task is narrow and the labels are cheap to produce, and fewer if experts must label each one. Include easy cases, hard cases, and known failure cases. Split the set so that some examples are held back for final evaluation and never used while tuning prompts. Document where the examples came from, because a test set drawn from the same source as training or retrieval material will overstate performance.
Choose the simplest viable configuration. In rough order of cost and complexity, the options are prompt design alone, prompt design with retrieval of relevant passages, prompt design with structured output and validation, and adaptation of model weights through supervised fine tuning. Each step adds maintenance burden, requires more data, and makes behavior harder to audit. Move up only when the simpler option has been tested and falls short.
Confirm data handling before any text leaves a controlled environment. Identify whether inputs contain personal data, confidential business information, or material under license restrictions. Agree with the data owner on which model endpoints are permitted, how long logs are kept, and whether prompts may be used for any purpose beyond the immediate task. The answers depend on your organization, contracts, and jurisdiction, so involve the people who own those rules early.

04Recommended workflow

1
: Write the task statement and define two or three measurable outcomes, such as the share of answers that match a reference label, the rate of unsupported claims found in review, or the median time to produce a usable draft. Record these in the project file before running any experiment.
2
: Assemble the evaluation set as described in planning. Write a short rubric for human graders that explains how to score a response on each outcome, with worked examples of acceptable and unacceptable answers. Test the rubric on a small sample with two graders and resolve disagreements before scaling up.
3
: Run a baseline with a plain prompt. Specify the role, the task, the required format, and any constraints such as length or forbidden content. Use fixed sampling settings during evaluation, usually low temperature, so that differences between runs reflect changes you made rather than random variation. Save the exact prompt text, model identifier, and settings with each run.
4
: Add retrieval only if the answer depends on documents the model would not reliably know. Chunk source documents at boundaries that preserve meaning, such as section headings or paragraphs, rather than at fixed character counts. Index them with an embedding model or keyword search, retrieve a small number of passages per query, and include source identifiers in the prompt so the output can cite them. Check retrieval separately from generation by asking whether the correct passage appears in the top results.
5
: Constrain the output. Where the consumer is a program, request a schema and validate it before use. Where the consumer is a person, request a fixed structure such as a summary, a list of supporting passages, and a confidence note. Reject or retry outputs that fail validation, and log the failures because they often reveal gaps in the prompt or the source material.
6
: Iterate on one variable at a time. Change the instructions, the examples included in the prompt, the retrieval parameters, or the model, but not several at once. After each change, rerun the full evaluation set and compare against the baseline. Keep a short changelog that says what changed, why, and what happened.
7
: Decide whether adaptation is justified. Fine tuning is worth considering when the task has a stable format, when many examples exist with consistent labels, and when prompt-based approaches cannot reach the target after reasonable effort. Hold out a test set, watch for overfitting to the style of the training data, and check that general capabilities needed by the product have not degraded. Document the training data provenance and the exact procedure so that the run can be reproduced.
8
: Prepare for deployment by writing the runbook. It should name the owner, the endpoint, the rate limits, the fallback behavior when the model is unavailable, the criteria for rolling back to the previous version, and the procedure for responding to a reported harmful or incorrect output. Stage the rollout to a small group of users before wider release.

05Quality checks, risk controls and compliance

Run automated checks on every output where feasible. These include schema validation, length limits, banned phrase lists, detection of personal data patterns, and checks that cited passage identifiers actually exist in the retrieved set. Automated checks are cheap and catch mechanical errors, but they cannot judge whether a claim is true, so they complement rather than replace human review.
Sample outputs for human review on a schedule that matches the risk. A low-stakes internal summarizer might be reviewed on a small random sample each week, while a tool that drafts customer-facing statements may require review of every output before release. Record reviewer decisions in a form that can be aggregated, and track the rate of errors by category over time.
Test for known failure modes. These include factual errors on specific numbers and names, omission of important qualifications, sensitivity to phrasing changes that should not matter, susceptibility to instructions embedded in retrieved text, and inconsistent answers to the same question. Build a small adversarial set for each failure mode that matters to your application, and rerun it after every change to the prompt, retrieval index, or model version.
Apply access controls and logging. Limit who can change prompts in production, keep versioned records of prompts and configurations, and restrict logs that contain user inputs to the people who need them. Where outputs trigger actions such as sending messages, editing records, or making purchases, require explicit confirmation or a second check before the action completes.
Address compliance with the rules that apply to your setting. Several well known frameworks give structure to this work, including the NIST AI Risk Management Framework, which organizes risk identification, measurement, and management activities. Sector regulators and data protection authorities may impose additional duties, and their requirements differ by jurisdiction and change over time. Confirm current obligations with your compliance or legal team, and do not treat any summary here as a determination of what the law requires.
For regulated or high-risk uses, the guidance in this manual does not replace qualified professional judgment, approved procedures, or required authorization. A model that assists with clinical notes, credit decisions, legal drafting, tax preparation, or engineering safety analysis needs review by people qualified in that field, documented sign-off, and often a formal validation process that goes beyond the steps described here.

06Collaboration and documentation

Assign roles explicitly. A typical project includes a product owner who defines the task and accepts outcomes, a practitioner who builds and tests the system, a domain expert who grades outputs and sets acceptable error rates, a data steward who controls source material and access, and an operator who maintains the deployment. In small teams one person may hold several roles, but the responsibilities should still be written down.
Keep a model card or system record for each deployed configuration. It should state the purpose, the model identifier and version, the prompt template, the retrieval sources, the evaluation results with the date range of the test set omitted if sensitive, known limitations, and the people responsible. Update it when anything changes. Readers who inherit the system should be able to reconstruct its behavior without asking the original author.
Share evaluation results in a format that non-specialists can read. A short table showing the baseline, the current version, and the failure categories with examples is usually more useful than a long technical appendix. Include a few representative outputs, both good and bad, so that stakeholders understand what the numbers mean in practice.
Agree on how disagreements are resolved. When graders disagree about whether an output is acceptable, record both views and the rubric clause that applies. Periodically review disagreements as a group, because they often reveal ambiguity in the task statement that needs to be fixed rather than a grader who needs correction.

07Measures and continuous improvement

Track a small set of indicators tied to the outcomes defined at the start. Common ones include task accuracy against held-out labels, the rate of outputs that fail validation, the rate of reviewer-flagged errors, latency and cost per request, the share of responses that trigger a fallback or escalation, and user-reported issues per thousand sessions. Choose targets with the domain owner, and state them as ranges that trigger review rather than as fixed promises.
Monitor for drift. The inputs users send change over time, retrieval sources are updated, and model providers may change underlying models or their behavior. Compare recent inputs against the distribution in the evaluation set, watch for new topics the system was not built for, and rerun the full evaluation suite on a schedule and after any upstream change.
Improve through a regular review cycle. Each cycle should examine a sample of failures, group them into causes such as missing source material, ambiguous instructions, or a genuine capability gap, and decide on one or two changes to test. Retire changes that do not help, and record the reasons so that the same idea does not return without new evidence.
Recognize the limits of improvement. Some tasks will not reach the accuracy a domain expert requires with a language model alone, and the right response may be to narrow the scope, add human review, or choose a different tool. Stating this plainly to stakeholders is part of the job.

08Common mistakes and how to prevent them

Evaluating on examples that look like the prompt. Teams often write prompts while looking at a few test cases, then report impressive results on the same cases. Prevent this by freezing a held-out set before prompt work begins and by reporting results only on that set after each change.
Trusting fluent output. A confident, well-organized answer can still be wrong. Require citations to source passages where the task allows it, spot-check claims against the sources, and build reviewer training around the specific errors the system tends to make.
Letting retrieval hide problems. When retrieval returns the wrong passage, the model may still produce a plausible answer from its general knowledge, and nobody notices. Log retrieved passages with each output and evaluate retrieval separately from generation.
Changing several things at once. A new prompt, a different model, and a larger context window introduced in one step make it impossible to know what caused a shift in results. Keep changes small, log them, and rerun the baseline comparison each time.
Ignoring cost and latency until launch. A prompt that works well with a large context and a slow model may be impractical at production volume. Estimate token usage and response times during prototyping, and include them in the evaluation criteria.
Skipping the runbook. Systems fail in ways nobody anticipated, and without a rollback plan and a named owner, the response is slow and improvised. Write the runbook before launch and rehearse the rollback once.

09Practical checklist

Write the task statement with input, output format, user, acceptable error rate, and escalation path.
Define two or three measurable outcomes and record them before experimenting.
Build an evaluation set from real examples and freeze a held-out portion before tuning.
Write a grading rubric with worked examples and test it with at least two graders.
Run a baseline with a plain prompt and fixed sampling settings, saving the exact configuration.
Add retrieval only when needed, and evaluate retrieval separately from generation.
Validate structured outputs automatically and log every validation failure.
Change one variable at a time and rerun the full evaluation after each change.
Confirm data handling permissions with the data owner before sending any text to a model.
Confirm applicable legal and compliance obligations with the responsible team for your jurisdiction.
Obtain qualified review and authorization for any regulated or high-risk use.
Keep a model card, prompt versions, and a changelog current for every deployed configuration.
Monitor drift and failure rates on a schedule and after any upstream change.
Write and rehearse the rollback and incident response runbook before launch.

★Learning sources

Micro Degree: Large Language Models
Micro Degree: Data Analytics Applications
Micro Degree: Azure Cloud Fundamentals
Micro Degree: Google Cloud Platform Basics

?Frequently asked questions

Should I fine tune a model or improve my prompts first?

Start with prompt design and, where needed, retrieval of relevant documents, because these are cheaper to change and easier to audit. Consider fine tuning only when a stable format and enough consistent labeled examples exist, and when the simpler approaches have been tested and still fall short of the target. Keep a held-out test set in either case so you can tell whether the change helped.

How many test examples do I need?

There is no universal number, and the answer depends on how varied the inputs are and how costly labeling is. For a narrow task, a few hundred well-chosen cases often reveal the main failure patterns, while broad tasks need more coverage across topics and user types. Include hard cases and known failures, not only typical inputs.

Can I send customer or patient text to a language model?

Only if your organization's data handling rules, contracts with the service, and applicable privacy and sector requirements permit that use for the specific data involved. These rules vary by jurisdiction and by the type of data, so confirm with your privacy, security, and compliance staff before any such text leaves a controlled environment. This manual does not authorize that use.