AWS Builder Center

Builder Center

[Workshop 2] Retrieve Data from Documents with Bedrock and Knowledge Bases

Mastering RAG on AWS: A Comprehensive Guide to Amazon Bedrock Knowledge Bases

Module 1: RAG Concepts
Retrieval-Augmented Generation (RAG) has become the standard architectural pattern for building Generative AI applications that require accurate, up-to-date, and domain-specific information. However, managing the data pipeline—chunking, embedding, indexing, and retrieving—can be complex.
In this guide, we explore how Amazon Bedrock Knowledge Bases simplifies this workflow. We will walk through the entire lifecycle: from ingesting data from multiple sources and performing near real-time updates, to implementing hybrid search with LangChain and evaluating your RAG pipeline using the RAGAS framework.

1. Building the Foundation: Multi-Source Ingestion

(Based on 01_create_ingest_documents_test_kb_multi_ds.ipynb)
The first step in any RAG application is unifying your data. Amazon Bedrock Knowledge Bases allows you to connect up to five different data sources—such as Amazon S3, Confluence, SharePoint, Salesforce, and Web Crawlers—into a single vector index (like Amazon OpenSearch Serverless).
Instead of building custom ETL pipelines, you simply define the data source configuration. Bedrock handles the heavy lifting:
  1. Chunking: Splitting documents into manageable pieces (Fixed size, Hierarchical, etc.).
  2. Embedding: Converting text to vectors using models like Titan Embeddings v2.
  3. Indexing: Storing vectors for semantic search.
Key Implementation Step:
When defining your Knowledge Base via the SDK, you can map multiple data sources. Here is how you might configure an S3 bucket source:
code:Python
1
2
3
4
5
6
7
8
9
10
data_sources = [
{
"type": "S3",
"s3Configuration": { "bucketArn": "arn:aws:s3:::your-data-bucket" }
}
# Add Confluence or Web sources here
]

knowledge_base.create_kb(data_sources=data_sources)
knowledge_base.start_ingestion_job()

2. Near Real-Time Updates with Document Level API

(Based on 05_document_level_kb_ingestion.ipynb)
Standard ingestion jobs are great for bulk loads, but what if you need to add a single urgent document without re-syncing the whole bucket?
The Document Level API (DLA) allows for "Inline Ingestion." You can add, update, or delete specific documents in your Knowledge Base in near real-time. This is crucial for dynamic applications where data freshness is paramount.
How it works:
You can inject text directly or point to a specific S3 object for immediate indexing.
code:Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Ingesting a document directly via DLA
response = bedrock_agent_client.ingest_knowledge_base_documents(
knowledgeBaseId=kb_id,
dataSourceId=ds_id,
documents=[{
'source': {
'sourceType': 'S3',
's3': {'uri': 's3://bucket/urgent_report.pdf'}
},
'metadata': {
'type': 'INLINE',
'inlineAttributes': [{'key': 'status', 'value': {'stringValue': 'urgent'}}]
}
}]
)

3. Advanced Retrieval Strategies

(Based on 03_customized_rag_retreive_api_hybrid_search_langchain.ipynb and 02_managed_retreiveandgenerate_and_streamapi.ipynb)
Once your data is indexed, the quality of your answers depends on how you retrieve that data. Amazon Bedrock offers two powerful ways to query your data:

A. The "Retrieve" API & Hybrid Search

For granular control, the Retrieve API returns the raw text chunks and their relevance scores. You can combine this with LangChain to build custom workflows.
Significantly, Bedrock supports Hybrid Search, which combines:
  1. Semantic Search: Understanding the intent and meaning of the query.
  2. Keyword Search: Matching exact terms (great for part numbers or specific names).
code:Python
1
2
3
4
5
6
7
8
9
retriever = AmazonKnowledgeBasesRetriever(
knowledge_base_id=kb_id,
retrieval_config={
"vectorSearchConfiguration": {
"numberOfResults": 5,
"overrideSearchType": "HYBRID" # Combines keyword + semantic
}
}
)

B. The "RetrieveAndGenerate" API

