Skip to content
Notifications
Clear all

Where to start if I want to test its accuracy on highly technical documents?

1 Posts
1 Users
0 Reactions
0 Views
(@infra_skeptic_9)
Reputable Member
Joined: 5 months ago
Posts: 158
Topic starter   [#21511]

Alright, let's cut through the usual "it's magical!" marketing fluff. We've all been burned by an AI confidently hallucinating API endpoints that don't exist or inventing configuration syntax that would bring down a production cluster. So, before I even consider letting something like NotebookLM near our internal architectural docs or post-mortems, I need a rigorous, cynical test plan.

My starting point is a corpus of documents where I already know the ground truth. I'm thinking of three tiers:
1. **Public, complex technical specs:** I'll feed it something like the AWS IAM JSON policy grammar reference or a Kubernetes API deprecation guide. I'll ask it to generate a valid policy or manifest based on specific, nuanced constraints from the doc. The failure mode here is subtle: will it correctly handle condition keys or API versions, or will it quietly make up plausible-sounding nonsense?
2. **Internal runbooks with known errors:** I have a few old, intentionally flawed Terraform modules (like a misconfigured `aws_subnet` resource) and their accompanying post-mortem analysis. The test is whether it can, when asked specific questions about the failure, correctly identify the root cause *by citing the exact lines and concepts from the post-mortem*, not by generating a generic "here's a common networking error" answer.
3. **Dense code/configuration combinations:** A documented CI/CD pipeline using GitHub Actions with specific security hardening steps. I'll ask it to modify the pipeline for a new use case while preserving all security controls. The key is to see if it understands the *interdependencies* spelled out in the docs, or if it just does a naive text splice that breaks the entire context.

The real metric isn't if it gets it right when the document is simple. It's how it fails when the document is complex. Does it admit uncertainty, or does it dress up a hallucination in convincing technical jargon? I want to see its confidence scoring and source anchoring under pressure.

I plan to run these tests next week. If anyone has already performed similar sanity checks on their own arcane infrastructure docs, I'm all ears. What were your failure modes? Did you find it was actually referencing the provided source, or was it quietly supplementing with its general (and often outdated/wrong) training data for our field?

-- cynical ops


Your k8s cluster is 40% idle.


   
Quote