← WorkTotalEnergies OneTech · DataLab, Pau
The right value, for the right object: LLM extraction from industrial reports
Two-pass extraction guided by document structure, on self-hosted LLMs and GPUs, with an evaluation that separates identifying the objects from the quality of their attributes.
- Role
- MSc internship — HPC Data Scientist / Data Engineer
- Period
- 04 — 09 · 2026
- Status
- Evaluated prototype, candidate for integration
- Tools
- PythonvLLMMistral · Llama · GemmaGPU L40S / H100SLURMPydanticClearML
01Overview
End-of-well technical reports — text, tables, OCR scans, up to 175,000 tokens — must yield reliable metadata to index business objects in reference systems. A correct depth attributed to the wrong wellbore becomes a master-data error.
Final-year MSc internship at the TotalEnergies OneTech DataLab (Pau), inside an existing pipeline for batches of technical data. Open-weight models served on the company's GPU infrastructure, data processed inside its governance environment.
What I personally did
- 01Studied the limits of fixed-chunk and vector-similarity RAG on these reports.
- 02Adapted two-pass extraction to tree navigation of the document, with an identity constraint in the prompts.
- 03Modelled the business hierarchy — main well, wellbores, sidetracks, offset wells — to limit attribution errors.
- 04Integrated the validators, batch processing and experimental routing of steps between models.
- 05Built the L1 / L2 evaluation framework and the error analysis (missed, mis-identified, over-generated objects).
What isn't mine —The general principle of two-pass extraction existed in an earlier DataLab module. I don't claim to have invented the system: my contribution is its adaptation, identity handling and evaluation.
02Constraints
- Long, heterogeneous documents: text, tables, OCR scans of uneven quality, scattered information.
- Several objects per report, and “offset” wells cited as geological references without being the subject.
- Self-hosted open-weight models only, on shared GPUs (L40S, H100) scheduled by SLURM.
- Outputs a reference system can use: enforced structure, normalised values, provenance.
03Architecture
Q · Final depth of WELLBORE A-1?
§1 · Well A — summary
Final depth 2,450 m
§3 · Wellbore A-1 — deviated drilling
Final depth 2,980 m
§7 · Offset well B — geological reference
Final depth 3,105 m
Most similar chunk: §7
3,105 m
A plausible value… from another well.
- 01
Hierarchical index
Each Markdown report becomes a tree of sections, titles, summaries and identifiers — so the search is no longer blind.
- 02
Hybrid search, no vector index
LLM-guided selection over the tree, complemented by a lexical search for domain landmarks. “Vectorless” means no embeddings — not no lexical search.
- 03
Pass 1 · the objects
List the subject wells and wellbores, with their identifiers and role.
- 04
Pass 2 · their attributes
Extract attributes constrained by that list: a value can only belong to an identified object.
- 05
Checks and provenance
Deterministic normalisation and validation (Pydantic), role marker, source excerpt and review priority for the operator.
Conceptual view, deliberately simplified for external publication.
04Implementation decisions
- 01
Separate “who” from “what”
Classic RAG answers “what is the depth?” with a plausible value — sometimes another object's. Separating object detection from attribute extraction makes attribution errors visible and measurable.
- 02
Navigate instead of chunking
The report's structure carries information: the model picks branches of the tree instead of receiving fixed, context-free chunks.
- 03
Route each step to the right model
The best model at detecting objects was not the best at extracting attributes. A composite system assigns each step to the best-suited model, trading quality against inference time.
- 04
Make experiments reproducible
vLLM inference on SLURM jobs, validated structured outputs, campaigns tracked in ClearML: every number points back to a replayable configuration.
05Challenges
Several identifiers, several depths
One report scatters values for several objects across sections. Better prompting is not enough: the object list must be established, its hierarchy kept and the assignment checked.
Sidetracks
Deviated branches of a well remain hard to find: a documented limit, not a hidden one.
OCR quality
Some attributes are capped by the quality of the source text, whatever the model.
06Evaluation
Two levels, measured separately: L1, identifying a report's subject wellbores; L2, attribute quality on correctly matched objects. Missed, mis-identified and over-generated objects are tracked apart. Each configuration is compared on detection, attribute accuracy, latency and error analysis, over a corpus of annotated reports.
Not publishedDetailed scores and corpus size stay internal until the company approves their publication. I'm glad to walk through them in an interview, within that frame.
07Outcomes
- Processing time cut by 75% on the studied pipeline.
- Better coverage of some objects, notably in the multi-wellbore reports of the test corpus.
- An explicit detection / attributes / inference-cost trade-off, rather than a single score.
- Status: evaluated prototype, candidate for integration into an existing component. No standalone deployment is claimed.
Limits
- Under some counting conventions, detection precision stays below an embedding-based RAG.
- Some comparisons use different inference engines.
- No universal superiority of vectorless retrieval is shown — nor claimed.
08What I took from it
- 01Measure attribution, not just the value: that's where the expensive errors hide.
- 02There's no single “best” model when steps have different demands.
- 03Writing the limits in the same document as the results makes the results credible.
09Evidence
- Internship thesis (77 pp.) and Data Science Chapter talkInternal — viewable with the company's consent
- Recommendation letters from supervisorsOn request