For a fully managed experience, the RetrieveAndGenerate API handles the retrieval and the LLM generation in a single call. It automatically augments the prompt with the retrieved context.
You can also use Streaming to reduce latency (Time-to-First-Token) for a better user experience:
codePython
1
2
3
4
5
6
7
8
9
10
response = bedrock_agent_client.retrieve_and_generate_stream(
input={'text': "What are the risks for Octank Financial?"},
retrieveAndGenerateConfiguration={
'type': 'KNOWLEDGE_BASE',
'knowledgeBaseConfiguration': {
'knowledgeBaseId': kb_id,
'modelArn': model_arn
}
}
)

4. Quality Assurance: Evaluating with RAGAS

(Based on 04_customized_rag_retreive_api_langchain_evaluation_ragas.ipynb)
How do you know if your RAG application is accurate? You cannot rely on "eye-balling" the results.
Using the RAGAS (RAG Assessment) framework combined with LangChain, we can scientifically evaluate our Bedrock Knowledge Base. We use a "Judge LLM" (e.g., Claude 3 Sonnet) to evaluate the responses of our application (e.g., Claude 3 Haiku).
Key Metrics to Monitor:
  1. Faithfulness: Is the answer derived only from the retrieved context? (Prevents hallucinations).
  2. Answer Relevance: Does the answer actually address the user's prompt?
  3. Context Precision: Did the retrieval system rank the relevant documents at the top?
Evaluation Workflow:
codePython
1
2
3
4
5
6
7
8
9
10
11
12
13
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision

# Setup the evaluation
result = evaluate(
dataset=dataset, # Contains questions, answers, and retrieved contexts
metrics=[faithfulness, answer_relevancy, context_precision],
llm=llm_for_evaluation, # e.g., Claude 3 Sonnet
embeddings=bedrock_embeddings
)

# Convert results to pandas dataframe for analysis
df = result.to_pandas()

Module 2: Optimizing Accuracy Retrieved Results

In the above module, we explored Amazon Bedrock Knowledge Bases' advanced features designed to improve the quality of your retrieved context. We will cover advanced chunking strategies, metadata filtering (including auto-generation), query decomposition, and result re-ranking.

1. Beyond Fixed-Size: Advanced Chunking Strategies

(Based on advanced_chunking_options.ipynb)
Standard fixed-size chunking often splits sentences in the middle or loses context. Amazon Bedrock provides intelligent alternatives to structure your data before it hits the vector store.

Semantic Chunking

Instead of splitting by character count, Semantic Chunking uses the embedding model to analyze relationships within the text. It breaks data into chunks only when there is a significant shift in the topic or meaning. This preserves informational integrity.

Hierarchical Chunking

This strategy creates a parent-child relationship.
  1. Parent Chunks: Large sections of text (used for context).
  2. Child Chunks: Smaller segments derived from the parent (used for embedding and search).
When a user queries the system, Bedrock searches the child chunks for precise matching but retrieves the parent chunk to provide the LLM with broader context.
Configuration Example:
code:Python
1
2
3
4
5
6
7
8
9
10
11
12
vector_ingestion_configuration = {
"chunkingConfiguration": {
"chunkingStrategy": "HIERARCHICAL", # or "SEMANTIC"
"hierarchicalChunkingConfiguration": {
"levelConfigurations": [
{"maxTokens": 1500}, # Parent chunk size
{"maxTokens": 300} # Child chunk size
],
"overlapTokens": 60
}
}
}

2. The Power of Metadata: Structuring Your Data

(Based on csv_metadata_customization.ipynb and metadata_filtering.ipynb)
For structured files like CSVs (e.g., sales reports, video game databases), treating every row as a generic blob of text creates noise. Amazon Bedrock allows you to separate Content (what gets embedded) from Metadata (fields used for filtering).

CSV Metadata Sidecars

You can pair your source files with a .metadata.json file (or configure the KB to parse CSVs automatically) to define which columns are searchable fields.
Querying with Explicit Filters:
Once ingested, you can apply strict logic to your vector search. For example, finding "Strategy games scored higher than 9.0":
code:Python
1
2
3
4
5
6
7
8
9
10
11
retrieval_query = {
"vectorSearchConfiguration": {
"numberOfResults": 5,
"filter": {
"andAll": [
{"equals": {"key": "genres", "value": "Strategy"}},
{"greaterThanOrEquals": {"key": "score", "value": 9.0}}
]
}
}
}

3. Autogenerated Filters: Letting the LLM do the Work

