Skip to main content
In this lesson, we explore the infrastructure and code behind our test application using Retrieval-Augmented Generation (RAG). Our objective is to illustrate how various components—from APIs and application configurations to vector search and runtime parameters—work in tandem to deliver an end-to-end solution on Azure.

Overall Architecture

We start by reviewing the overall architecture which includes key components such as Azure Container Apps, Machine Learning workspaces, and storage accounts. This mid-size pilot application leverages common Azure services, including Azure-managed identities and Azure AI Studio.
The image shows a Microsoft Azure Resource Visualizer interface displaying a diagram of interconnected cloud services and resources. It includes various Azure components like Container Apps, Machine Learning workspaces, and Storage accounts.

Deep Dive into Code Integration

Next, we examine the code—with an in-depth look at Promptly integration.

YAML Model Configuration

The following YAML configuration defines model settings, including the API endpoint, deployment details, and runtime parameters such as max tokens, temperature, top_p, and logit bias adjustments. It also provides a sample user and context prompt.
After saving these changes, the application functions as an API. Users send inquiries and receive answers from the backend LLM.

API Setup with FastAPI

Consider the main API file that sets up routes using FastAPI. The sample snippet demonstrates the inclusion of CORS middleware and two endpoints: one for a health-check (GET) and another for generating responses (POST).
A more detailed view of the API call shows that when the “get response” endpoint is triggered, the code extracts inputs and passes them to another module, which uses Promptly to orchestrate backend processes.

Backend Helper Function

In the helper function, model configuration is loaded from environment variables. The prompt is executed using Promptly, and the result is printed and returned.
A similar implementation is repeated with minor modifications in variable naming. Both versions extract inputs, execute the prompt, and return the generated response.

Fetching Additional Context

Another snippet demonstrates fetching additional context before executing the prompt. The function retrieves customer information and product details to create a comprehensive context.
A similar configuration using Jinja templating illustrates how to define system prompts and grounding information.

Templated Prompt with Jinja

Prompt File for a Comedic Sketch

Later in the lesson, we discuss a simple prompt file designed to have the model generate a joke. The file provides additional runtime parameters for context.

Output with Constrained Temperature

Fine-tuning parameters such as temperature and logit bias can dramatically affect model output, making these configurations especially useful with smaller models.

Integrating Product and Customer Data

The lesson further explores the interaction between product and customer data. Product information is stored in a CSV file, later used to build an index for Azure Search Services. Below is an excerpt from the CSV file:
This CSV file outlines product attributes, including ID, name, price, category, brand, and description. An embedding process then converts these descriptions into vector representations, which are indexed in Azure Search Services. The following Python code demonstrates how products are vectorized and indexed in Azure Search:
Vector search profiles and semantic search settings are later defined as follows:
You can view the indexed data in the Azure portal. For instance, searching for “car” returns the CampCruiser Overlander SUV as the top result.
The image shows a Microsoft Azure portal interface for a search service, displaying options for connecting, exploring, and monitoring data with Azure AI Search.
A sample response from Azure Search for a query might look like this:
The embedding process converts product descriptions into vector representations that match search queries. Additionally, token values (e.g., the word “potato”) are displayed to help control output by setting logit biases appropriately.

Integrating with Cosmos DB

Finally, the backend integrates with Cosmos DB to manage customer data. Below is an example of a customer JSON document:
This customer information is used to personalize API responses and appropriately handle queries.

Conclusion

Throughout this lesson, you have seen how a simple API call integrates multiple components—from Promptly orchestrating LLM responses, through runtime parameter tuning, vector searches with Azure Search, to customer data management with Cosmos DB. In the next lesson, we will examine modifying configurations, creating new users, and optimizing the Retrieval-Augmented Generation (RAG) process. Happy coding!

Watch Video