RAG Chatbot for API Docs on AWS

Introduction

30 Second Summary

Ever spent twenty minutes digging through API documentation trying to find the one endpoint that handles authentication? Imagine if you could just ask a chatbot and get the exact answer, complete with a link to the right section.

In this project, you will build a conversational chatbot that answers natural-language questions about API documentation using Retrieval-Augmented Generation. You will upload docs, let AWS handle the indexing and retrieval, and chat with your knowledge base through a browser interface.

What You'll Build

By the end, you will type a question into your chatbot, watch it pull the most relevant chunks from your API docs, and read back a grounded answer with a citation pointing to the exact source section.

By the end of this project, you'll have:

• A managed RAG pipeline on Amazon Bedrock where you ask a simple question like "How do I authenticate?" and get a precise, cited answer pulled directly from your uploaded docs.
• Firsthand experience with agentic retrieval, where you ask a complex multi-part question, watch the system decompose it into sub-queries, retrieve from multiple sections, and stitch together a complete answer that standard search missed.
• A live Amazon Lex chatbot interface where you hold a natural conversation, ask follow-up questions, and see the bot maintain context between turns.
• Secret Mission: Add Bedrock Guardrails to block off-topic questions and keep your chatbot focused on API documentation only.

Are there any prerequisites?

You need an AWS account with free tier credits. In Step 1, you will enable model access in Amazon Bedrock. No prior experience with Bedrock or Lex is required.

Before We Start

Before we dive into the AWS console, let's lock in what you're about to build and why it matters. This step is your moment to commit to the goal before any hands-on work begins.

Set Up Bedrock Model Access and Upload Your API Docs

Your RAG chatbot needs two foundations before anything else can happen. Amazon Bedrock needs permission to call the foundation models that will power embeddings and answer generation.

Your documents also need a home where the knowledge base can reach them. In this step, you will enable model access and upload your API docs to an S3 bucket.

In this step, get ready to:

• Enable foundation model access in Amazon Bedrock.
• Upload API documentation to a new S3 bucket.
• Verify both are ready for the knowledge base.

Enable model access in the Amazon Bedrock console

The knowledge base uses two types of foundation models: an embedding model to convert your documents into searchable vectors, and a language model to generate answers. You need to grant your account access to these models before the knowledge base can use them.

• Sign in to the AWS Management Console at https://console.aws.amazon.com.
• In the top search bar, type Bedrock and select Amazon Bedrock from the results.
• In the left navigation pane, choose Model access.
• Choose Manage model access.
• Select the checkboxes next to the Anthropic models (Claude) and the Amazon models (Titan).
• Choose Request model access.

Why do we need both Anthropic and Amazon models?

Amazon Titan powers the embedding model that converts your documents into vector representations for search. Anthropic Claude is the language model that reads the retrieved chunks and generates human-readable answers.

The knowledge base needs both: one to understand your documents, and one to talk to users about them.

• Wait for the Access status column to show Access granted next to both the Anthropic Claude models and Amazon Titan models. This is typically instant for on-demand models.

What if I need to submit a usage form?

Some model providers (like Anthropic) may ask you to complete a one-time usage form describing your use case. If prompted, fill out the form with details about building a Q&A chatbot for API documentation and submit it. Approval is typically immediate.

Still seeing Available to request?

Make sure you selected models from both the Anthropic and Amazon providers before clicking Request model access. If you submitted a usage form for Anthropic, refresh the page after a minute.

help me troubleshoot Bedrock model access not showing Access granted

Create an S3 bucket and upload your API documentation

Your knowledge base needs a data source to ingest. S3 is the storage layer where you place the documents that Bedrock will chunk, embed, and index.

• In the top search bar of the AWS console, type S3 and select S3 from the results.
• Click Create bucket.
• In the Bucket name field, enter a unique name like api-docs-kb- followed by your initials (for example, api-docs-kb-jm).
• Leave all other settings at their defaults.
• Scroll to the bottom and click Create bucket.

Why does the bucket name need to be unique?

S3 bucket names are globally unique across all AWS accounts. Adding your initials ensures the name is not already taken by another AWS user.

• Click on your newly created bucket name to open it.
• Click Upload.
• Click Add files and select one or more PDF or markdown files containing API documentation. Any API docs work: a downloaded reference guide, an OpenAPI spec, or a technical manual you have on hand.
• Click Upload to transfer the files to your bucket.