(Based on autogenerated_metadata_filters.ipynb)
Hard-coding filters works for UI dropdowns, but chat interfaces are unstructured. Users might ask, "How many Prime members did Amazon have after 2021?"
With Autogenerated Filters, you don't need to parse the natural language yourself. You simply define the schema of your metadata, and Bedrock uses a model (like Claude 3 Sonnet) to inspect the user's prompt and automatically construct the filter for you.
Implementation:
You define implicitFilterConfiguration within your retrieval call:
code:Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
response = bedrock_agent_runtime_client.retrieve_and_generate(
input={'text': "How many prime members does Amazon have after 2021?"},
retrieveAndGenerateConfiguration={
'type': 'KNOWLEDGE_BASE',
'knowledgeBaseConfiguration': {
'knowledgeBaseId': kb_id,
'modelArn': model_arn,
'retrievalConfiguration': {
'vectorSearchConfiguration': {
'implicitFilterConfiguration': {
'metadataAttributes': [
{'key': 'year', 'type': 'NUMBER', 'description': 'The year of the report'},
{'key': 'company', 'type': 'STRING', 'description': 'Company name'}
],
'modelArn': 'arn:aws:bedrock:region::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0'
}
}
}
}
}
)
Result: The system automatically generates a greaterThan filter for the year 2021.

4. Handling Complexity: Query Reformulation

(Based on query_reformulation.ipynb)
When a user asks a multi-part question (e.g., "What is Octank Tower and how did the scandal affect share prices?"), a single vector search often fails because the embedding vector dilutes the distinct topics.
Query Decomposition breaks complex prompts into sub-queries. Bedrock retrieves data for "Octank Tower" and "Scandal impact" separately, pools the results, and generates a comprehensive answer.
code:Python
1
2
3
4
5
'orchestrationConfiguration': {
'queryTransformationConfiguration': {
'type': 'QUERY_DECOMPOSITION'
}
}

5. The Final Polish: Re-ranking

(Based on re_ranking_using_kb.ipynb)
Vector search is fast but relies on semantic similarity, which isn't always the same as relevance. Re-ranking introduces a second stage to the retrieval process.
  1. Retrieve: Fetch a large number of results (e.g., 30) using vector search.
  2. Rerank: Use a specialized Reranking Model (like Amazon Rerank or Cohere Rerank) to score those 30 results precisely against the query.
  3. Select: Pass only the top 3-5 highest-scored chunks to the LLM.
This significantly reduces hallucinations by ensuring the LLM only sees the highest-quality context.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
retrieval_config = {
"vectorSearchConfiguration": {
"numberOfResults": 30, # Fetch broad results first
"rerankingConfiguration": {
"type": "BEDROCK_RERANKING_MODEL",
"bedrockRerankingConfiguration": {
"modelConfiguration": {
"modelArn": "arn:aws:bedrock:region::foundation-model/amazon.rerank-v1:0"
},
"numberOfRerankedResults": 3 # Only keep the best 3
}
}
}
}

Module 3: Building Trustworthy RAG with Contextual Grounding

In the previous modules, we focused on how to retrieve the most relevant data. However, retrieving the right data is only half the battle. The generative model must also strictly adhere to that data when formulating an answer.
One of the biggest risks in GenAI applications is Hallucination—where the model generates a confident-sounding answer that is not factually supported by the source documents, or where it answers a user query that is completely irrelevant to the provided context.
In this module, we implement Contextual Grounding using Amazon Bedrock Guardrails to automatically detect and filter ungrounded or irrelevant responses.

The Challenge: When RAG Goes Wrong

Even with a high-quality Knowledge Base, an LLM might:
  1. Hallucinate: Add information from its pre-training data that conflicts with or doesn't exist in your corporate data.
  2. Drift: Answer questions that are semantically irrelevant to the retrieved context (e.g., asking a financial bot about travel advice).

The Solution: Contextual Grounding Checks

Amazon Bedrock Guardrails provides a feature called Contextual Grounding which evaluates the relationship between the Source (chunks), the Query, and the Response. It applies two specific filters:
  1. Grounding Filter: Checks if the response is factually accurate based only on the source chunks. If the model adds new information not present in the chunks, the grounding score drops.
  2. Relevance Filter: Checks if the model's response is actually relevant to the user's specific query.

Implementation Guide

1. Configuring the Guardrail

