Cloud Domain-Adaptive RAG Chatbot

Building a Cloud-Focused Generative AI Assistant Using Azure OpenAI, Azure AI Search, Azure Functions, and RAG

Project Overview

Large Language Models are powerful for general-purpose questions, but they may not always provide sufficiently accurate, contextual, or organization-specific answers for specialized technical domains.

I developed a Cloud Domain-Adaptive Retrieval-Augmented Generation (RAG) Chatbot to demonstrate how enterprise cloud knowledge can be collected, processed, indexed, retrieved, and combined with a Large Language Model to provide more relevant and context-aware responses.

The solution focuses on cloud technologies and uses content from sources such as technical blogs, documentation, and video-based learning content to create a continuously extensible cloud knowledge base.

The project was designed using Microsoft Azure services with emphasis on:

• Domain-specific knowledge retrieval
• Automated content ingestion and processing
• Vector and hybrid search
• Generative AI
• Modular cloud-native architecture
• Cost-conscious implementation
• Future extensibility

Problem Statement

Cloud professionals frequently need information across multiple technologies including Azure, AWS, GCP, migration, disaster recovery, security, identity, networking, virtualization, monitoring, and architecture.

This information is often distributed across:

• Technical blogs
• Product documentation
• YouTube videos
• Architecture documents
• Training material
• Knowledge articles
• Operational documents

Traditional keyword-based search can return multiple documents but still requires users to manually identify the most relevant information.

General-purpose LLMs provide conversational answers, but they may not have access to the latest or domain-specific organizational knowledge.

The challenge was therefore:

How can cloud-specific information be dynamically retrieved from a trusted knowledge base and provided to an LLM so that users receive more contextual, relevant, and grounded answers?

Solution

I designed a Cloud Domain-Adaptive RAG architecture where cloud-related content is first collected and processed before being converted into vector embeddings and indexed within Azure AI Search.

When a user submits a question, the application retrieves the most relevant knowledge from the indexed cloud content and provides that context to Azure OpenAI.

The Large Language Model then generates the final response using both:

User Question + Retrieved Cloud Context

instead of depending only on the model’s pre-trained knowledge.

This approach combines the reasoning capabilities of Generative AI with domain-specific information retrieval.

Solution Architecture

The architecture follows a multi-stage pipeline covering:

Content Ingestion → Data Processing → Embedding → Indexing → Retrieval → RAG Orchestration → LLM Response → User Interface

Architecture Components

1. Cloud Knowledge Sources

The solution can ingest cloud-related knowledge from multiple sources such as:

• Technical blogs
• Web content
• YouTube-related content
• Architecture documentation
• Training material
• Cloud implementation notes

This allows the knowledge base to continuously evolve as new technical content becomes available.

2. Azure Function – Content Ingestion

An Azure Function acts as the ingestion layer.

Its responsibility is to collect content from configured sources and store the original information in Azure Blob Storage – RAW.

Separating raw content from processed content provides better traceability and allows the processing pipeline to be rerun without collecting the source information again.

3. Azure Storage – RAW Layer

The RAW storage layer preserves the original ingested content.

It provides a central landing zone before any transformation or AI processing takes place.

This pattern also separates:

Source Data → Processed Data → Searchable Knowledge

which improves maintainability of the architecture.

4. Azure Function – Data Processing

The processing function reads content from the RAW storage layer and prepares it for AI-based retrieval.

Typical processing activities include:

• Cleaning unnecessary content
• Normalizing text
• Removing unwanted formatting
• Preparing documents
• Dividing large content into manageable chunks

The processed information is then stored in the Clean Storage Layer.

5. Azure Storage – Clean Layer

The clean storage layer contains AI-ready content.

Maintaining a separate processed-data layer enables the indexing pipeline to work with structured and cleaned information without modifying the original source data.

6. Azure Function – Indexing

The indexing function retrieves processed content and prepares it for Azure AI Search.

Each document is divided into smaller logical chunks before vector representations are generated.

Chunking is important because an entire large document should not normally be provided to an LLM for every question.

Instead, the system retrieves only those portions that are most relevant to the user query.

7. Azure OpenAI – Embedding Model

The processed text chunks are converted into numerical vector representations using an Azure OpenAI embedding model.

In this project, the embedding layer allows semantic similarity to be calculated between:

the user’s question

and

the cloud knowledge stored in the search index.

This means retrieval is based not only on matching words but also on the semantic meaning of the query.

8. Azure AI Search – Hybrid and Vector Retrieval

Azure AI Search acts as the primary retrieval layer of the solution.

The architecture supports a combination of:

• Keyword search
• Vector search
• Semantic relevance
• Hybrid retrieval

Hybrid retrieval is particularly useful because keyword-based techniques are strong at finding precise technical terms, while vector retrieval identifies content with similar semantic meaning.

Combining these approaches improves the quality of information supplied to the LLM.

Query-Time RAG Workflow

When a user asks a question, the following workflow takes place:

1. The user submits a question through the Streamlit interface.
2. The RAG backend receives the query.
3. The query is converted into an embedding.
4. Azure AI Search performs hybrid/vector retrieval.
5. The most relevant cloud knowledge chunks are returned.
6. The retrieved information is added to the LLM prompt as context.
7. Azure OpenAI processes the question together with the retrieved context.
8. The generated response is returned through the backend.
9. Streamlit displays the final answer to the user.

This is the core Retrieval-Augmented Generation process.

