判斷何時不應使用 LLM 的實用框架

Not every software problem needs a large language model (LLM). If a task can be solved reliably using deterministic rules, SQL queries, standard APIs, search algorithms, or traditional machine learning, adding an LLM may increase cost, latency, security exposure, and maintenance complexity without improving the outcome.
Engineering leaders should avoid using an LLM when the system requires exact calculations, predictable outputs, strict execution guarantees, very low latency, or decisions that cannot tolerate unverified results.
Evaluate five factors before selecting an LLM: task complexity, correctness requirements, latency, total operating cost, and operational risk. Use an LLM when understanding or generating flexible natural language creates measurable value that simpler technologies cannot provide efficiently.

1. Start by Identifying the Actual Engineering Problem

One common architectural mistake is selecting the technology before defining the task. Invoice processing, for example, involves document extraction, field validation, tax calculations, purchase-order matching, discrepancy detection, and approval. Those operations do not necessarily require the same technology.
Document extraction might benefit from OCR, document AI, or an LLM when layouts are highly variable. Tax calculations should use deterministic business logic. Purchase-order matching can use queries and predefined rules. Unusual discrepancies may require statistical anomaly detection or human review.
Ask first: Does this task require language understanding or generation, or does it simply require executing known business logic? If the answer is known business logic, start with conventional software.

2. Seven Situations Where You Should Not Use an LLM

When the output must be mathematically exact

Financial reconciliation, tax computation, inventory balances, and contractual pricing should rely on validated algorithms and appropriate numerical representations. An LLM can interpret a request, but calculations should remain deterministic.
from decimal import Decimal

def calculate_discount(price, rate):
price = Decimal(str(price))
rate = Decimal(str(rate))
if price < 0 or not 0 <= rate <= 1:
raise ValueError("Invalid price or discount rate")
return (price * (1 - rate)).quantize(Decimal("0.01"))

print(calculate_discount("250.00", "0.15")) # 212.50

Use instead: Validated business logic, decimal arithmetic, calculation libraries, or specialized numerical systems.

When the workflow follows clearly defined rules

A refund policy with explicit eligibility periods, excluded categories, and approval thresholds is better represented as a rules engine or conventional application logic.
def refund_decision(days_since_purchase, amount, eligible):
if not eligible or days_since_purchase > 30:
return "reject"
if amount > 500:
return "manual_review"
return "approve"

This simplified example is not a complete refund policy. A production system would also need authentication, transaction validation, fraud controls, and audit records. Use instead: Rules engines, state machines, or workflow orchestration.

When latency requirements are extremely strict

LLM inference can add network, input-processing, generation, and tool-call delays. It may be inappropriate for industrial control loops, low-level network packet handling, high-frequency transaction processing, and safety-critical device control. Use instead: Optimized algorithms, embedded logic, or specialized low-latency models with measured timing guarantees.

When the answer already exists in structured data

If revenue figures already exist in an authoritative database, query that system directly rather than asking a model to generate the result.
SELECT SUM(amount) AS total_revenue
FROM paid_invoices
WHERE paid_at >= '2026-09-01'
AND paid_at < '2026-10-01';

This query assumes revenue means paid invoice amounts; financial reporting may require different accounting definitions. An LLM may translate a user question into a constrained query, but authorization and aggregation should remain under application control.

When sensitive data cannot be processed under the proposed architecture

Do not introduce an LLM if the implementation cannot satisfy data handling, retention, access control, and deployment requirements. Private deployments and governed managed services can support sensitive workloads, but controls must be demonstrated. OWASP identifies prompt injection and sensitive information disclosure among important LLM application risks.

When a specialized model solves the task more efficiently

Fraud detection, demand forecasting, defect classification, anomaly detection, and predictive maintenance may be better served by statistical methods or task-specific machine learning. An LLM can explain the result without generating the underlying prediction. Compare approaches on representative data.

When you cannot evaluate whether the model is correct

Do not approve autonomous production use without representative test cases, defined unacceptable outcomes, and an evaluation or review mechanism. A controlled prototype or human-reviewed workflow is preferable until measurable acceptance criteria exist.

3. LLM vs. Traditional Software vs. Machine Learning

Requirement
Usually preferred approach
Reason
Exact arithmetic
Deterministic code
Defined, testable numerical behavior
Business rule enforcement
Rules engine
Predictable and auditable decisions
Structured data retrieval
SQL or APIs
Authoritative records
Keyword or exact-match search
Search engine
Efficient retrieval without generation
Demand forecasting
Statistical or ML models
Optimized for prediction
Flexible document summarization
LLM
Variable natural language
Semantic document discovery
Embeddings and retrieval
Conceptually related content
Natural-language interface
LLM plus controlled tools
Intent translated into validated operations
High-risk automated actions
Deterministic controls and oversight
Permission and execution boundaries

These are starting points, not universal rules. Benchmark against your own acceptance criteria.

4. Calculate the Real Cost of Using an LLM