We configure the guardrail by defining thresholds (from 0.0 to 1.0). A higher threshold means stricter enforcement. In this example, we create a guardrail for a Dungeons & Dragons rulebook bot.
codePython
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Create a Guardrail with Contextual Grounding enabled
response = bedrock_client.create_guardrail(
name="contextual-grounding-guardrail",
description="Ensures responses are based strictly on the SRD",
contextualGroundingPolicyConfig={
'filtersConfig': [
{
'type': 'GROUNDING',
'threshold': 0.5 # Block if factual consistency is low
},
{
'type': 'RELEVANCE',
'threshold': 0.8 # Block if response doesn't answer the specific query
},
]
},
blockedInputMessaging="Sorry, I can not respond to this.",
blockedOutputsMessaging="The response was blocked due to lack of grounding.",
)
guardrail_id = response["guardrailId"]

2. Integrating Guardrails with the Converse API

To use Contextual Grounding, we must pass the retrieved chunks from our Knowledge Base into the converse API as a specific grounding_source. This allows the Guardrail to "see" the source data and compare it against the generated response.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
def invoke_with_guardrail(query, retrieved_chunks, guardrail_id):
# format chunks into a single string or list
context_string = str(retrieved_chunks)

messages = [
{
"role": "user",
"content": [
{
"guardContent": {
"text": {
"text": context_string,
"qualifiers": ["grounding_source"] # Mark this as the source of truth
}
}
},
{
"guardContent": {
"text": {
"text": query,
"qualifiers": ["query"]
}
}
},
],
}
]

response = bedrock_runtime.converse(
modelId="anthropic.claude-3-sonnet-20240229-v1:0",
messages=messages,
guardrailConfig={
"guardrailIdentifier": guardrail_id,
"guardrailVersion": "DRAFT",
"trace": "enabled" # Enables debugging of scores
}
)
return response
Module 4:

-->Building the Multimodal RAG Application (02_audio_video_rag_using_kb.ipynb)

Once the data preparation phase is complete and the audio/video files have been processed using Amazon Bedrock Data Automation (BDA), the next step is to operationalize this data within a Knowledge Base (KB). This notebook guides you through the end-to-end creation of the RAG workflow.
Step 1: Configure the Knowledge Base
To allow the Large Language Model (LLM) to retrieve answers from your video and audio files, you must first create the Knowledge Base. This involves defining the schema and selecting the embedding model (such as Amazon Titan Text Embeddings V2). The KB acts as the central repository where your processed multimodal data is indexed.
Step 2: Syncing the Data Source
With the Knowledge Base created, the next step is to sync the data source. In this module, the data source is configured to point to the S3 bucket containing the BDA output (the JSON files containing the video summaries and audio transcripts generated in the previous step).
  • Ingestion: When you start the ingestion job, the Knowledge Base converts the BDA-generated textual insights into vector embeddings and stores them in the vector database (Amazon OpenSearch Serverless).
Step 3: Querying the RAG Application
Once ingestion is complete, the application is ready for testing. You can invoke the retrieve_and_generate API to ask complex questions about the video content.
  • Example Query: "Summarize the key features of the product shown in the video."
  • Result: The system retrieves the relevant context from the video summary (as seen in the result_vid.json from the previous file) and generates a coherent, human-readable response.
Clean Up Resources
As shown in the notebook execution results (Image 2), the final stage of this module is the deletion of resources. It is crucial to clean up to avoid incurring unnecessary costs. The script automates the deletion of:
  • The S3 buckets containing raw and processed data.
  • The Knowledge Base and its associated data sources.
  • The OpenSearch Serverless collection.
  • IAM roles and policies created specifically for this workshop.

-->End-to-End Multimodal RAG for Text & Images

While the previous files focused on audio and video, this notebook (text_images_rag_using_kb.ipynb) explores a common enterprise use case: extracting insights from complex documents containing both text and images (e.g., PDFs with charts, graphs, and diagrams).
Overview
Traditional RAG solutions often struggle with visual data embedded within documents, such as a financial report containing a bar chart. This solution leverages Amazon Bedrock Knowledge Bases' advanced parsing capabilities to handle this multimodal challenge effectively.
Parsing Strategies
This notebook demonstrates how to configure the Data Source to use a specific parsing strategy. You have two primary options for handling images within documents:
  1. Amazon Bedrock Data Automation (BDA): A fully managed service that automatically extracts and describes images.
  2. Foundation Models: Using models like Claude 3.5 Sonnet to interpret images and generate text descriptions for embedding.
