
LLM Centric Apps
The rate of innovation in AI has been tremendous over a short period. Specifically, two innovations have opened up a plethora of possibilities for building Apps centred around large language models (LLMs): Function calling and agents.
In this article, I demonstrate how you can utilise function calling and agents to perform searches on flight databases, enabling you to find cheap flights, short flights, long flights, or anything that suits your preference.
Please note – At the very least, you will require the following to make this work for yourself:
- An OpenAI API key – For accessing the large language models.
- An Amadeus API key – For accessing the flight data.
Now, let’s delve into the technical details.
Autonomous Agent Chains
Langchain has been at the forefront of the LLM-powered agent. It’s a simple, yet potent concept.
Essentially, you can equip an Agent with the "reasoning" capability of an LLM, in our case, this will be GPT-4.
You can grant agents access to a variety of tools. These can include a search engine, pandas, SQL, Wolfram Alpha, etc. The list is expanding every month with developers adding more tools.
The agent, powered by a large language model, employs analytical reasoning to determine how to leverage the tool to complete a task you assign.
Function Calling
A development by OpenAI, function calling allows you to parse arguments for a function from a natural language input.
This has significant implications for how users can interact with our app using natural language or even speech.
Function calls will become clearer later with the coded examples provided.
Building a Flight Search App
We can develop an app to query flights with natural language using just four components, excluding the front end.
<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fgiphy.com%2Fembed%2FbaZizQiKKg7p7mb7uz%2Ftwitter%2Fiframe&display_name=Giphy&url=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2Fv1.Y2lkPTc5MGI3NjExc2IwcmV1djJibndmN20wZDN0aHdsdGR5ODhuYzV0bmhnbzJzMm9vciZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw%2FbaZizQiKKg7p7mb7uz%2Fgiphy.gif&image=https%3A%2F%2Fi.giphy.com%2Fmedia%2FbaZizQiKKg7p7mb7uz%2Fgiphy.gif&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=giphy" title="Gif By Author: Demo of the Flights Search LLM App based on the query -" Please give me flights from London to Greece departing on the 15th November 2023 and returning on the 10th of December 2023. For one Adult."" height="244" width="435">
- Flight Data API: The flight data is pulled from Amadeus’ flight API containing all relevant details about flights.
- Function Call: The large language model (LLM) of choice, which is OpenAI’s GPT-4 for the purpose of this app.
- SQL Database: Stores data pulled in an in-memory SQL database.
- The SQL Database Agent: Uses an LLM and SQL Alchemy. The LLM generates the SQL queries from a natural language input. SQL Alchemy executes the query.
The overall architecture looks something like this:

OpenAI Function Calling Script
Function calls enable us to extract structured data from a natural language input. This is perfect for the flight search app since we need to extract key details about flights to enable us to request data from the Amadeus flight API:
Amadeus API Request Script
Next, we send a request for flight booking data to Amadeus. They provide a free tier, but you will need to sign up to receive your API keys.
I have written a script to transform the data such that it’s suitable for SQL queries. This is key to the performance of your application. Note the function _loaddata() is covered in the next section.
Create Database Script
Once we have our data, we need to create an SQL database and store our data their so that our agent can query it.
SQL Database Agent Script
We can call our SQL database agent to query the stored flights database based on the request. The process follows this general workflow:
- Step 1 – Combines the natural language query from the user into the prompt template.
- Step 2 – Sends the combined query and prompt to the SQL database agent
- Step 3 – The SQL database agent works to generate the right query to respond to the user request using the ReAct framework.
Here’s the script:
Here’s the prompt template:
Before we move on, I should briefly cover the ReAct framework.
In essence, ReAct is a framework for prompting LLMs that mixes thinking and doing. It helps the model make plans and adjust them, and also lets it interact with outside sources like databases or environments to get more information.
This method has been tested on different tasks and has shown better results and is easier for humans to understand and trust. For more detail on ReAct, read this resource.
Bringing it All Together
The app consists of six scripts in total including the front end which is developed with Streamlit. The setup instructions and end to end project is available in my GitHub repo.
I have an end to end walkthrough showing you how to clone the app from my GitHub repo to run on your own machine.
I have recorded a live demo via my YouTube channel. You can see the app in action, take a peep under the hood, and see how to set up on your own machine.
Final Thoughts
Function calling and SQL Database agents are incredibly powerful. I envision them being used to build many LLM-centric applications. However, I would like to raise some cautions.
- Prompt Engineering: This plays a major part in the performance of your application. Research into prompt engineering has delivered frameworks like ReAct. However, there is still a lot of engineering required to deliver reasonable responses. The prompt template, in particular, is tricky to get right.
- Latency: The app takes a long time to run end-to-end; it’s certainly not the instant feedback we are often used to. Less performant models like GPT-3.5 will run faster, but at the expense of the capability to answer more complex queries. To a certain extent, the latency issues can be mitigated with a good front end and loading bar from a customer experience perspective. Long term, we would expect to see faster models that are performant.
- Hallucinations: There is a tendency for LLMs to hallucinate, which may return incorrect results from time to time. The prompt engineering frameworks are designed to reduce the hallucination rate, however, more work still needs to be done. I anticipate that more advanced models will suffer less with this hallucination problem, just as we have seen GPT-4 hallucinate at a lower rate than GPT-3.5.
- Data Curation: Using the SQL Database agent can work well if the data is also well curated. Most of my time was spent deciding on the right logical representation of the data to ensure that the LLM could query it correctly.
- LLM Limitations: There are several bugs in the app that could be resolved by introducing more tools. A prime example relates to dates. Occasionally, the LLM fails to infer a date if the year and month aren’t explicitly stated. Providing the LLM with access to Python via an agent could help rectify this issue.
I welcome feedback on the prototype along with any suggestions to improve it.
Thanks for reading.
If you’re keen to enhance your skills in Artificial Intelligence, join the waiting list for my course, where I will guide you through the process of developing large language model powered applications.
If you’re seeking AI-transformation for your business, book a discovery call today.
For more insights on artificial intelligence, Data Science, and large language models you can subscribe to the YouTube channel.