Techniques for Mapping Natural Language to API Calls

Bridging the gap between the fluid, often ambiguous nature of human language and the precise, structured requirements of an API is a common challenge when building tools for LLM agents. An agent might understand a user's request like, "What's the weather like in London tomorrow?", but a weather API needs a call such as GET /api/weather?city=London&date=2024-07-15. Here are several techniques to perform this translation, enabling an LLM agent to effectively use external APIs.

Direct LLM-Powered Mapping

The most straightforward approach is to leverage the LLM's inherent language understanding capabilities. By providing the LLM with a detailed description of the API tool, including its purpose, parameters, types, and required fields (as discussed in "Understanding Tool Specifications and Descriptions" in Chapter 1), you can instruct the LLM to directly generate the structured API call.

Many modern LLMs support "function calling" or "tool use" modes where they can output a structured JSON object representing the function (your API tool) to call and the arguments to use.

Example: Given a tool description for a get_weather API that takes location (string), date (string, YYYY-MM-DD), and units (enum: celsius, fahrenheit), and a user query: "Will it be cold in Oslo next Friday? Give me the temperature in Celsius."

The LLM, guided by the tool description, would aim to produce an output like:

{
  "tool_name": "get_weather",
  "parameters": {
    "location": "Oslo",
    "date": "2024-07-19", // Assuming 'next Friday' is resolved
    "units": "celsius"
  }
}

Your agent's framework then takes this JSON and executes the actual API call.

Advantages:

• Relatively simple to implement if the LLM supports structured output or function calling.
• Uses the LLM's sophisticated understanding of language, including resolving some ambiguities.

Considerations:

• The quality of the mapping heavily depends on the clarity and completeness of your tool description and the LLM's capabilities.
• The LLM might "hallucinate" parameter values or misinterpret complex requests. Extensive prompt engineering or fine-tuning might be needed for high reliability.
• Date and time parsing (like "next Friday") can be tricky. Sometimes it's better to have the LLM extract the raw temporal expression and let your code resolve it to a specific date/time format.

LLM for Entity Extraction, Code for Mapping Logic

A more thorough approach, especially for complex APIs or when you need finer control, involves a two-step process:

1. LLM for Entity and Intent Extraction: Use the LLM to parse the natural language query and extract relevant entities (like locations, dates, names, search terms) and the user's intent. The LLM's output here is an intermediate structured representation, not the final API call.
2. Programmatic Mapping: Your code takes these extracted entities and, based on the identified intent, programmatically constructs the precise API call, applying any necessary business logic, validation, or data transformation.

Example: User query: "I need to find a flight from Boston to San Diego, leaving sometime next week, returning two weeks after."

The LLM might extract:

{
  "intent": "find_flight",
  "origin": "Boston",
  "destination": "San Diego",
  "departure_period": "next week",
  "return_time_relative": "two weeks after departure"
}

Your Python code would then:

• Resolve "next week" to a date range (e.g., 2024-07-22 to 2024-07-28).
• Calculate the return period based on the departure.
• Map origin to the API's departureAirportCode parameter (perhaps involving a lookup from city name to airport code).
• Map destination to arrivalAirportCode.
• Construct the API call to GET /flights/search with the correctly formatted parameters.

Advantages:

• Greater control and reliability, as your code handles the final mapping and validation.
• Easier to implement complex business logic (e.g., "if user asks for X but Y is not specified, default Y to Z").
• More testable, as you can test the extraction and mapping steps separately.

Considerations:

• Requires more development effort to write the mapping logic.
• You need to design the intermediate structured format for the LLM's output.

Semantic Search for API Endpoint or Parameter Selection

When an agent has access to a large suite of API tools, or a single API has numerous complex and overlapping parameters, the LLM might struggle to select the correct API endpoint or the most relevant set of parameters. In such cases, semantic search can act as a preliminary step.

1. Embed Descriptions: Create vector embeddings of the descriptions of your API tools and their parameters.
2. Embed Query: Embed the user's natural language query.
3. Similarity Search: Perform a similarity search in the vector space to find the API tools or parameters whose descriptions are most semantically similar to the user's query.
4. Refined Prompting: Provide the top-k matching tool/parameter descriptions to the LLM as part of its context. This narrows down the choices the LLM has to make, improving its accuracy in generating the correct API call structure.

