How I made AI Search “Whatever data you want to see…” for Find Me in Chicago.
The Chicago Data Portal provides a wealth of information, but its user interface has never been inviting for non-technical citizens to discover and explore. Find Me in Chicago is an independent civic project to make public data more accessible. The application started modestly in 2016 with location searches using basic jQuery and Google Maps. It has since evolved into a robust multi-cloud platform powered by React, Azure, and AWS
AI coding agents accelerated the modernization but after all that effort, Find Me in Chicago still only supported location searches. What I really wanted was AI to help users discover and explore public data more broadly. My idea was “Just tell me the data you want to see…” and it would magically work.
To make my idea work, I embarked on a journey commonly known to engineers as Text-to-Sql which has been attempted many times over decades with mixed and generally poor results. The Chicago Data Portal is powered by Socrata which uses a query language called SoQL, which is an Sql-like language not to be confused with Salesforce Object Query Language.
Anyone who has ever worked on this problem will immediately recognize the four challenges I call CHAD:
1. Cost
2. Hallucination
3. Ambiguity
4. Determinism
Text-to-SoQL is hard because it sits at the intersection of many hard problems in NLP simultaneously: ambiguity resolution, domain-specific grounding, structured output generation, compositional reasoning, and output verification – all with little tolerance for error because a syntactically valid but semantically wrong query silently returns bad data.
My solution is a layered prompt system, C# post-processing normalization, neighborhood macros, and multi-snapshot tolerance testing. I am not trying to make the LLM perfect. I just engineer it to be useful..
In this series I will discuss the CHAD challenges and more.