Pick docs you know well

Choose API documentation that you are familiar with. This way you can verify that the chatbot's answers are actually correct when you test it later.

• Confirm the upload succeeded by checking that your file(s) appear in the Objects list inside the bucket.

Upload failing or file not appearing?

Make sure your file is a supported format (PDF or markdown). Check that the file is not empty and is under 50 MB. If you see a permissions error, ensure your IAM user has S3 write access.

help me fix my S3 upload issue

Confirm your setup

Before you move on, predict what you expect to see on each page. Then verify both pieces are in place.

• Navigate back to the Amazon Bedrock console. In the left navigation pane, choose Model access.
• Confirm that the Access status column shows Access granted next to both the Anthropic Claude models and Amazon Titan models.
• Navigate back to your S3 bucket and confirm your documentation file(s) are listed in the Objects tab.

You should see Access granted status for both model providers, and at least one file in your S3 bucket.

Your models are unlocked and your docs are in place. Next up, you will create a managed knowledge base that turns those raw documents into a searchable, AI-powered retrieval system.

Create and Test Your Managed Knowledge Base

Your model access is ready and your API docs are sitting in S3. Now it's time to turn those static files into a searchable knowledge base that can answer natural-language questions.

Normally, building a RAG pipeline means setting up a vector database, choosing an embedding model, writing chunking logic, and wiring up retrieval. Amazon Bedrock's Managed Knowledge Base handles all of this as a single service, so you can focus on querying rather than infrastructure.

In this step, get ready to:

• Create a Managed Knowledge Base connected to your S3 bucket.
• Sync the data source to chunk, embed, and index your documents.
• Test a simple query and confirm you get a cited answer.

Create a Managed Knowledge Base

• In the AWS console, navigate to Amazon Bedrock.
• In the left navigation pane, select Knowledge bases.
• Click Create Managed Knowledge Base.
• Leave the default name or enter api-docs-kb as the knowledge base name.
• Under Data source, select Amazon S3 from the data source type dropdown.
• Browse to the api-docs-kb-{initials} bucket you created in Step 1.

Why a Managed Knowledge Base?

The alternative is a customer-managed knowledge base, which requires you to provision and configure an OpenSearch Serverless vector store separately. The managed option handles the vector store, embeddings, and re-ranking automatically.

Managed embedding and managed re-ranking are both included at no extra cost. You only pay for storage and retrieval API calls.

• Leave all other settings at their defaults (managed embeddings, managed re-ranker, auto-created IAM role, default chunking).
• Click Create Knowledge Base.
• Wait for the knowledge base and data source to be created. This takes 2-5 minutes.

Once the knowledge base is ready, you need to sync it so Bedrock chunks, embeds, and indexes your documents.

• On the knowledge base details page, scroll down to the Data source section.
• Select your data source, then click Sync.
• Wait for the sync to complete. The status updates to Ready when done.

Sync failed or stuck?

• Check that your S3 bucket contains at least one supported file (PDF or markdown). Empty buckets have nothing to index.
• Verify the bucket name matches what you configured in the data source. A mismatched bucket name causes a permissions error.
• Check the Sync history section and select View warnings for details on what failed.

Having trouble with your sync? Help me debug why my Bedrock Knowledge Base sync is failing

• While on the knowledge base details page, note the Knowledge Base ID displayed at the top. You will need this in a later step.

Test with a simple query

Your documents are now chunked, embedded, and indexed. Time to ask your first question and see if the knowledge base can retrieve the right answer.

Before you run your query, think about this: what do you expect the response to include? A direct answer, a chunk of raw text, or something else?

• In the test window on the right side of the knowledge base details page, make sure Generate responses is toggled on. This tells the LLM to synthesize an answer from the retrieved chunks.
• Type a straightforward factual question that you know your docs answer. For example: What is the base URL for the API? or What authentication method is used?.
• Click Run.

You should see a synthesized answer that directly addresses your question. Below the answer, source citations appear pointing to the specific chunk of your document that the answer came from.

• Click Show source details to expand the citation and see the raw text that was retrieved from your document.

What just happened?

When you typed your question, the knowledge base converted it into a vector embedding and searched the index for the most similar document chunks. The managed re-ranker then re-ordered those chunks by relevance.

Finally, the foundation model read the top chunks and synthesized a natural-language answer with a citation back to the source. All of this happened in a single API call behind the scenes.

