Skip to content

Evaluating the accuracy of AI recommendations

An LLM can be fluent, confident, and wrong. This article shows how to judge an AI recommendation on evidence — grounding, technical validation, and measurement — before you act on it against a production network, and how to track an AI feature's accuracy over time instead of trusting it on faith.

Confidence is not correctness

The single most important mindset is that an LLM's fluency says nothing about its correctness. A chat model does not "know" it is right; it predicts plausible text one token at a time. That makes it entirely possible to get a perfectly phrased, authoritative-sounding answer that references a deprecated command, an interface that does not exist, or a change that is syntactically valid but operationally harmful. The polish is not evidence. This failure mode is common enough that it has a name in the OWASP Top 10 for LLM Applications — LLM09:2025 Misinformation — whose core warning is that trouble starts when an application treats model output as verified fact without a validation or review gate.

So evaluation has to rest on evidence, not on the model's tone. There are two distinct jobs: judging a single recommendation before you act on it, and measuring an AI feature repeatedly as prompts, models, and data change.

Evaluating a single recommendation

Before an AI-suggested change touches a device, run it through the same gates you would apply to any human-written change, plus a couple specific to generated output:

  • Ground it against the source of truth. Check the stated facts — IPs, VLANs, interface roles — against your source of truth (NetBox/Nautobot) and the live device state. The recommendation is a claim; the source of truth is the fact.
  • Validate it technically. Lint and syntax-check the output, dry-run it (ansible-playbook --check, terraform plan), and prove it in a lab with Cisco Modeling Labs before any production touch.
  • Verify it with pyATS. Snapshot operational state, apply the change in the lab, snapshot again, and diff to confirm it did exactly what was claimed — and nothing else.
  • Have a human expert review it. A domain engineer judges whether the change is sound and safe. Model confidence is not a substitute for that judgment.
  • Ground with retrieval. Supply the authoritative documentation or data in context and check that the answer cites and matches it (more on this below).

"Accuracy" is not one property, either. When you judge a recommendation, check several dimensions — a change can be factually right and still unsafe:

Dimension The question to ask
Factual correctness Are the stated IPs, VLANs, and commands actually true against the source of truth?
Completeness Did it omit a necessary step — a missing no shutdown, an absent return route?
Safety Could it cause an outage or open a security hole, even if technically "correct"?
Currency Is it using current platforms and commands, not ones deprecated after the model's training cutoff?
Relevance Does it answer the question actually asked, for the right device and context?

Grounding is the highest-leverage technique

The most effective single thing you can do to improve accuracy is grounding: give the model the authoritative facts it needs in context instead of letting it rely on training memory. For network automation that means feeding it the source-of-truth record and the live device state for the question at hand, and instructing it to answer only from that. A grounded answer is both more accurate and checkable — you can compare it against the very data you supplied.

The difference is concrete. Asked "what is r1's loopback IP?", an ungrounded model may pattern-match a plausible-looking address from its training data. A grounded agent first calls a tool to read the live config or the NetBox record, then answers from that fact — turning a guess into a citation you can verify against the same source.

This is the idea behind retrieval-augmented generation (RAG): retrieve authoritative source material and inject it into the prompt so the model answers from it. RAG measurably reduces hallucination, because any claim not supported by the retrieved context is, by definition, a hallucination you can detect. It does not eliminate the problem — retrieval quality matters, and grounding on the wrong document grounds the model on wrong facts — but it narrows the gap the model has to fill from memory.

Measuring an AI feature over time

Checking one answer is not enough for a capability you use repeatedly, such as a conversational agent. To judge it over time, build an evaluation set: a collection of representative questions paired with known-correct answers (ground truth). Run the AI against it, measure the score, and track that score every time a prompt, model, or data source changes. It is a regression test suite for AI.

# a tiny evaluation harness: questions with known-good answers
eval_set = [
    {"q": "What VLAN is SALES?",               "expected": "10"},
    {"q": "Is Gi1 on r1 routed or switched?",  "expected": "routed"},
]

correct = 0
for case in eval_set:
    answer = ask_ai(case["q"])             # your agent / model call
    if grade(answer, case["expected"]):    # exact or semantic match
        correct += 1

accuracy = correct / len(eval_set)
print(f"accuracy: {accuracy:.0%}")

A few practices make this hold up in production:

  • Track the right metric. Report accuracy on the eval set; for classification-style tasks (is this interface routed or switched?), track precision and recall so a model that is right-but-incomplete does not hide behind a single number. Watch the trend across versions, not just today's value.
  • Keep golden/regression sets. Hold a fixed set of cases so that a prompt tweak or a model upgrade cannot silently regress quality. A model that scored well last month can quietly get worse after an "upgrade"; running the set on every change turns quality into a tracked metric rather than an assumption.
  • Use LLM-as-judge with caution. Another model can help grade open-ended answers, but validate the judge against human labels before you trust it, and be aware of its known biases — judges favor the first option, longer answers, and outputs from their own model family (Zheng et al., 2023). Pin the judge to a fixed model so a judge change cannot masquerade as a quality change. Never treat the judge as ground truth.
  • Watch for stale knowledge. A model's training cutoff means it may not know new platforms or commands. Ground it against current data rather than relying on what it remembers.

Pair this measurement with the validation gates from your pipeline — lint, dry-run, CML, pyATS — so AI quality is something you verify continuously, exactly as you would the correctness of any other automation code.

Key takeaways

  • Fluency is not correctness. An LLM predicts plausible text and can be confidently wrong, so evaluate on evidence, never on tone.
  • For one recommendation: ground it against the source of truth and live state, validate it (lint, dry-run, CML), verify it with a pyATS diff, and have a human review it. Check factual correctness, completeness, safety, currency, and relevance.
  • Grounding is the highest-leverage fix. Supply authoritative data in context and have the model answer from it; RAG reduces hallucination and makes answers checkable against their sources.
  • For an AI feature: build an evaluation set with ground-truth answers and measure accuracy over time. Keep golden/regression sets, use LLM-as-judge cautiously, and watch for stale training knowledge.
  • Trust is earned by measurement, not asserted by confidence — the same validation discipline that makes any change safe is what makes an AI recommendation safe to rely on.