In August 2023, a client asked me to build a model that could extract age from Instagram bios.
The examples made the real problem clear. A bio might say “25 yo”, “32”, or “1995”. But it might also say “married in 2018” or “moved to the city in 1999”. The system had to recognize the first group without confidently turning every four-digit number into a birth year.
That is not just a number-extraction task. It is a context problem.
A regular expression finds candidates, not answers
A regular expression can quickly find 25, 1995, or 2018. That is useful, but it only produces candidates.
The next questions are semantic:
- Is this number explicitly connected to age?
- Is a four-digit value a birth year, an anniversary, or an event date?
- Does the surrounding phrase support the interpretation?
- Is there enough evidence to return an age at all?
The safest answer is sometimes “unknown”. In data extraction, abstaining is usually better than adding a plausible but false value to a profile.
Turn examples into test cases
Before choosing a model, I would still write the acceptance set in plain language:
| Bio fragment | Expected interpretation |
|---|---|
25 yo |
explicit age |
born 1995 |
birth year; calculate against a defined reference date |
class of 2018 |
not an age |
married since 2018 |
not an age |
32 |
ambiguous without more context |
This small table does more than a vague requirement such as “extract age”. It exposes the edge cases, gives the implementation something testable, and makes false positives visible.
A practical pipeline
For short, noisy text, I prefer a layered pipeline:
- normalize spacing, case, punctuation, and common age expressions;
- extract candidate ages and years;
- inspect nearby words and phrase structure;
- reject event dates and values outside agreed bounds;
- return the value together with a confidence or reason;
- keep an explicit “no reliable answer” outcome.
Depending on the available labeled data, the context step can be rules, a classifier, or a combination. The important design decision is not the fashionable model. It is preserving the distinction between a candidate and a verified interpretation.
What the client verified
The engagement was completed as a fixed-price Upwork project. The client left a 5.0 public review:
“I had the privilege of working with Mehmed on a recent project and his performance was nothing short of exemplary. His expertise, punctuality, and innovative thinking shone through in every aspect of his work. He maintained clear, timely communication and his commitment to exceeding expectations was evident. Mehmed’s results-oriented approach not only delivered top-quality work, but it also far surpassed my initial expectations. Looking forward to collaborating again in the future, I would highly recommend Mehmed for any project requiring in-depth knowledge, skill, and exceptional work ethic!”
That review confirms successful delivery, communication and client satisfaction. It does not provide a public benchmark, dataset size, production accuracy or downstream business result, so I do not invent those numbers here.
The broader lesson
Many data-quality problems have this shape. The raw value is easy to find; its meaning depends on context.
A clean table can still be wrong if 2018 is stored in an age column. Reliable extraction therefore needs more than parsing. It needs explicit definitions, negative examples, validation and permission to say “I do not know”.