The Workflow
  1. Data Ingestion: The notebook uploads documents (PDFs containing mixed media) to an S3 bucket (directory mm-data).
  2. Chunking and Embedding: During the ingestion job, the chosen parser breaks down the document. Text is chunked normally. Images are converted into descriptive text (e.g., "A bar chart showing Q3 revenue growth"). Both are then converted into vectors by the Amazon Titan Embeddings model.
  3. Retrieval with Attribution: When you ask a question like "What is the revenue trend in Q3?", the Knowledge Base retrieves the answer based on the chart's data. Crucially, the response includes citations, allowing users to verify the source image.
Resource Management
Similar to the Audio/Video module, this notebook includes a comprehensive cleanup script (as seen in Image 3). It ensures that all created artifacts are removed upon completion:
  • Knowledge Base Deletion: knowledge_base.delete_kb(delete_s3_bucket=True, ...) removes the KB and the underlying S3 data.
  • Role Detachment: The script systematically detaches policies (e.g., AmazonBedrockFoundationModelPolicy...) and deletes the IAM execution roles to ensure security hygiene.

Module 5: Structured RAG with Amazon Redshift

Introduction

While previous modules focused on unstructured data (documents, audio, video), this module explores Structured RAG. This capability allows Amazon Bedrock Knowledge Bases to query structured data residing in Amazon Redshift using natural language. Instead of chunking text, the Knowledge Base analyzes the database schema to transform natural language questions into valid SQL queries, retrieves the data, and generates a natural language response.
This notebook (structured_rag_using_kb.ipynb) demonstrates an end-to-end workflow for connecting a Knowledge Base to an Amazon Redshift database (Serverless or Provisioned).

Key Concepts & Prerequisites

  • Text-to-SQL: The core mechanism involves the Knowledge Base understanding your database schema (tables, columns) and converting user prompts (e.g., "What were the top sales last week?") into SQL queries.
  • Redshift Environment: The notebook supports connecting to both Redshift Serverless and Redshift Provisioned Clusters.
  • Authentication: The solution demonstrates flexibility in security by supporting multiple access patterns, including IAM Roles, Secrets Manager, and direct Database User credentials.

Step-by-Step Implementation

1. Configuration and Access Patterns
The setup phase is critical for Structured RAG. The notebook provides an interactive widget allowing builders to choose between five distinct authentication patterns to match their security requirements:
  1. Secrets Manager + Redshift Serverless
  2. IAM Role + Redshift Serverless
  3. IAM Role + Redshift Provisioned
  4. Secrets Manager + Redshift Provisioned
  5. DB User + Redshift Provisioned
Based on the selection, the BedrockStructuredKnowledgeBase utility configures the necessary sqlKnowledgeBaseConfiguration.
2. Creating the Knowledge Base and Permissions
Once the configuration is defined, the Knowledge Base is created. A unique aspect of Structured RAG is the requirement to grant database-level permissions to the Bedrock execution role. The notebook generates the specific SQL commands required to be run in the Redshift Query Editor:
  • CREATE USER "IAMR:..."
  • GRANT SELECT ON ALL tables...
This ensures the Knowledge Base has the strict authority to read the data it is querying.
3. Schema Ingestion
Unlike unstructured RAG, the "Ingestion" job in Structured RAG does not vectorise data rows. Instead, it reads and syncs the metadata (schema definitions) of the Redshift database. This allows the Foundation Model (Anthropic Claude 3 Sonnet is used in this example) to understand the structure of the data without moving the actual data out of Redshift.
4. Querying the Data
The notebook demonstrates three different ways to interact with the Structured Knowledge Base:
  • retrieve_and_generate API: The end-to-end RAG experience. You ask a question (e.g., "Show me the top 5 customers"), and Bedrock generates the SQL, executes it against Redshift, and uses the LLM to interpret the returned rows into a natural language answer.
  • retrieve API: This returns the raw result of the SQL query execution (the actual data rows) without the LLM summarization. This is useful if you want to display the data in a table in your UI.
  • generate_query API: A useful tool for debugging or "human-in-the-loop" workflows. It converts the natural language prompt into a SQL query without executing it, allowing developers to validate the SQL logic before running it.

