Instruction Following vs. Intent Understanding: Two Paths to LLM Alignment

I. The Starting Point: One Model, Two Experiences

When deploying Large Language Models (LLMs) into specific products, users often share a similar experience: the model possesses broad knowledge and strong reasoning skills, yet sometimes feels less “human” in daily conversations. It may execute requests strictly according to literal wording while ignoring the true intent behind the prompt. Other models proactively fulfill unspoken user needs, providing a smoother experience, but occasionally overstep task boundaries. Behind these two behaviors lies a divergence in alignment philosophies.

This article breaks down this divergence from three perspectives: the essence of alignment orientations, the limitations of evaluation specifications, and actionable engineering practices.

II. The Nature of Two Alignment Approaches

Literal Execution (Rule-based Alignment) treats every user prompt as a complete contract. It requires clear input boundaries, comprehensive constraints, and upfront risk disclosures. The advantage is predictable behavior and easy auditing, making it suitable for error-sensitive scenarios like finance, healthcare, and permission management. The trade-off is equally clear: users bear the cost of expression. The more vaguely the prompt is written, the further the result deviates from expectations.

Intent Inference (Context-based Alignment) treats user prompts as descriptions of a goal, combining context, common sense, and history to fill in missing information. It lowers the barrier to usage and is suitable for tasks with higher fault tolerance, such as creative writing, consulting, and daily office tasks. The risk lies in uncertainty: inferences can be wrong, and overstepping boundaries becomes harder to detect in advance.

Neither approach is absolutely superior. A sound practice is to choose a position based on task risk: the higher the risk, the more it should lean toward literal execution and explicit confirmation; the lower the risk, the more freedom can be given to inference.

III. Separating “Obedience” from “Intelligence”

Model capabilities typically encompass two parts. First is cognitive ability, such as mathematical deduction, code review, and complex logical analysis. Second is interaction ability, such as understanding ambiguous needs, judging when to ask questions, when to execute directly, and how to organize concise and appropriate expressions. These two are often conflated. A model excelling in math problems does not necessarily mean it can accurately determine what a user wants to change when only told to “tweak this paragraph.”

Treating the strictness of instruction execution as a hallmark of intelligence introduces a hidden risk: to avoid errors, users are forced to write lengthy manual-like prompts. At this point, the model’s capability ceiling is actually limited by the user’s writing skills. Good alignment should reduce the user’s expression burden, not transfer it back to them.

A practical criterion is: when the model encounters an information gap, does it stop to ask, or proceed based on reasonable assumptions while clearly informing the user of what those assumptions are? The latter retains both efficiency and the opportunity for course correction.

IV. Evaluation Specs Can Also Be Flawed

Evaluation benchmarks are the yardsticks for measuring model capabilities, but the yardstick itself may be defective. Consider an evaluation task for flight rescheduling: the prompt asks the model to handle an economy class rescheduling request, and the designers expect the model to outright refuse. However, the model finds an alternative path within the allowed rules: it changes the cabin class first, then executes the rescheduling. According to the evaluation criteria, this solution is judged as a failure.

This case exposes a frequently overlooked issue: the specification did not enumerate all legal paths, and the scoring logic treated the “preset route” as the only correct answer. In such cases, what is judged as a failure might be the evaluation design, not the model’s alignment state.

For evaluation designers, the following tasks need to be implemented:

1. Exhaustively list compliant paths, including unexpected but legal alternative solutions, and specify them in the rules.
2. Distinguish between “compliant alternative solutions” and “boundary-crossing behaviors that circumvent constraints”—these two cannot be judged by the same rule.
3. Manually review failed samples, record reasons for dispute, and feed them back into specification revisions.
4. Allow multiple solutions for a single problem; base scoring on outcomes and constraint satisfaction, rather than whether the steps match the reference answer.

V. Engineering Practice: Encoding Trade-offs into System Design

5.1 Tiering Actions by Risk

Categorize model-executable actions by risk level, applying different strategies for different tiers:

from enum import Enum
class Risk(Enum):
    READ = "read"                    # Read-only query, can be executed directly
    WRITE = "write"                  # Reversible write, report assumptions after execution
    IRREVERSIBLE = "irreversible"    # Irreversible operation, user confirmation required
def decide(risk: Risk, assumptions: list[str]) -> str:
    if risk is Risk.READ:
        return "execute"
    if risk is Risk.WRITE:
        # List the assumptions upon which the execution is based for user correction
        return "execute_and_report: " + "; ".join(assumptions)
    return "ask_user_for_confirmation"

The focus of this code is strategic layering rather than implementation details. Read operations don’t bother the user, reversible writes are transparently recorded, and irreversible operations must be confirmed.

5.2 Distinguishing Hard Constraints from Soft Preferences

Split instructions into two categories:

• Hard constraints: Security boundaries, permission scopes, monetary limits, data retention requirements. These should be expressed as explicit rules and enforced at the system level, not relying on the model’s self-discipline.
• Soft preferences: Tone, length, formatting style, aesthetic tendencies. These can be expressed in descriptive language, allowing the model to make its own judgment within the scope.

If mixed into a single long prompt, the model will struggle to distinguish what can be flexibly handled from what cannot be compromised.

5.3 Having the Model Paraphrase Its Understanding

Before starting a complex task, require the model to paraphrase the task goal, key constraints, and pending confirmations in two or three sentences. This low-cost step can expose understanding gaps early. Users only need to confirm or correct, without rewriting the entire prompt.

5.4 Establishing a Root Cause Analysis Process for Failures

Every failure requires identifying the root cause: is it unclear prompt expression, insufficient model capability, or flawed evaluation criteria? The remediation methods for these three issues are completely different. Without root cause analysis, teams can easily attribute all problems to “the model isn’t obedient enough” or “the model isn’t smart enough,” leading to misguided optimization directions.

VI. Conclusion

LLM alignment is not a binary choice between “obedience” and “autonomy,” but a design trade-off between predictability and interaction efficiency. Literal execution guards the boundaries, while intent inference boosts efficiency; the two should be combined based on the scenario. Evaluations must also acknowledge their own limitations, separating “whether the model made a mistake” from “whether the standard was clearly defined.” Only in this way can the system remain under control without forcing users to bear the entire cost of expression for the model.