Total Cost of Ownership = Development + Infrastructure + Inference + Evaluation + Monitoring + Maintenance + Exception Handling.
Cost per successful task = Total operational cost / Successfully completed tasks.
Consider a hypothetical workload of one million requests per month:
Metric
Deterministic service
LLM-based service
Cost per attempt
$0.001
$0.02
Monthly attempts
1,000,000
1,000,000
Direct processing cost
$1,000
$20,000
Successful task rate
99.9%
97%
Direct cost per successful task
~$0.001
~$0.0206

Illustrative scenario only, not observed vendor prices or published benchmarks. The systems may solve different problems, and a deterministic service might not handle some language-intensive tasks. Compare time to deployment, cost per completed task, failure rates, review requirements, maintenance, monitoring, and security overhead.

5. A Five-Gate Framework for Deciding Whether to Use an LLM

Gate 1: Is language intelligence actually required?

If the task does not require flexible language interpretation or generation, begin with deterministic software.

Gate 2: Can a simpler solution meet the requirements?

Benchmark rules, search, APIs, or specialized ML. Do not compare an LLM only against doing nothing.

Gate 3: Can the system tolerate probabilistic behavior?

Define how incorrect, incomplete, or inconsistent results are detected and handled.

Gate 4: Does the LLM satisfy operational constraints?

Test latency, throughput, cost, availability, privacy, and security under realistic workloads.

Gate 5: Does the additional capability justify the complexity?

Approve the LLM only when its benefits are material and risks can be managed.
Decision flow: Require language intelligence? If no, use deterministic software. If yes, benchmark simpler alternatives. If a simpler option meets acceptance criteria, prefer it. Otherwise, test error containment, operational constraints, and measurable incremental value before approving controlled LLM implementation.
This five-gate framework is a proposed engineering method, not an externally validated standard.

6. Engineering Example: Routing Customer Support Requests

A SaaS platform needs to route requests such as duplicate charges, account-email changes, and API errors. Three architectures are possible.

Option A: Rule-based routing

def route_ticket(message):
text = message.lower()
if "charged twice" in text or "duplicate charge" in text:
return "billing"
if "change email" in text or "update email" in text:
return "account"
if "api error" in text or "api is returning errors" in text:
return "technical"
return "manual_review"

This is transparent and testable but has limited coverage when customers use unexpected wording or describe multiple issues.

Option B: LLM-based routing

An LLM can interpret varied expressions, but adds inference costs, model evaluation, output validation, and additional failure modes.

Option C: Hybrid routing

Use explicit rules for well-defined requests, a lightweight classifier for common variations, an LLM for ambiguous language, and human review for low-confidence or high-impact cases. The routing policy remains under application control.
Compare classification precision and recall, misrouting rate, manual-review rate, P95 latency, cost per correctly routed ticket, and maintenance effort. A hybrid system is preferable only if it provides measurable benefits.

7. Use LLMs at the Boundaries, Not Everywhere

Separate language interpretation from authoritative business execution. An LLM can translate intent into a structured request; deterministic services should validate schemas, enforce permissions, apply business rules, and execute critical operations.
User request
|
LLM interprets intent
|
Structured request
|
Schema validation
|
Authorization + business rules
|
Deterministic API execution
|
Verified result
|
User response

Structured outputs can constrain response format, but valid syntax does not guarantee correct interpretation or authorized execution. This is especially important for AI agents connected to enterprise systems.

8. Questions Every Engineering Leader Should Ask Before Approving an LLM

Problem definition: What requires an LLM, and what alternatives were considered?
Baseline: How well does the strongest non-LLM approach perform?
Quality: What dataset and metrics evaluate correctness?
Reliability: What happens if the model fails or returns invalid output?
Security: Can the model access or change anything beyond user authorization?
Performance: What are P50, P95, and P99 latencies under load?
Economics: What is the cost per successful business task?
Ownership: Who maintains prompts, datasets, configurations, and monitoring?
Change management: How will model and data updates be retested?
Exit strategy: Can the model be replaced without redesigning the application?

Frequently Asked Questions

When should you avoid using an LLM?

When simpler approaches meet the requirements with less complexity, or when critical model errors cannot be detected, contained, or reviewed.

Are LLMs better than traditional machine learning?

Not universally. LLMs suit flexible language tasks, while specialized models may be more efficient for structured prediction and forecasting.

Should LLMs be used for business logic?

They can interpret requests, but authoritative rules, calculations, permissions, and transactions should generally remain deterministic.

Can an LLM replace SQL queries?

It can translate natural language into a validated query, but the database should execute structured retrieval and aggregation.

When is a hybrid AI architecture appropriate?

When flexible language interpretation adds value but critical steps need predictable execution and strong controls.

How can CTOs justify rejecting an LLM-based solution?

Use comparative evidence that a simpler architecture meets quality, latency, security, and operational requirements at lower total cost.

Conclusion: The Simplest Reliable Architecture Should Win

The decision to use an LLM should be based on engineering requirements, not technology momentum. Large language models can provide valuable capabilities for flexible language and unstructured information, but they are not the right answer to every software problem.
Before introducing an LLM, establish a non-LLM baseline, define measurable acceptance criteria, and test whether the model delivers enough additional value to justify its cost and risk.
A useful rule for architecture reviews: If removing the LLM does not materially reduce the system’s ability to meet its requirements, the LLM probably does not belong in the critical path.
The goal is to build the simplest system that reliably delivers the required business outcome.