This technique is particularly useful for discovery and disambiguation in complex API landscapes. For instance, if a user says "Update the customer record," and you have APIs for update_customer_address, update_customer_contact_info, and update_customer_preferences, semantic search can help identify which of these (or all) are most relevant to the query based on finer details in the query and API descriptions.

Advantages:

• Improves accuracy in selecting the right tool or parameters from a large set.
• Can handle more varied phrasing in user queries.

Considerations:

• Adds complexity, requiring an embedding model and a vector store.
• The quality of embeddings and descriptions is important for good results.

Few-Shot Prompting with Examples

LLMs are excellent pattern recognizers. You can guide the LLM's mapping behavior by providing a few examples (shots) of natural language queries and their corresponding desired API call structures directly in the prompt. This is a form of in-context learning.

Example Prompt Snippet:

Here are some examples of how to map user requests to the 'create_calendar_event' API tool:

User request: "Schedule a meeting with John for tomorrow at 3 PM about the project update."
API call: { "tool_name": "create_calendar_event", "parameters": { "title": "Meeting with John: project update", "attendees": ["[email protected]"], "start_time": "YYYY-MM-DDTH15:00:00", "duration_minutes": 60 } }

User request: "Block out my calendar for a focus session next Monday morning from 9 to 11."
API call: { "tool_name": "create_calendar_event", "parameters": { "title": "Focus Session", "start_time": "YYYY-MM-DDT09:00:00", "end_time": "YYYY-MM-DDT11:00:00" } }

User request: {{user_actual_query}}
API call:

The LLM then attempts to follow the pattern shown in the examples to process {{user_actual_query}}.

Advantages:

• Can significantly improve mapping accuracy for specific, recurring patterns.
• Relatively easy to implement if you have representative examples.

Considerations:

• Effectiveness depends on the quality and relevance of the examples.
• The number of examples is limited by the LLM's context window size.
• May not generalize well to queries that deviate significantly from the provided examples.

The following diagram illustrates the general process of translating a natural language query into a structured API call.

The diagram shows a natural language query being processed by a mapping engine, which can employ one or more of the techniques described, to produce a structured API call ready for execution.

Essential Approaches for Effective Mapping

Regardless of the technique you choose, several factors are important for successful natural language to API call mapping:

• High-Quality Tool Descriptions: As emphasized in Chapter 1, the LLM needs comprehensive information about the API: its purpose, each parameter's name, data type (string, integer, boolean, enum), format (e.g., date as YYYY-MM-DD), whether it's required or optional, and a clear description of what each parameter represents. For enum types, list all possible values. This is the foundation upon which the LLM builds its understanding.
• Parameter Value Formatting: Ensure the LLM is guided to provide values in the exact format the API expects. For instance, if an API expects a country code in ISO Alpha-2 format (e.g., "US", "GB"), this should be specified in the parameter description. If the LLM extracts "United States," your mapping logic (or a very well-instructed LLM) needs to convert it.
• Handling Ambiguity and Missing Information: Natural language is often imprecise.
  • Clarification: Design your agent to ask clarifying questions if parameters are missing or the request is ambiguous. For example, if a user asks for "weather in Springfield" and your API needs a state, the agent could ask, "Which Springfield are you referring to?"
  • Default Values: Define sensible default values for optional parameters in your tool specification or mapping logic.
  • Confidence Scoring: If the LLM generates multiple possible interpretations, your system might use confidence scores (if provided by the LLM) or heuristics to pick the most likely one, or present options to the user.
• Iterative Refinement: Mapping natural language to API calls is rarely perfect on the first try. Plan to test extensively with varied user queries, observe the LLM's behavior, and iteratively refine your tool descriptions, prompts, example sets, or custom mapping logic. Logging interactions and failed mappings is invaluable for this process (covered further in Chapter 6).

Ultimately, transforming natural language into API calls involves finding the right balance. You want to utilize the LLM's flexibility and understanding while maintaining the precision and control needed for reliable API interactions. The choice of technique will depend on the complexity of your APIs, the desired level of reliability, and the development resources available.