I'm building conflict detection for a retrieval-augmented knowledge base containing facts such as fees, deadlines, and eligibility criteria gathered from many institutions. I want to normalize each fact into a deterministic attribute tree—for example, program=BHM, category=General, year=2026-27, fee=₹150000—so equivalent facts from different documents can be compared and contradictions flagged.
Tables, labeled fields, question-and-answer pairs, and headed sections are straightforward. I can preserve their structure during ingestion and use parsers and regular expressions. The difficult case is unlabeled prose, such as: "Students from the general category are required to pay ₹1,50,000 for the 2026-27 academic year for the BHM programme." The fee, category, year, and program are related by sentence meaning rather than explicit delimiters.
I'm looking for classical or pre-LLM approaches that work across varied wording: dependency parsing, rule-based information extraction, Open Information Extraction, semantic role labeling, CRF or other trained taggers, or useful Python libraries. A small local model is acceptable, but I do not want live hosted LLM inference because of cost, latency, reproducibility, and determinism. The goal is a practical pipeline for extracting a small set of known-shaped facts and their qualifiers from messy prose, while keeping simpler documents on regex and structural parsing.
2 Answers
There probably isn’t a single deterministic technique that will reliably understand arbitrary prose without some form of learned semantic model. A practical design is to use a layered pipeline: handle tables, labels, headings, and obvious patterns with structural parsing and regular expressions, then send only the unresolved sentences through a local extractive model or trained tagger. This keeps the cheap, predictable path for most documents while limiting the less deterministic component to difficult cases.
It also helps to treat extraction as a verification problem rather than asking a system to invent a complete fact. First identify the relevant sentence, then ask targeted questions such as “Where is the fee for the BHM program and General category?” and return an exact span from the source. The returned amount, date, and entity names can then be validated with strict parsers and checked against the original text. A small span-extraction model from a local NLP stack can do this without generating new prose or calling a hosted service.
For a fully symbolic system, dependency parsing can help connect a monetary amount to its governing verb and nearby modifiers, while named-entity recognition can locate currencies, dates, organizations, programs, and categories. You can combine those outputs with a domain lexicon and dependency-path rules—for example, identify payment verbs, find their amount object, and attach noun phrases that modify the subject or occur in the same clause.
OpenIE can produce useful candidate relations, but generic triples usually won’t preserve the exact attribute structure you need, so it is better treated as candidate generation rather than the final representation. A domain-specific NER or sequence tagger trained with labels such as FEE, PROGRAM, CATEGORY, YEAR, and DEADLINE may generalize better than an ever-growing collection of sentence regexes. Whichever method you use, retain the source span, confidence, sentence, and document location so conflicting normalized facts can be reviewed and verified. There is an unavoidable tradeoff: broader coverage requires either more rules and training data or a learned semantic component.
The verify-instead-of-generate approach fits this well. Since the fields I need are already known—fee, deadline, program, category, and so on—I can check whether a value matching the expected pattern appears near the relevant qualifiers instead of trying to interpret every sentence from scratch. A local extractive QA model for the leftover prose seems like a useful compromise, while tables and labeled fields remain purely rule-based.