Alignment
Alignment is not one switch. It combines training, preference optimization, prompting, guardrails, data privacy, and evaluation so a model follows intended behavior under realistic pressure. In a product, alignment means the full system behaves according to user intent, developer policy, and deployment constraints.
Training signal and runtime layers
Instruction-tuned systems often start with supervised demonstrations and then use human or AI preference data. A preference objective can compare a chosen response to a rejected response for prompt and increase the margin between their scores. Runtime alignment is separate: the application constrains tools, validates structured output, and checks hallucination mitigation.
One common preference-learning signal is pairwise: for the same prompt, the training data says that is preferred to . The optimizer should raise the relative score of the chosen response without simply making every response longer or more agreeable. In production, that learned preference is only one layer:
| Layer | What it controls |
|---|---|
| Supervised instruction data | Basic task following, response style, and refusal patterns. |
| Preference optimization | Ranking chosen answers above rejected answers for comparable prompts. |
| System prompt and tool policy | Runtime boundaries, allowed actions, and required evidence. |
| Validators and audits | Schema validity, citation support, privacy checks, and regression tests. |
An alignment contract
{
"policy": "Answer with cited sources or say evidence is unavailable.",
"training_signal": "chosen_vs_rejected",
"runtime_checks": ["citation_support", "pii_redaction", "tool_permission"]
}The artifact separates learned behavior from controls that remain outside the model. A citation policy can be reinforced during training, but the application still needs an evidence checker because a fluent unsupported answer can satisfy style preferences while failing the workflow.
Alignment layers
| Layer | Example control | What it cannot guarantee alone |
|---|---|---|
| Pretraining data | broad capability and priors | instruction following or safety. |
| Instruction tuning | task-following and response formats | correct policy under adversarial context. |
| Preference optimization | preferred style and refusal behavior | exact authorization or citation support. |
| System instructions | runtime policy for a route | resistance to all prompt injection. |
| Guardrails | deterministic checks around tools and outputs | semantic quality of every answer. |
| Evaluation | detects regressions and gaps | prevents failures without enforcement. |
Strong alignment is layered because each mechanism fails differently.
Finance Assistant Alignment
A general assistant may be aligned to be helpful, but a finance assistant must also refuse to invent policy, avoid exposing private data, and require confirmation for refunds. If preference data rewards “helpful completion” too strongly, the assistant may take action or answer without evidence. The product needs workflow-specific alignment data, retrieval grounding, and tool gates.
Evaluation
Evaluate alignment by deployment scenario, not only broad chat preference. Include helpfulness, harmlessness, honesty, privacy, unsupported-claim rate, refusal accuracy, and tool-policy compliance. A model that is aligned for open-domain chat can still be misaligned for a regulated workflow if it optimizes for user satisfaction over policy.
Caveats
Preference data can encode annotator bias or reward verbosity. A model can be aligned for chat helpfulness but misaligned for a regulated workflow unless the workflow has its own tests. Alignment also drifts when prompts, retrieval corpora, tools, or user populations change.
References
- Ouyang et al., 2022, Training language models to follow instructions
- Rafailov et al., 2023, Direct Preference Optimization
- NIST AI Risk Management Framework 1.0
Nav