Not seeing an answer or citation?

• Make sure Generate responses is toggled on. With it off, you only see raw chunks, not a synthesized answer.
• Confirm the sync completed successfully (status shows Ready). If the sync is still running, no documents are indexed yet.
• Try a different question that matches content you know exists in your uploaded docs.

Still stuck? Help me figure out why my Knowledge Base query returns no results

Observe the basic retrieval

For a simple factual question, the knowledge base performed well. It found the relevant chunk, re-ranked it to the top, and generated a grounded answer with a citation.

This is your baseline. Standard retrieval with managed re-ranking works great for single-intent lookup questions where the answer lives in one section of your docs.

What is re-ranking?

After the initial semantic search finds candidate chunks, a re-ranker model scores each chunk against your original question and reorders them by true relevance. This catches chunks that are semantically similar but not actually answering the question.

In your Managed Knowledge Base, re-ranking is enabled by default at no extra cost. You did not have to configure it.

Your knowledge base is working. Next up, you will push it harder with complex multi-part questions and discover where single-pass retrieval hits a wall.

Hit the Limits of Standard Retrieval

In the previous step, your knowledge base handled a straightforward factual question with ease. Standard retrieval found the relevant chunk, re-ranked it, and delivered a cited answer.

But real-world questions are rarely simple lookups. When someone asks a comparative question or needs information scattered across multiple sections of your docs, a single search pass hits a wall. In this step, you'll push your knowledge base with complex queries and experience exactly where it breaks down.

In this step, get ready to:

• Test a complex multi-part question in the Knowledge Base test panel.
• Evaluate whether the response covers all dimensions of your question.
• Understand why single-pass retrieval falls short on multi-hop questions.

Ask a complex multi-part question

A multi-part question requires pulling information from different sections of your documentation and synthesizing it into a single answer. These are the kinds of questions real users ask when they need to compare features or understand relationships across your API.

• Return to the Knowledge Base test panel in the Amazon Bedrock console (the same panel you used for your simple query in the previous step).
• Make sure you are using standard Retrieve mode (not Agentic Retrieval).

Now think about a question that requires information from multiple places in your docs. Here are some examples depending on what your documentation covers:

• "Compare the authentication methods for the admin API vs. the public API."
• "What are all the rate limits and how do error codes differ between endpoints?"
• "List every required header across all endpoints and explain when each is needed."

Before you submit your question, take a moment to predict: do you think the knowledge base will handle a complex comparative question as well as it handled the simple factual one?

• Type a complex multi-part question into the test panel and submit it.

Read the response. You'll notice the answer is either incomplete, draws from only one section of your docs, or misses entire dimensions of the question. Parts of what you asked go unanswered.

What should I see?

The response will likely answer one part of your question well (the part closest to whatever single chunk the retrieval found) but leave other parts vague, missing, or unsupported by citations. This is the expected result. Standard retrieval did exactly one search and returned chunks from a single area of your docs.

Evaluate the gaps in the response

The shortfall you are seeing is not a bug. It is the intended limitation you need to experience before moving to a more powerful retrieval mode.

• Look at the citations in the response. Count how many distinct document sections they reference.
• Identify which parts of your original question went unanswered or were only partially addressed.
• Try one or two more complex questions to confirm the pattern. Each time, note where the response falls short.

Spot the single-source pattern

If all the citations point to chunks from the same section of your docs, that is the clearest sign that standard retrieval only searched once. A comparative question needs chunks from at least two different areas.

Understand why single-pass retrieval falls short

Standard Retrieve performs one semantic search against your indexed chunks and returns the top-ranked results. For a simple factual question, one search is enough because the answer lives in one place.

Why does one search fail on multi-part questions?

When your question has multiple intents (compare X and Y, list all Z across endpoints), a single embedding search captures the meaning of your full question as one vector. That vector lands closest to chunks about one of the intents, not all of them.

The chunks about the other intents are still in the index. They just never get retrieved because the system only searched once. This is the gap that query decomposition fills by splitting your question into sub-queries and searching for each one separately.

You have now seen the ceiling of single-pass retrieval firsthand. Simple factual lookups work great. Complex multi-part questions that span different sections of your docs get partial answers at best. In the next step, you'll unlock Agentic Retrieval, which decomposes your complex question into sub-queries and retrieves iteratively until it has enough evidence to answer every part.

