How I Turned Incident History into an Azure AI Search Knowledge Base

Start with the support problem

The starting point was simple: support teams often solve the same class of problem more than once, but the useful knowledge is trapped inside old incidents. I wanted a small implementation that made the previous root cause and resolution searchable from a short symptom phrase.

Model the incident for retrieval

I created a dedicated Azure AI Search index around the fields a support engineer actually needs: incident ID, Azure service, severity, reported issue, root cause, resolution and status. The dataset used 12 synthetic incidents across 12 Azure services so the behaviour could be tested without using customer information.

Test search with operational language

I used Search Explorer and the Streamlit interface to test short phrases such as “VPN disconnected.” The useful result was not only a matching incident; it exposed the previous root cause and the resolution that had worked before.

Make it usable outside the search console

The final reference implementation adds a simple Streamlit interface with service and severity filters. That turns the search index into something closer to a support workflow than a technical demo.

What I would carry into a larger implementation

1. Index the operational fields users actually need after retrieval.
2. Test the vocabulary support engineers use, not only formal incident titles.
3. Keep metadata such as service and severity filterable.
4. Start with relevance and usability before adding unnecessary AI layers.