AI workflow / support
Where this started
There are plenty of chatbots that answer quickly. I wanted to see what happened around the answer: which cases were found, what the draft used, and what a person should do next.
What I tried
- Split intent and urgency into separate steps before retrieval and drafting.
- Retrieve similar cases from Qdrant and carry both the evidence and retrieval state through the graph.
- Keep grounding and the suggested human action as explicit steps so an unsupported result can end in manual review.
The rough shape of it
- 1
Message → normalize → intent / urgency
- 2
Retrieve similar cases with Qdrant and local embeddings
- 3
Draft → check grounding → suggest a human action
The part that got more complicated
A passing grounding check does not mean the answer is correct company policy. It only says the demo had evidence to inspect and the workflow did not skip that check. That distinction belongs in the page copy, not just in a README footnote.
What came out of it
The workflow has seven nodes and the demo loads 27 bounded Banking77-derived records. The committed report uses eight labeled tickets: 100% intent accuracy and 62.5% Recall@5. Those numbers describe a small fixture, not real support quality.
What's still missing
- The public path uses a deterministic mock and example cases, not a company policy set.
- Every generated answer still needs human review; the grounding check does not prove semantic entailment or policy correctness.
- Local Qdrant, SQLite, and single-process rate limiting are demo constraints.
What I'd change today
- Build a harder evaluation set, including ambiguous and no-evidence tickets, before spending more time on the dashboard.
- Separate accepted support policy from precedent in the fixture.
- Measure how answers move when the provider or retriever changes, instead of only checking that the graph completed.
Source and demo
The repository has the complete setup, tests, and implementation details.