Skip to main content
Open In Colab We’ll use a movie database containing recent titles, ratings, box office performance, and metadata to demonstrate how to build, evaluate, and systematically improve a text-to-SQL system using Phoenix’s experimentation framework. Think of Phoenix as your scientific laboratory, meticulously recording every experiment to help you build better AI systems.
Let’s first start a phoenix server to act as our evaluation dashboard and experiment tracker. This will be our central hub for observing, measuring, and improving our text-to-SQL system. Note: this step is not necessary if you already have a Phoenix server running.
Let’s also setup tracing for OpenAI. Tracing is crucial for evaluation-driven development - it allows Phoenix to observe every step of our text-to-SQL pipeline, capturing inputs, outputs, and metrics like latency and cost that we’ll use to systematically improve our system.
Let’s make sure we can run async code in the notebook.
Lastly, let’s make sure we have our OpenAI API key set up.

Download Data

We are going to use a movie dataset that contains recent titles and their ratings. We will use DuckDB as our database so that we can run the queries directly in the notebook, but you can imagine that this could be a pre-existing SQL database with business-specific data.

Implement Text2SQL

Let’s start by implementing a simple text2sql logic.
Awesome, looks like the we are producing SQL! let’s try running the query and see if we get the expected results.

The Three Pillars of Evaluation

Effective AI evaluation rests on three fundamental pillars:
  1. Data: Curated examples that represent real-world use cases
  2. Task: The actual function or workflow being evaluated
  3. Evaluators: Quantitative measures of performance
Let’s start by creating our data - a set of movie-related questions that we want our text-to-SQL system to handle correctly.
Let’s store the data above as a versioned dataset in phoenix.
Next, we’ll define the task. The task is to generate SQL queries from natural language questions.
Finally, we’ll define the evaluation scores. We’ll use the following simple functions to see if the generated SQL queries are correct. Note that has_results is a good metric here because we know that all the questions we added to the dataset can be answered via SQL.
Now let’s run the evaluation experiment.
Great! Let’s see how our baseline model performed on the movie questions. We can analyze both successful queries and any failures to understand where improvements are needed.

Interpreting the results

Now that we ran the initial evaluation, let’s analyze what might be causing any failures. From looking at the query where there are no results, genre-related queries might fail because the model doesn’t know how genres are stored (e.g., “Sci-Fi” vs “Science Fiction”) These types of issues would probably be improved by showing a sample of the data to the model (few-shot examples) since the data will show the LLM what is queryable. Let’s try to improve the prompt with few-shot examples and see if we can get better results.
Looking much better! Finally, let’s add a scoring function that compares the results, if they exist, with the expected results.
Amazing. It looks like the LLM is generating a valid query for all questions. Let’s try out using LLM as a judge to see how well it can assess the results.
The LLM judge’s scoring closely matches our manual evaluation, demonstrating its effectiveness as an automated evaluation method. This approach is particularly valuable when traditional rule-based scoring functions are difficult to implement. The LLM judge also shows an advantage in nuanced understanding - for example, it correctly identifies that ‘Anime’ and ‘Animation’ are distinct genres, a subtlety our code-based evaluators missed. This highlights why developing custom LLM judges tailored to your specific task requirements is crucial for accurate evaluation. We now have a simple text2sql pipeline that can be used to generate SQL queries from natural language questions. Since Phoenix has been tracing the entire pipeline, we can now use the Phoenix UI to convert the spans that generated successful queries into examples to use in Golden Dataset for regression testing as well.

Generating more data

Let’s generate some training data by having the model describe existing SQL queries from our dataset
Awesome, let’s create a dataset with the new synthetic data.
Great! We now have more data to work with. Here are some ways to improve it:
  • Review the generated data for issues
  • Refine the prompt
  • Show errors to the model
This gives us a process to keep improving our system.

Conclusion

In this tutorial, we built a text-to-SQL system for querying movie data. We started with basic examples and evaluators, then improved performance by adding few-shot examples as well as using an LLM judge for evaluation. Key takeaways:
  • Start with simple evaluators to catch basic issues
  • Use few-shot examples to improve accuracy
  • Generate more training data using LLMs
  • Track progress with Phoenix’s experiments
You can further improve this system by adding better evaluators or handling edge cases.