Unlock Agentic Retrieval with Query Decomposition

In the previous step, you saw standard retrieval fall short on multi-part questions. It performs a single search pass and returns chunks from only one section of your docs, leaving parts of your question unanswered.

Agentic retrieval solves this by using a foundation model to break complex queries into sub-queries, retrieve against each one, and evaluate whether the collected evidence is sufficient before generating an answer. In this step, you will switch to this mode and watch it handle the same questions that stumped standard retrieval.

In this step, get ready to:

• Switch to Agentic Retrieval mode in the Knowledge Base test panel.
• Re-run complex multi-part queries and receive comprehensive cited answers.
• Compare standard Retrieve vs. Agentic Retrieval results side by side.

Switch to Agentic Retrieval

The test panel you used in the previous steps defaults to standard Retrieve mode. Switching to Agentic Retrieval tells Bedrock to use a foundation model as a planner that decomposes your query, retrieves in multiple passes, and judges whether it has enough evidence.

• Return to the Knowledge Base test panel for api-docs-kb in the Bedrock console.
• In the retrieval type dropdown, select Agentic retrieval with answer generation.
• Confirm the model selection is set to the managed foundation model (this is the default).
• Set Maximum agentic iterations to 5.

Why 5 iterations?

Each iteration is one planner invocation plus its sub-query retrievals. For comparative queries that span multiple document sections, 4-5 iterations gives the planner enough rounds to gather complete evidence. A simple single-KB lookup typically needs only 3.

What is query decomposition?

Query decomposition is a technique where a foundation model splits a complex question into smaller, focused sub-queries. Each sub-query targets a specific piece of evidence from your documents.

For example, "Compare authentication for admin vs. public APIs" becomes two sub-queries: one searching for admin authentication and one for public API authentication. The planner then stitches the results into a complete answer.

Re-run your complex query

Now test Agentic Retrieval with the same multi-part question that returned an incomplete answer in standard mode.

• Type the same complex multi-part question you asked in the previous step (for example, "Compare the authentication methods for the admin API vs. the public API" or "List every required header across all endpoints and explain when each is needed").
• Before you click Run, predict: do you think the answer will cover all parts of your question this time, or will it still miss sections?
• Click Run.

Watch the trace events stream in as the system works. You will see Planning events where the model creates sub-queries, Retrieval events as it searches for each sub-query, and finally a synthesized answer that addresses all parts of your question.

• Read the response carefully. It should now reference multiple document sections with separate citations for each part of your question.
• Select Show source details to confirm citations come from different chunks across your docs.

What are trace events?

Trace events give you visibility into the agentic retrieval process. They show the planner's decisions in real time: which sub-queries it created, which knowledge base sections it searched, and whether it judged the results sufficient or decided to iterate again.

This transparency is valuable for debugging. If an answer is still missing something, the trace tells you exactly which sub-query came up empty.

Response still seems incomplete?

Make sure you selected Agentic retrieval with answer generation as the retrieval type, not the standard Retrieve option.

If your API docs are very short (only a page or two), the system may not have enough distinct sections to demonstrate the multi-section retrieval. Try a question that specifically asks about two different topics covered in your docs.

Help me troubleshoot my Agentic Retrieval setup

Compare the results side by side

Seeing both modes answer the same question makes the difference undeniable. You will switch back to standard Retrieve, re-run the query, and then return to Agentic Retrieval to confirm the improvement.

• In the retrieval type dropdown, switch back to the standard retrieval option.
• Run the same multi-part question again.
• Note which parts of the question are missing or only partially answered.

• Switch back to Agentic retrieval with answer generation and set iterations back to 5.
• Try additional complex questions that require synthesizing multiple sections, such as: "What is the relationship between authentication scopes and rate limit tiers?" or "Walk me through the complete lifecycle of a request from auth to response."
• Observe how Agentic Retrieval iterates until it has gathered complete evidence from across your documents.

When to use which retrieval mode?

Use standard Retrieve for direct, single-fact lookups ("What is the base URL?"). It is faster and cheaper because it makes no extra model calls.

Use AgenticRetrieveStream when questions are multi-part, comparative, or exploratory. It costs more ($4 per 1,000 calls vs. $1 per 1,000 for standard) because it invokes the planner model multiple times, but it finds evidence that a single search pass misses.