Clean Up

As with previous modules, the notebook includes a cleanup section. It is essential to run the knowledge_base.delete_kb(delete_iam_roles_and_policies=True) command to remove the Knowledge Base, associated Data Sources, and auto-generated IAM roles to prevent ongoing costs.
Conclusion
This module showcases how Amazon Bedrock Knowledge Bases can bridge the gap between generative AI and structured enterprise data, enabling business users to query complex Redshift databases using plain English without needing knowledge of SQL.

Module 6: Graph RAG using Amazon Bedrock Knowledge Bases

Introduction

In this final module, we explore Graph Retrieval-Augmented Generation (GraphRAG). While traditional RAG retrieves information based on vector similarity, GraphRAG goes a step further by identifying and leveraging relationships between entities within your data.
By combining Amazon Bedrock Knowledge Bases with Amazon Neptune Analytics, you can build generative AI applications that understand the "structure" of your data—connecting related concepts across different document chunks. This results in responses that are more accurate, comprehensive, and explainable.

Key Benefits of GraphRAG

  • Contextual Relevance: It identifies relationships between entities (e.g., companies, people, locations) and structural elements (e.g., section titles) across your documents.
  • Improved Summarization: By understanding the hierarchy and connections in data, the model can filter out noise and focus on key content.
  • Explainability: Responses rely on the graph structure, allowing for better traceability of how different pieces of information are connected.
Note: GraphRAG requires both Amazon Bedrock Knowledge Bases and Amazon Neptune Analytics to be available in your selected AWS Region.

Step-by-Step Implementation

1. Setup and Prerequisites
For this module, we use the Anthropic Claude 3 Haiku model for generation and Amazon Titan Embeddings v2 for vectorization. The setup involves initializing the Boto3 clients (bedrock-agent-runtime, s3, etc.) and defining the necessary IAM roles.
2. Creating the Knowledge Base with Neptune Analytics
The core differentiation in this module is the configuration of the Knowledge Base. Unlike previous modules that used OpenSearch Serverless, this implementation uses Amazon Neptune Analytics as the vector store.
The critical configuration parameter here is the chunking strategy:
  • chunking_strategy = "GRAPH": This tells Amazon Bedrock not just to split text, but to extract entities and build a graph representation of the data during ingestion.
  • vector_store = "NEPTUNE_ANALYTICS": Specifies that the graph and embeddings will be stored in Neptune.
3. Ingesting Data
We use a synthetic dataset of financial 10K reports (e.g., Octank Financial) uploaded to Amazon S3. When the start_ingestion_job() function is called:
  1. Bedrock reads the documents from S3.
  2. It extracts text and metadata.
  3. It identifies entities and relationships (building the graph nodes and edges).
  4. It generates embeddings for these chunks using the Titan model.
  5. All data is indexed into the Neptune Analytics graph.
4. Testing the Knowledge Graph
The notebook demonstrates two ways to query your GraphRAG application:
  • retrieve_and_generate API:
    • Query: "Provide a summary of consolidated statements of cash flows of Octank Financial..."
    • Mechanism: The system queries the Neptune graph to find relevant nodes and their connected entities. It retrieves this structured context and passes it to Claude 3 Haiku to generate a natural language summary.
  • retrieve API:
    • Query: "How many new positions were opened...?"
    • Output: This returns the raw chunks (nodes) from the graph along with their location, similarity score, and metadata. This is useful if you need to inspect the graph data or build a custom retrieval pipeline.

Clean Up

GraphRAG involves provisioning specific infrastructure in Amazon Neptune. To avoid incurring unnecessary costs, the final step of the notebook performs a comprehensive cleanup:
  • Deletes the Knowledge Base and Data Sources.
  • Deletes the underlying Neptune Analytics Graph.
  • Removes the S3 buckets and IAM roles.
  • Command: knowledge_base.delete_kb(delete_s3_bucket=True, delete_iam_roles_and_policies=True)
Conclusion
This module demonstrates the cutting edge of RAG technology. By integrating knowledge graphs, you move beyond simple keyword matching to deep semantic understanding, enabling your AI application to answer complex questions that require reasoning across multiple documents.
# ai-for-developers# rag# knowledge-bases-for-bedrock# amazon-bedrock# amazon-sagemaker-ai
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article