RAG Orchestration Layer

A dedicated backend layer coordinates communication between:

• User interface
• Embedding service
• Azure AI Search
• Retrieved context
• Azure OpenAI LLM
• Final response generation

The orchestration layer is responsible for controlling the complete RAG workflow rather than allowing the UI to communicate directly with every AI service.

This improves modularity and allows retrieval, prompting, security, logging, and model configuration to evolve independently.

Azure OpenAI – LLM Layer

After relevant information is retrieved, the context is passed to an Azure OpenAI Large Language Model.

Instead of asking the LLM:

Answer this cloud question using only your existing knowledge.

the RAG application effectively asks:

Here is relevant information retrieved from the cloud knowledge base. Use this context to answer the user’s question.

This helps produce responses that are more closely aligned with the available domain knowledge and helps reduce unsupported responses.

Streamlit User Interface

Streamlit provides a lightweight conversational interface through which users can interact with the RAG solution.

Users can enter natural-language cloud questions and receive AI-generated answers backed by information retrieved from the cloud knowledge repository.

The UI layer can later be replaced by other interfaces without redesigning the underlying RAG architecture.

Potential interfaces could include:

• Enterprise web applications
• Microsoft Teams
• Power Apps
• Copilot-based interfaces
• Service management portals
• Mobile applications

Why Domain-Adaptive RAG?

A generic AI model understands a broad range of subjects.

A domain-adaptive RAG solution supplements that general intelligence with information specifically relevant to a particular domain.

For this project, the domain is Cloud Computing and Cloud Architecture.

The same architecture could be adapted for:

• IT operations
• Healthcare
• Banking
• Manufacturing
• Legal knowledge
• Cybersecurity
• Enterprise support
• Internal organizational knowledge

Only the knowledge sources and domain-specific processing would need to change.

Key Benefits

Domain-Specific Responses

The chatbot retrieves cloud-specific information before generating the answer, improving relevance for specialized technical questions.

Reduced Dependency on Model Memory

Answers are not generated solely from the LLM’s pre-trained knowledge. Relevant information is retrieved dynamically from the indexed knowledge base.

Better Knowledge Discovery

Users can ask questions conversationally instead of manually searching across multiple technical documents and content repositories.

Scalable Knowledge Base

New content can be added to the ingestion pipeline without retraining the underlying LLM.

Automated Processing

Azure Functions automate ingestion, cleaning, processing, and indexing activities.

Hybrid Retrieval

Combining keyword and vector retrieval improves the ability to locate both exact technical terms and semantically related information.

Modular Architecture

The ingestion, processing, retrieval, orchestration, LLM, and presentation layers remain independently maintainable.

Technologies Used

Key Architecture Design Principles

While building the solution, I focused on several enterprise architecture principles:

Separation of concerns
Ingestion, processing, indexing, retrieval, LLM interaction, and user interface are separated into different architectural layers.

Loose coupling
Individual components can evolve without redesigning the entire application.

Cloud-native processing
Serverless Azure Functions are used for event-driven data-processing activities.

Retrieval before generation
Relevant knowledge is retrieved before the LLM generates its final response.

Domain adaptation without model retraining
The solution can improve its knowledge by updating the search repository rather than continuously fine-tuning or retraining the LLM.

Cost awareness
The architecture was designed to demonstrate an enterprise RAG pattern while keeping infrastructure utilization and AI consumption under control.

Challenges Addressed During Development

Building the solution also involved practical challenges commonly encountered in Generative AI projects.

These included:

• Choosing an appropriate chunking strategy
• Generating embeddings for processed content
• Maintaining correct embedding dimensions
• Designing the Azure AI Search vector index
• Combining semantic and vector retrieval
• Automating indexing as new content arrives
• Passing retrieved context efficiently to the LLM
• Managing token consumption
• Separating raw and processed knowledge
• Designing the RAG orchestration workflow

Resolving these challenges provided practical experience beyond simply integrating an LLM API.

Future Enhancements

The architecture can be extended further with capabilities such as:

• Reranking retrieved documents
• Source citations within generated responses
• User feedback and relevance scoring
• Conversation memory
• Knowledge graphs
• Agentic AI workflows
• Model Context Protocol integration
• Advanced content connectors
• Enterprise authentication using Microsoft Entra ID
• Role-based knowledge access
• AI safety and content filtering
• Prompt-injection protection
• Observability and token-cost monitoring
• Automated evaluation of RAG responses

These enhancements can evolve the solution from a prototype into a more comprehensive enterprise AI knowledge platform.

Key Learning

One of the most important learnings from this project is that building an effective Generative AI application involves much more than selecting an LLM.

A production-oriented RAG solution requires careful design across:

Data ingestion → Data quality → Chunking → Embeddings → Search → Retrieval → Prompt construction → LLM generation → Security → Monitoring → User experience

The quality of the final answer depends heavily on the quality of the information retrieved and supplied to the model.

Conclusion

The Cloud Domain-Adaptive RAG Chatbot demonstrates how Generative AI can be combined with cloud-native services and enterprise knowledge to create a specialized AI assistant.

Rather than treating an LLM as an isolated component, the project integrates data engineering, serverless computing, vector search, semantic retrieval, backend orchestration, and Generative AI into a complete architecture.

The project helped me practically explore the transition from traditional cloud architecture toward AI-enabled and GenAI architecture, where enterprise data, retrieval systems, cloud platforms, and Large Language Models work together to deliver intelligent applications.