You now have firsthand evidence that Agentic Retrieval with query decomposition produces comprehensive, multi-section answers where standard retrieval falls short. The knowledge base handles all the orchestration behind the scenes.

Your knowledge base can now answer complex questions accurately. Next up, you will give it a proper conversational interface by connecting it to an Amazon Lex chatbot that users can interact with naturally.

Build the Lex V2 Chatbot Interface

Your knowledge base can answer questions, but right now the only way to use it is through the Bedrock test panel. Real users need a conversational interface where they can ask questions naturally and get follow-up responses in context.

Amazon Lex V2 provides exactly this. It is a chatbot service with built-in generative AI capabilities that connect directly to Bedrock Knowledge Bases. No code required.

In this step, get ready to:

• Create a Lex V2 bot with English language support.
• Connect your Knowledge Base using the built-in QnAIntent.
• Test conversational flow with follow-up questions.

Create a Lex V2 bot

You need a bot shell before you can add intents or connect your knowledge base. This bot acts as the container for your chatbot's conversational logic.

• In the AWS Management Console, search for Amazon Lex in the top search bar and open the service.
• Click Create bot.
• Select Create a blank bot.
• Enter APIDocs-Assistant as the bot name.
• For the IAM role, select Create a role with basic Amazon Lex permissions.
• Choose English as the language.
• Click Create at the bottom of the page.

After a few seconds, the console loads your new bot's configuration page. You should see the bot name APIDocs-Assistant at the top of the screen.

What is a Lex V2 bot?

A Lex bot is a conversational container. It holds intents (what the user wants to do), slots (the information the user provides), and fulfillment logic (how the bot responds).

For this project, you only need one intent. The built-in QnAIntent handles everything: interpreting the question, searching your knowledge base, and generating a response.

Don't see the Create bot button?

Make sure you are in the Lex V2 console, not the legacy Lex V1 console. If you see a banner offering to switch to V2, click it.

Also confirm your region supports Lex V2. US East (N. Virginia) and US West (Oregon) are safe choices.

Help me create my Lex V2 bot

Add the QnAIntent connected to your Knowledge Base

The AMAZON.QnAIntent is a built-in Lex intent designed specifically for question-answering. When a user's message does not match any other intent, QnAIntent uses a Bedrock model to search your knowledge base and respond.

• On your bot's Intents page, click Add intent.
• Select Use built-in intent.
• Choose AMAZON.QnAIntent from the list.
• For the model, select Anthropic Claude (choose the available Claude model from the dropdown).
• For Knowledge store, select Knowledge base for Amazon Bedrock.
• Enter your Knowledge Base ID in the field. You can find this on the Knowledge Base details page in the Bedrock console.
• Click Save Intent.

Finding your Knowledge Base ID

Open a new browser tab, navigate to the Bedrock console, click Knowledge Bases in the left sidebar, and select api-docs-kb. The Knowledge Base ID is displayed near the top of the details page. Copy it and paste it back in the Lex console.

• Click Build at the top of the page to compile the bot.

Wait for the build to complete. You should see a success banner confirming the bot was built successfully.

Why does the bot need to be built?

Building compiles your bot's intent configuration into a runtime model that Lex can execute. Until you build, changes you make in the console are just drafts. You need to rebuild any time you modify an intent.

Build failed?

Double-check that you selected a model under the QnAIntent settings. The intent requires a foundation model to generate responses.

Confirm your Knowledge Base ID is correct. An invalid ID causes the build to fail with a validation error.

Help me fix my Lex bot build failure

Test the conversational flow

Your bot is built. Now you can test whether it retrieves answers from your knowledge base and maintains context across follow-up questions.

• Click Test at the top of the page to open the Lex test panel.

Before you type anything, think about this: what do you expect will happen when you ask your bot a question about your API docs? Will it answer like the Bedrock test panel did, or will something be different?

• Type a question about your API documentation (for example, "What authentication method is used?" or "What is the base URL?").
• Press Enter to send the message.

The bot responds with a relevant answer drawn from your knowledge base. It works just like the Bedrock test panel, but now wrapped in a conversational interface.

• Ask a follow-up question that relies on context from your first question. For example, if you asked about authentication first, follow with "What happens if it expires?" or "Are there different levels of access?".

The bot maintains context between turns. Your follow-up receives a relevant answer that builds on the previous exchange, providing a natural conversational experience.

How does Lex maintain context?

