Instruction Following vs. Intent Inference: Two Approaches to Model Alignment

4 hr ago0 views

This article compares two ways to align large language models with user intent: literal instruction following and intent inference. It explains the trade-offs of each in predictability, auditability, and prompt-writing effort. It also covers how responsibility can be split between system design and users, and describes an evaluation case in which a valid solution path was scored as a failure.

1. Two Alignment Orientations

“Alignment” usually means that a model’s behavior stays consistent with what people intend. In engineering practice, this consistency is mainly achieved through two approaches.

The first is literal instruction execution. Training goals emphasize that the model follows the instruction strictly, does not expand the task scope on its own, and does not speculate about requirements the user never stated. Users must spell out task boundaries, prohibited actions, output formats, and risk points before the model can produce stable results. This orientation resembles governance approaches from ancient times that stressed clear, codified rules. Its core purpose is to reduce ambiguity.

The second is intent inference. The model combines context, conversation history, and system settings to infer what the user actually wants. Users can write briefly, and the model can fill in reasonable default behavior. However, the output becomes less predictable, and the model may make decisions the user did not expect.

Neither approach is strictly better. The right choice depends on the task’s risk level and its tolerance for errors.

2. Benefits and Costs of Literal Execution

Literal execution mainly offers predictability and auditability. In batch processing, workflow automation, and compliance review, each output corresponds directly to an instruction, which makes review and traceback easier. The model does not arbitrarily widen the scope of operations, so the risk of misuse is lower.

The costs are equally clear. First, the burden of writing prompts shifts to the user. Users must anticipate every possible edge case. Otherwise, the model fails where the instruction is silent, rather than making a reasonable completion. Second, the practical ceiling of model capability is limited by prompt quality. The same model can perform very differently with a rough instruction than with a complete one.

Take log troubleshooting as an example. If a user only writes “Find the errors in this log,” a literal model may return only lines containing the word “ERROR” and miss exceptions recorded as “Exception” or “timeout.” If the user adds “Errors include all exception levels, timeouts, and connection failures, sorted by time,” the results are more complete. However, this requires the user to know that those categories exist in the first place.

3. Who Bears the Cost of Writing Prompts

Real user input is usually short, conversational, and missing background. This is common in everyday use and is not a user mistake. If the system requires every user to specify all boundaries, it effectively hands engineering work that belongs to system design over to the user.

A more reasonable approach divides responsibility by layer:

The system handles default behavior. It provides reasonable assumptions for missing information and labels those assumptions in the output.
The user specifies high-risk constraints, such as data that must not be modified, fields that must be retained, and operations involving funds or permissions.
When key information is missing, the model proactively asks clarifying questions. It neither guesses silently nor refuses outright.

The following is a reference structure for task descriptions:

Task: Organize this week's order anomaly records
Default behavior: When fields are missing, provide assumptions and label them; sort by anomaly occurrence time
Hard constraints: Do not modify the original data; output only order number, anomaly type, and recommended handling action
To confirm: If an anomaly type cannot be determined, list it as an open question instead of classifying it on your own

This structure separates the space for inference from hard constraints. Exploratory tasks can keep more room for inference, while high-risk tasks should have explicit limits.

4. Evaluation Case: Specification Gaps and Misjudgment

Judging whether a model output is “aligned” depends on whether the evaluation standard itself is complete. A large model developer has publicly described a case that illustrates this point.

In an airline ticketing evaluation task, the prompt asked the model to handle a request to change an economy-class ticket. The benchmark’s expected answer was a direct refusal. The model did not refuse. Instead, it found a path permitted by the rules: first upgrade the cabin class, then process the change. Under the evaluation standard, this solution was marked as a failure. The developer’s analysis argued that the path is valid under the task’s original rules, so the failure stems from the benchmark specification not covering a legal sequence of operations, rather than from a problem with model alignment.

This case shows a common problem in evaluation design. Evaluation standards often record only one “standard answer,” but real rules usually allow multiple legal paths. If the scoring logic treats one path as wrong by default, it marks compliant reasoning as a failure, which can then mislead model training and capability assessment.

5. Engineering Recommendations

To address these issues, teams designing prompts and evaluation systems can apply the following practices:

Define four parts for each task: goal, constraints, default assumptions, and output format. Avoid relying on a single sentence as the instruction.
Set hard constraints for high-risk operations. Keep room for inference in exploratory tasks, and note the basis for inferences in the output.
Allow the model to ask clarifying questions when key information is missing, and count “reasonable clarification” as a valid result in evaluations.
When designing evaluation sets, enumerate the legal paths under the task’s rules, define the permitted sequences of operations, and record the basis for scoring.
Review disputed scoring cases manually, and distinguish between “insufficient model capability” and “incomplete specification” as failure types.
Keep collecting failure cases, and regularly check whether evaluation standards match business rules.