Semantic similarity retrieves text that sounds relevant. Engineering retrieval must first resolve authorization, well and wellbore identity, time or depth, BHA, operating state, source authority, and freshness. RAG is therefore an evidence-routing problem in which semantic search is one bounded step, not the organizing principle.
Filter engineering scope before similarity
A semantic retrieval system essentially asks:
Which stored information is most similar in meaning to this query?
A drilling engineer often needs:
Which information belongs to this exact operational context?
Those are different questions. An engineer asks:
What happened when we increased flow in the lateral?
A semantic search may return excellent discussions of increasing flow from:
- several offsets,
- several BHAs,
- several hole sections.
But the requested evidence may specifically concern:
- the current well,
- BHA 4,
- the sidetrack,
- 16,000–17,000 ft MD,
- yesterday afternoon.
Semantic similarity does not inherently understand those constraints. A useful conceptual drilling hierarchy might look like:
$$Field \rightarrow Pad \rightarrow Well \rightarrow Wellbore \rightarrow BHA\ Run \rightarrow Depth/Time \rightarrow Event$$
Not every query needs every level, but the hierarchy matters:
Show me the torque behavior on the last BHA.
“Last BHA” is relative to:
- a well,
- a wellbore,
- a point in operational time.
Retrieving the most recently created BHA record globally would obviously be wrong. The entity context has to be resolved first.
Engineering identity is resolved through field, pad, well, wellbore, BHA, depth, time, and operational event before semantic ranking.
A strong architecture applies deterministic constraints before semantic ranking:
- Resolve well, wellbore, BHA, time/depth, and operation.
- Restrict candidate evidence to that scope.
- Rank the remaining notes, reports, and documents by semantic relevance.
This changes the retrieval problem from:
$$Search(All\ Knowledge)$$
to:
$$Search( Knowledge \mid Engineering\ Context )$$
The conditioning makes the result engineering-specific.
Structured filters constrain engineering scope while structured queries and semantic document search retrieve different evidence types for synthesis.
Route each question to the right evidence
Not every drilling question is a document-search problem:
| Question | Required route |
|---|---|
| What is current hole depth? | Current structured record |
| Average rotary torque through the last 500 ft? | Structured time/depth query with rig-state filtering |
| What did the report say about the tight spot? | Document retrieval |
| What is modeled ECD at current flow? | Deterministic engineering calculation |
| Is the torque increase mechanical or geological? | Multi-source reasoning |
Routing occurs before language-model reasoning. “RAG system” can therefore undersell what a serious engineering assistant needs. For the question:
What is the expected standpipe pressure at the current flow rate?
The system might retrieve:
- current flow,
- mud properties,
- BHA geometry,
- hole geometry.
But the answer itself should come from an engineering calculation. RAG retrieves the inputs. The physics model computes the result. The language model explains it. Conceptually:
$$Retrieve \rightarrow Calculate \rightarrow Interpret$$
not:
$$Retrieve \rightarrow Ask\ LLM\ to\ Guess$$
Preserve authority, freshness, and provenance
Four sources contain mud weight:
- Well plan: 11.6 ppg.
- Yesterday's DDR: 11.8 ppg.
- Current mud report: 12.0 ppg.
- Engineering note: “Plan to increase to 12.1 ppg.”
Which one answers:
What are we running now?
Not necessarily the one with the greatest semantic similarity. The system needs a concept of source authority. For current actual mud weight, the authoritative source may differ from the source used for:
- planned mud weight,
- historical reasoning,
- management summary.
A RAG architecture should therefore preserve source type, source role, and freshness rather than treating every text chunk as interchangeable evidence. If the current mud database was last updated six hours ago and a newer field report says the system was weighted up, the stored value remains historically valid but may no longer describe the current state.
A useful answer should distinguish:
Latest available structured mud weight is 11.8 ppg, last updated six hours ago.
from:
Current mud weight is 11.8 ppg.
Those sentences sound similar. Their epistemic meaning is very different. Every retrieved piece of evidence should ideally retain:
- source,
- well,
- wellbore,
- time,
- depth where applicable,
- author or system,
- data type,
- freshness.
Then the final answer can trace its reasoning back to the evidence. This makes the system easier to:
- audit,
- troubleshoot,
- trust.
Without provenance, a fluent answer becomes difficult to verify.
Constrain synthesis and access
Once reliable evidence has been assembled, the LLM becomes extremely useful. It can:
- connect observations,
- summarize reports,
- compare evidence,
- explain calculations,
- identify contradictions,
- state uncertainty.
The LLM is not necessarily the best component for:
- identifying the current well,
- performing exact depth filtering,
- selecting the authoritative current mud-weight record.
Those are better solved deterministically. This is the same architectural philosophy established in the deterministic-calculation article:
Use each computational method for the part of the problem it is good at.
A weak approach may construct a large prompt such as:
You are looking at Well A, sidetrack 2, BHA 5, at 14,200 ft...
That is better than no context. But if the retrieval system itself does not use those fields, it can still retrieve evidence from:
- another well,
- another BHA.
The LLM is then asked to notice the mismatch afterward. A stronger architecture applies context before retrieval. The model should never have to choose between:
- perfectly relevant evidence from the wrong well,
- slightly less similar evidence from the correct well.
The wrong-well evidence should never have entered the candidate set. If an AI assistant supports several operators, a semantically ideal document in another customer's dataset must not be retrieved. Authorization is applied before retrieval. Conceptually:
$$Candidate\ Evidence = Authorized \cap Contextually\ Valid \cap Relevant$$
This is not merely a security feature. It is part of retrieval correctness. The assistant should reason only over information the user is allowed to access. Two reports may contain nearly identical wording:
High torque observed in lateral; worked pipe and circulated.
One is:
- same formation,
- similar BHA,
- neighboring pad.
The other is:
- another basin,
- different hole size,
- very different BHA.
Semantic similarity might rank them equally. Engineering similarity should not. This suggests a more useful retrieval score conceptually:
$$Score = f( Semantic\ Similarity, Engineering\ Comparability )$$
The exact implementation may vary. The principle should not.
A practical drilling retrieval architecture
A defensible workflow has six stages:
- Apply authorization before any retrieval.
- Resolve field, pad, well, wellbore, BHA, time/depth, formation, and operational state as required.
- Classify the request as measurement, historical query, calculation, document retrieval, or multi-source reasoning.
- Retrieve exact structured data deterministically and use semantic search only for relevant text.
- Verify source authority and freshness; preserve measured, calculated, retrieved, and inferred provenance.
- Let the LLM synthesize what the evidence shows, what it does not show, and where uncertainty remains.
Evaluate context, routing, and abstention
Typical chatbot evaluations are not sufficient. A drilling retrieval system should be tested for engineering failure modes:
- Correct-well retrieval: Did every cited piece of evidence belong to the intended well?
- Correct-wellbore retrieval: Did sidetrack and original-hole evidence remain separated?
- Depth correctness: Was the retrieved interval actually relevant to the requested depth?
- Temporal correctness: Was the evidence valid at the requested time?
- Source correctness: Was planned information accidentally presented as actual?
- Freshness: Did the system detect stale current-state information?
- Calculation routing: Were deterministic engineering questions calculated rather than generated?
- Provenance: Could every claim be traced to measurement, calculation, document, or inference?
- Abstention: Did the system report insufficient evidence when required context was unavailable?
These metrics are closer to engineering reliability than generic answer-similarity scores. AIDE provides a practical example of this architecture. At a high level, the DrillingMetrics implementation connects a language model to:
- authorized real-time drilling data,
- historical wells,
- operational reports,
- domain knowledge,
- deterministic engineering calculations.
The system is designed so that:
- measured data,
- calculated results,
- inferred outputs
remain distinguishable. That distinction is important because a useful drilling assistant should not treat all evidence as equivalent text. The language model is the reasoning and communication layer. The underlying engineering systems determine:
- which well,
- which data,
- which calculation,
- which historical evidence.
That is a fundamentally different architecture from simply placing thousands of drilling PDFs into a vector database.
AIDE uses current-well evidence to separate a slide-driven stand-average decline from the underlying rotary-drilling performance.