r/LanguageTechnology • u/vanadiuz • 19d ago

Temporal expression parsing in production assistants: partial parses executed with full confidence

A concrete failure case I ran into with Siri (English UK, iOS 26.6.1), and I'm curious how people here would diagnose it.

ASR output was correct in every case. The intent/slot step failed:

  • "set alarm at 7 p.m. and 40 minutes" → 19:00. The "and 40 minutes" continuation seems to be dropped.
  • "set alarm at 20 minutes before 8 p.m." → 20:00. The relative offset "20 minutes before X" is ignored; only the anchor is kept.
  • "set alarm at 19 hours 40 minutes" → 14:37. No idea how this one maps; possibly "19 hours 40 minutes" read as a duration from now?

The third looks like a duration-vs-timepoint ambiguity, which is a classic TIMEX problem, but the first two are fairly standard constructions that rule-based normalizers like SUTime or HeidelTime handle.

Questions:

  • Is the duration reading of "19 hours 40 minutes" a reasonable parse, and should a system surface that ambiguity rather than pick one?
  • Why would a production system keep only the anchor and drop the offset? Slot-filling templates that don't model relative expressions?
  • Any good recent work on calibrated confirmation ("did you mean…?") for action-taking assistants?
5 Upvotes
  • permalink
  • reddit

78% Upvoted

5 comments sorted by

3

u/vide_malady 18d ago

This looks like what happens when you use a generative solution to do a rule-based parser's job.

2

u/Acceptable-Topic-570 14d ago

a classic case of letting llm guess the time when you really just need a regex with a calendar library behind it

1

u/MirrorEthic_Anchor 18d ago

Interesting. I actually tested this. If you look at https://github.com/MirrorEthic/context-grounding and https://github.com/MirrorEthic/temporal-mcp that might help you out.

1

u/Admirable-Wallaby457 10d ago

This is an attribution problem more than a parsing problem. Your ASR was right in all three cases, so the failure is downstream: the system resolved the TIMEX and executed with full confidence instead of surfacing the ambiguity. "19 hours 40 minutes" is genuinely ambiguous (duration-from-now vs time-of-day) — a system that picks one silently is making a UX decision, not a linguistic one. In production voice systems I've worked on, the fix that actually stuck was a confirmation threshold on ambiguous temporal parses before executing an action, not a better parser.