The QnAIntent automatically tracks conversation history. When you ask "What happens if it expires?", Lex knows "it" refers to the authentication method from your previous question. This context window persists for the duration of the test session.

Bot not answering your question?

If the bot returns a generic fallback message instead of an answer from your docs, check that the Knowledge Base ID you entered matches the one on the Bedrock Knowledge Base details page.

Make sure you ask about something that is actually in your uploaded documentation. A question about content not in your docs will not get a relevant answer.

If you changed anything, remember to click Build again before retesting. Lex only uses the most recently built version.

Help me troubleshoot my Lex QnAIntent responses

Your chatbot is live and answering questions from your API documentation. But what happens if someone asks it about the weather, or for investment advice? In the Secret Mission, you will add guardrails to keep it focused on what it knows.

Secret mission

Add Bedrock Guardrails to Keep Your Chatbot On-Topic

Your chatbot answers API documentation questions brilliantly. But what happens when someone asks it for the weather forecast or investment advice? Right now, the LLM will try to answer anything. In this mission, you'll add Bedrock Guardrails to keep your chatbot professional and focused.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses usage-based AWS services, so costs only accrue when you query or store data.

Cost warning

Your Bedrock Managed Knowledge Base charges $5.00 per GB of raw data stored per month, plus $1.00 per 1,000 Retrieve API calls and $4.00 per 1,000 Agentic Retrieve API calls. Guardrail assessments are also charged per use. If you leave these resources active and continue querying, costs will accrue.

For a small learning project with occasional testing, expect well under $1/month. If you are done experimenting, delete all resources to reduce ongoing costs to $0.

Resources you used:

• Amazon Lex V2 bot (APIDocs-Assistant).
• Amazon Bedrock Managed Knowledge Base (api-docs-kb).
• Amazon S3 bucket (api-docs-kb-{your-initials}).
• Amazon Bedrock Guardrail.

Keep everything running

No action needed. Choose this if you are still actively building or testing your chatbot.

• Your Knowledge Base, Lex bot, and Guardrail remain available for querying.
• Costs are usage-based and minimal for occasional testing (likely under $1/month).
• The Lex V2 free tier covers 10,000 text requests per month for your first year.

Pause - I'll come back to this later

There is no explicit pause option for these services. Costs only accrue when you query the Knowledge Base or when data remains stored in the managed index.

• Stop sending queries to your Lex bot and Knowledge Base.
• Storage charges ($5/GB/month) continue as long as your Knowledge Base exists with synced data.
• If you want to eliminate all charges while preserving your uploaded docs, delete the Knowledge Base (to stop index storage charges) but keep the S3 bucket. You can recreate the KB later from the same bucket.

Delete - I don't want to use this again

Remove all project resources to reduce ongoing costs to $0.

• Delete the Lex V2 bot first. Open the Amazon Lex console. In the left navigation, choose Bots. Select APIDocs-Assistant, then choose Delete. Confirm the deletion when prompted.
• Delete the Bedrock Guardrail. Open the Bedrock console. In the left navigation, choose Guardrails. Select your guardrail, then choose Delete. Type delete in the confirmation field and choose Delete.
• Delete the Bedrock Knowledge Base. In the Bedrock console left navigation, choose Knowledge bases. Select api-docs-kb, then choose Delete. Type delete in the confirmation field and choose Delete. This removes the managed index and stops storage charges.
• Empty and delete the S3 bucket. Open the S3 console. Select your api-docs-kb-{your-initials} bucket. Choose Empty and confirm by typing permanently delete. After emptying, select the bucket again, choose Delete, and confirm by typing the bucket name.

Nice Work!

Nice Work!

Nice work! You just built a production-grade RAG chatbot on AWS that answers natural-language questions about your API documentation with cited sources.

You've learned how to:

• Built a fully managed RAG pipeline using Amazon Bedrock Managed Knowledge Base with S3 as the data source, handling chunking, embedding, and indexing automatically.
• Hit the limits of standard single-pass retrieval on complex queries and solved it with Agentic Retrieval, using query decomposition and iterative retrieval to get comprehensive, multi-section answers.
• Connected the knowledge base to a Lex V2 chatbot using the built-in QnAIntent for a conversational interface with follow-up question support.
• Secret Mission: Added Bedrock Guardrails with denied topic policies to block off-topic questions and keep the chatbot focused on API documentation only.

Ready to quiz yourself?