A client came to me with a catalog of unstructured biographical data for a specialty directory. Ten thousand records of raw, messy text that had to end up as a clean knowledge graph. My first instinct was to pipe the whole lot through a GPT-4o script and call it a day. Then I added up the API cost and looked at the latency for a background process running on a standard VPS, and the plan fell apart. Using a massive LLM for simple structured data extraction is like bringing a rocket launcher to a fistfight. It costs a fortune, and it is lazy engineering.
I tried the old-school route first, with SpaCy and a pile of custom regex. It went badly. The text varied too much, and the relationship mapping turned into a brittle stack of if-else branches. So I switched to GliNER2, the successor to the original GliNER model. It runs on a CPU, it does entity recognition and relationship extraction in the same model, and it will not eat your budget in monthly API charges.
Why GliNER2 works for structured data extraction
The difference is that you declare a schema instead of hoping a prompt sticks. You name the entities you want (People, Locations, Inventions) and the relationships between them (Parent of, Worked on), and the model fills them in. Same discipline I use for performance troubleshooting: define the constraints, then measure the output instead of guessing at it.
The extract_json method is what sold me. It pulls structured JSON straight out of the text, with none of the “reasoning” overhead that makes an LLM slow, which matters a lot inside an ingestion pipeline. The model is small and specialized, and as long as you keep it in its lane it hallucinates far less than the big generalists.
/**
* Example of defining a multi-task schema in GliNER2
* This approach prevents the 'over-engineering' trap.
*/
schema = (extractor.create_schema()
.entities({
"Person": "Names of people and nobility titles.",
"Invention": "Mechanical or technological creations.",
})
.relations({
"invented": "A person created or proposed an invention",
"worked_on": "A person contributed to an invention"
})
.structure("person")
.field("name", dtype="str")
.field("birth_date", dtype="str")
)
# bbioon_execute_extraction handles the heavy lifting
results = extractor.extract(raw_text, schema)It is not perfect. In my testing it struggled with anything that needed real inference, like working out gender from the word “daughter” when nothing else in the record spelled it out. But for plain structured data extraction, moving data from A to B without wrecking the budget, nothing else I tried came close. Anyone who read my pragmatist’s manifesto already knows where I land on efficiency versus hype.
Break the LLM over-engineering habit
Building a knowledge graph, or just cleaning up a messy WordPress database, does not have to start with the most expensive tool in the shed. A small focused model handles named entity recognition and hierarchical extraction with high precision. The full technical detail is in the official GLiNER2 paper, and the code sits in their GitHub repository.
Data pipelines get complicated fast. If you are tired of debugging someone else’s mess and you just want the thing to run, send me a message. I have probably hit the same headache already.
Where GliNER2 pays off
- It runs on a CPU, so there is no GPU cluster to rent or babysit.
- One pass covers NER, classification and relationships rather than three separate models.
- On bulk work it is cheaper and quicker than sending everything to GPT-4 or Claude.
If you are still paying five figures a month for API calls a small encoder model could handle in-house, your stack is worth a second look.
