I Took the Wheel Off My RAG: Managed KB vs. Manual Chunking

In April I published a benchmark comparing 5 chunking strategies in Amazon Bedrock Knowledge Bases. The practical conclusion was simple: FIXED_SIZE with S3 Vectors as the backend, and that’s it, unless your data justifies something more complex.

Three months later, AWS took the question away from the problem entirely. Amazon Bedrock Managed Knowledge Base doesn’t ask you to pick a chunking strategy. Smart Parsing decides parsing by document type, AWS manages the vector store, and if your questions are complex, AgenticRetrieveStream plans a retrieval strategy instead of running a single similarity search.

Sounds like April’s discussion is obsolete. So I asked the question that felt honest to me: how much does it cost in quality to have the wheel taken away from you, and under what conditions do you get that loss back?

I didn’t have a thesis before running this. I have one now, and it’s not the one I expected.

🎯 Spoiler: Simple managed retrieval practically ties my manual April configuration. What didn’t work is the agentic planner —the piece that justifies the “agentic” in the name— with the model AWS gives you by default: it didn’t decompose a single query across 80 evaluated questions.

This article covers the full methodology: five retrieval configurations over the same corpus, two question sets —the original 25 single-hop questions from April untouched, and 15 new multi-hop questions written against the actual document text—, three different planners, and the 6 infrastructure gotchas I had to resolve before I could measure anything. Because the planner finding has a twist: it depends entirely on which model does the planning, and I didn’t know that until I stopped using the one that ships by default.

📌 TL;DR — Key data before you keep reading

• Managed KB with simple Retrieve ≈ my manual April configuration in Correctness (0.88 vs. 0.84, a difference within the expected range).
• Smart Parsing ingests without failing the two PDFs that broke SEMANTIC and NONE in April — and does it faster than my manual pipeline (183s vs. 407s). It even ingests and correctly retrieves a PDF with no extractable text layer.
• AgenticRetrieveStream with the default planner (MANAGED) never generated a single sub-query across 80/80 evaluated questions, including ones a simple retrieval demonstrably couldn’t solve.
• On multi-hop questions, that made the “agentic” retriever land below simple retrieval (0.50 vs. 0.567 Correctness).
• With a small CUSTOM planner (Claude Haiku 4.5), real decomposition does show up — but on questions that no longer needed it, not on the 5 that did.
• With a large CUSTOM planner (Claude Sonnet 4.6, the same model as my generator), multi-hop Correctness jumped from 0.50 to 1.00, sustained across two independent runs — but the planner and generator share the same model in that test, and I’m stating that explicitly as a caveat, not as fine print.
• The corpus isn’t byte-identical to April’s: my original bucket was destroyed and I had to re-download the documents. I’m saying that explicitly, not hiding it.

Why This Matters to Me

This isn’t academic curiosity. If you’re evaluating whether to migrate a production RAG to Managed Knowledge Base, the real question isn’t “is it better?” — it’s “what do I lose by giving up control of chunking, and what do I gain if I also let the service decide when and how to search more than once?”

That second part is what almost nobody measures. AWS presents AgenticRetrieveStream with numbers from an academic benchmark (MuSiQue) showing gains of up to +37 recall points on 4-hop questions. Those are real numbers, published on their official agentic retrieval blog post, and I break them down further down. But an academic benchmark doesn’t tell you what happens when the planner you get by default, without touching a single parameter, meets your own corpus.

That’s what I ran.

The Design: Five Configurations, Two Question Sets

I kept the generator (Claude Sonnet 4.6) and the judge (Nova Pro, cross-family) constant across four of the five configurations —the only exception is D, where the service itself generates— to isolate the retrieval layer as the sole variable:

The first four ran together. I added E a day later, as a direct response to what I found with C — I cover it in detail further down, in its own section, so as not to mix an exploratory run with the original pre-registered design.

And two question sets over the same corpus of 3 technical documents (the Well-Architected Framework, the AgentCore developer guide, and a RAG evaluation blog post):

• 1-hop set: the 25 original single-hop questions from April. Untouched, for comparability.
• Multi-hop set: 15 new multi-hop and comparative questions, written against the actual document text, not against summaries.

🔍 ProTip #1: If you’re going to compare an “agentic” retriever against a simple one, you need two question sets, not one. AWS itself reports that its gain on single-hop questions is under 5 recall points. Running only single-hop questions against a retriever that plans is measuring something you already know in advance won’t show a difference — that’s not a benchmark, it’s a confirmation.

A fairness control that cost me time but was non-negotiable: I re-ran configuration A in full, I didn’t reuse the scores published in April. Those came from the native retrieveAndGenerate path; B, C, and D can only be evaluated through the bring your own inference responses (BYOI) path. Comparing scores produced by two different evaluation mechanisms would have been exactly the kind of methodological trap I criticize other benchmarks for.

First Gotcha, Before Writing a Single Line of Retrieval Code

My original plan was to reuse April’s Knowledge Base as-is. I couldn’t.

April’s KB and its corpus bucket no longer existed. That wasn’t an oversight — I’d intentionally destroyed them after publishing the article, as I do with almost all my benchmark infrastructure. Verified against the real account before assuming anything: list-knowledge-bases returned zero results across five regions, the S3 Vectors bucket had no buckets, and the corpus bucket returned NoSuchBucket.

I had to recreate just the FIXED_SIZE module from April’s repo (Titan v2, 1024 dimensions, 512-token chunks, 20% overlap) — without the other 4 chunking modules, which weren’t needed for this benchmark.

And here’s the uncomfortable part I do need to say: the corpus couldn’t be byte-identical to April’s. The data folder was in the .gitignore of the original repo — I never versioned the actual content, so there was no hash or manifest to compare against. Verified by HTTP HEAD:

The AgentCore developer guide practically doubled in size over four months, which makes sense — it’s the service that’s evolved the most in that period. I’m reporting this as an explicit limitation of the re-run. I’m not hiding it, not minimizing it, and I also don’t think it invalidates the comparison: the documents are still the same class of content (dense AWS technical documentation), which is what April’s benchmark needed to be representative.

⚠️ ProTip #2: If you’re going to publish a benchmark you plan to revisit months later, version the corpus with a public hash (even if you don’t upload the full files). I didn’t do that in April, and it cost me the ability to claim “byte-identical” with evidence, not just intent.

Second Batch of Gotchas: Creating and Querying a Managed KB Isn’t Like a Regular One

Six real infrastructure problems, none of them documented together anywhere I could find.

1. Retrieve against a Managed KB rejects vectorSearchConfiguration. My April code used that parameter with no issue against the S3 Vectors KB. Against the Managed KB, the service responded:

ValidationException: Incompatible configuration: vectorSearchConfiguration
is not supported for managed knowledge bases. Use managedSearchConfiguration
instead.

Same internal shape, different container key. Config A uses one, config B needs the other.

2. Creating an S3 data source with type=S3 fails on a Managed KB. The error:

ValidationException: Unsupported data source type for MANAGED knowledge
base type.

The correct form —which I only found against a real AWS example, not against the shape’s reference documentation— is type=MANAGED_KNOWLEDGE_BASE_CONNECTOR, with the connector’s configuration nested one level deeper than feels intuitive.

3. Creation is asynchronous in a way I didn’t expect. With Terraform, config A accepts CreateKnowledgeBase and CreateDataSource back-to-back with no waiting. Against a Managed KB, calling CreateDataSource while the KB is still CREATING fails with ConflictException. You have to poll until AVAILABLE before continuing — typically 2-5 minutes.

4. ragSourceIdentifier in the eval job isn’t a free-form label. I tried giving it a descriptive name ("D-setA") and the service rejected it: it has to match exactly the knowledgeBaseIdentifier carried by each line of the BYOI dataset, or it fails with ValidationException.

5. The eval job’s output schema is different from the one documented for “automated MODEL evaluation”. That documented schema uses automatedEvaluationResult.scores at the root. The real one, confirmed against raw output in S3, is conversationTurns[].results[], with a single JSONL per job at a path the service generates.

6. The judge sometimes can’t extract a score. A real example, verified against the raw JSONL: for the question “Summarize the design principles of the Operational Excellence pillar” (config A, 1-hop set), Nova Pro answered in natural language with a perfectly coherent explanation, but Builtin.Faithfulness came back result: null with the message Unable to parse score from the LLM judge response. It’s not that the judge failed to reason — the service simply couldn’t parse a number out of that specific response. I’m reporting it and counting it in the final tally, not averaging it away by hiding it.

Figure 1: The judge’s response is coherent and correctly lists the principles, but the service failed to extract a numeric score from that text. The error is documented right in the console.

With that resolved, I was able to confirm something that broke in my favor: Smart Parsing ingests without complaint the two PDFs that broke SEMANTIC (1 MB limit) and NONE (50,000-character limit) in April. The job finished COMPLETE, 3 of 3 documents indexed, 0 failed, in roughly 183 seconds — faster than my manual FIXED_SIZE + S3 Vectors pipeline over the same corpus (~407 seconds).

I went a step further to really stress-test Smart Parsing: I generated a synthetic 2-page PDF with no extractable text layer at all —confirmed with pypdf that extract_text() returns an empty string on both pages, only content rasterized to image— and added it to the corpus. The ingestion job finished COMPLETE all the same, no failures, no skipped documents. And it didn’t stop at “accepted it in name only”: a direct Retrieve with a query about that PDF’s content returned the correct text as the top result, score 0.981, pointing exactly at the file. The Knowledge Bases documentation does list scanned documents among the types Smart Parsing automatically selects for, but it doesn’t name the mechanism: that it runs OCR internally is something I’m inferring from the result, not from an explicit promise.

That’s already a data point with real weight: if your corpus has large or scanned files that break manual chunking, Managed KB solves a real problem for you without you having to think about it.

The Results

Nova Pro judge and BYOI across all configurations, with the same scripts for A, B, C, and D. A single run per cell — not averaged over multiple executions, so take it as signal, not statistical certainty.

Figure 2: All 8 combinations of the original design (configurations A-D × 2 sets) finished Completed in the RAG evaluations console. None got stuck halfway or failed silently.

Row E ran a day after A-D, as a direct follow-up to the planner finding — the full detail, including the caveat that the planner and generator share the same model there, is in its own section further down.

And the verdict on the five hypotheses I pre-registered before running anything:

Figure 3: RAG evaluations’ native comparison view, config B (simple Retrieve) against config C (AgenticRetrieveStream) on the multi-hop set. The “agentic” retriever loses on 3 of 4 metrics and ties on the fourth.

Four of five hypotheses held. The one that fell is the interesting one, and it didn’t fall by a little.

With a scope caveat on H3. What that hypothesis evaluates is the MANAGED planner, the default. Further down you’ll see that with a large CUSTOM planner, the pattern H3 predicted does show up — and that doesn’t rescue it, because it was refuted exactly as I wrote it, for the planner it measured. What it does leave is the question I chase through the rest of the article: is what matters the planner’s size, or the fact that a large planner ends up sharing a model with the generator?

The Main Finding: The Planner Never Planned

H3 isn’t a “didn’t help much.” It’s a measured regression: on the question set where the agentic retriever should shine, it ended up worse than single-step simple retrieval.

And it has an identified mechanical cause, not a statistical mystery. I reviewed the full trace of all 80 agentic questions run (configurations C and D, both full sets). In 100% of cases, the structure was identical: a single Retrieval step —the speculative pass with the raw query— followed by a Planning step that returned "actions": []. A second Retrieval step never appeared. FullDocumentExpansion never appeared. The planner never generated a single sub-query, not even on the multi-hop set questions where I already knew —from a separate check I did before running the benchmark— that single-step retrieval didn’t reach both relevant documents.

A concrete example. For the question “which AgentCore component applies logic similar to the Security pillar’s ‘Keep people away from data’ for code execution?”, the initial speculative Retrieval brought back only content from the AgentCore developer guide —Code Interpreter, session isolation, security controls— and nothing from the Well-Architected Framework. The subsequent Planning step decided that was already enough.

Figure 4: Raw trace for this same question. After the single Retrieval step, the Planning event with "message": "Agent planning completed" returns "actions": [] — the planner considered the work done without generating a single sub-query.

🎓 ProTip #3: If you’re going to measure “iterations” of an agentic retriever, don’t count trace steps — count real sub-queries. A Planning step that returns actions: [] still counts as an iteration in the iterations field the SDK exposes, but it doesn’t represent any decomposition work. It’s the difference between “the planner ran” and “the planner planned”.

Is This a Bug? I Went to Verify It Against the Source

Before publishing this as a finding, I checked it against the official AWS post dedicated entirely to this capability, Agentic retrieval for Amazon Bedrock Managed Knowledge Base — the same one that’s the source of the MuSiQue numbers I cite above. Three things get confirmed, one gets nuanced.

It confirms this isn’t a problem with my data capture. The documentation describes the Retrieval/FullDocumentExpansion step as “one event per executed sub-query.” My code logs any step that arrives in the stream, with no name filtering. If the planner had decomposed even once across 80 questions, it would have shown up in the trace. It never did.

It confirms that exiting early is documented behavior, not a bug. The docs explicitly say the planner “may exit early after its evaluation step determines the evidence is sufficient.” 100% of my cases are exactly that — a normal service state, not a failure.

It confirms the MuSiQue numbers I already cited, with their exact values: +22.8, +31.9, and +37.3 recall points on 2-, 3-, and 4-hop questions, with gains under 5 points on single-hop questions.

And it nuances something important: the post’s two official code examples —single-KB and multi-KB— use foundationModelType: "CUSTOM" with an explicit model. Neither uses the default value (MANAGED). The same post recommends as best practice “starting with a small, fast planner,” which implies deliberately choosing a model, not trusting the default.

That leads me to the most honest conclusion I can give: I can’t claim “AgenticRetrieveStream doesn’t decompose” in general. I can only claim, with evidence from 80 of 80 questions, that the default managed planner —the one anyone who hasn’t read this AWS blog post gets— never exercised its decomposition capability on my corpus, not even when the retrieved evidence was insufficient. That all the official reference documentation uses CUSTOM is, in itself, a data point: it suggests AWS doesn’t expect the managed model to reliably decompose either, without the user choosing their own planner.

I Tried the Obvious Fix: My Own Planner

I configured foundationModelType=CUSTOM with Claude Haiku 4.5 as the planner —a “small, fast” model, exactly what AWS recommends, and different from both the generator (Sonnet 4.6) and the judge (Nova Pro), so as not to contaminate either role.

I kept this run separate; it doesn’t replace configuration C’s official results, which remain with the managed planner, because that’s what the benchmark’s design deliberately measures.

Something did change. With Haiku 4.5 as the planner, 3 of the 15 multi-hop set questions showed planning_actions > 0 — the planner generated real sub-queries, something that never happened even once across the 80 questions with the managed planner. On the single-hop set, 0 of 25 decomposed, which is consistent: it isn’t needed there.

But it didn’t change what actually mattered. The 5 cross-document questions where simple Retrieve demonstrably failed to bring back evidence from both documents —I separately confirmed the missing content was properly indexed, this wasn’t an ingestion problem— still came back with a single document, exactly like with the managed planner. The CUSTOM planner decomposed questions that already had sufficient evidence in a single pass, and didn’t touch the ones that genuinely needed both sources.

💡 ProTip #4: Switching from the managed planner to your own isn’t a magic button that fixes cross-document multi-hop, at least not with a “small, fast” model like AWS recommends. The publishable result, with what I have so far, is: changing the planner helps the planner work, it doesn’t guarantee it works on the right questions.

One obvious question remained unanswered: what if the planner isn’t just different, but large? I tested it, and the result made me rewrite this section twice.

I Went Up a Weight Class: A Large Planner (And a Role Collision I Need to Name)

AWS’s official blog mentions two candidates as a “large” planner: Claude Sonnet 4.6 and Amazon Nova Premier. Before running anything, I checked which one was still viable against the real account, not against the docs — and found a problem.

Figure 5: Nova Premier shows up marked Legacy in the model catalog. Verified in more detail: startOfLifeTime=2025-04-30, legacyTime=2026-03-13, endOfLifeTime=2026-09-14 — twelve days after this session.

Nova Premier gets ruled out not by design preference, but because anyone trying to reproduce this benchmark after September 14 couldn’t use it even if they wanted to. That left me with just one “large” alternative cited by AWS: Sonnet 4.6, the same model I already use as the constant generator in A, B, C, and D.

I need to be explicit here about what this breaks: my own design rule for the Haiku run was to keep the planner isolated from the generator and judge, precisely so as not to contaminate any role. Config E breaks that rule on purpose, documented as a deviation, not an oversight. The result that follows can’t be read as “pure large planner” — it has to be read as “large planner that’s also the same model that generates the response afterward”.

With that caveat already on the table, the numbers:

Sonnet 4.6 decomposed almost three times as often as Haiku. Of the 5 cross-document questions that neither MANAGED nor Haiku solved (b04, b08, b09, b11, b14), verified by searching for Well-Architected Framework-specific vocabulary in the retrieved chunks:

• b04 and b14 get fixed — they now do bring back WAF content.
• b08 partially improves — some WAF, not as much as the previous two.
• b09 and b11 still miss the side that was missing — b09 even generated a sub-query, but not toward the right document; b11 didn’t even decompose.

Figure 6: b14 solved with the Sonnet 4.6 planner. The question crosses the Well-Architected Framework’s sustainability principle Maximize utilization with AgentCore Runtime’s Instances mode — two different documents. The answer cites retrieved passages 11 and 13, matches the ground truth, and the judge gives it Correctness 1.

In other words: a bigger planner decomposes more, but doesn’t guarantee it decomposes well. Two of five problem questions are still broken even with the most capable model I could test.

And the eval job with Nova Pro, same 4 metrics:

Figure 7: Native comparison of the two eval jobs on the multi-hop set. E’s area dominates C’s on all four measured metrics, with the widest gap in Correctness. The other radar axes sit at 0 because those evaluators weren’t part of the job.

On the single-hop set the difference is small (0.90 vs. 0.88 Correctness), consistent with H2: a planner, whatever its size, shouldn’t add much when a single step is already enough. On the multi-hop set the jump is large: Correctness goes from 0.50 (C) to 1.00 (E) — above even B (simple Retrieve, 0.567) and D (MANAGED planner + service generation, 0.70).

Is It Real, or a Lucky Single Roll?

Before publishing a jump of that magnitude, I repeated the full C and E run on the multi-hop set the next day — same 15 questions, same corpus, same models, retrieval/generation/evaluation pipeline run from scratch, with its own independent evaluation job.

The result holds. E’s Correctness came out exactly 1.00 across both independent runs — it’s not an artifact of a lucky roll. C stays low in both, with a 0.033 difference between runs that’s normal judge noise, not a trend. The gap between C and E in Correctness is stable; the other three metrics vary a bit more run-to-run (up to 0.05) but never cross the gap between configurations.

⚠️ ProTip #5: A jump from 0.50 to 1.00 in a single run of 15 questions is exactly the kind of number that invites suspicion of an artifact — an average inflated by discarded records, a miscounted null_result. Before publishing any jump that large, repeat the full run from scratch. If it doesn’t hold, it was noise. If it holds, as it does here, you have real evidence worth reporting with confidence.

The honest reading, with all its caveats:

1. N=15 is still a small set. The pattern repeats across 2 runs, but that doesn’t replace a larger N. The direction of the effect is well-supported; the exact values for Completeness, Faithfulness, and Helpfulness carry more run-to-run noise than Correctness.
2. The planner and generator share a model, the deviation already declared above. I can’t rule out that part of the gain comes from Sonnet 4.6, as planner, “knowing better what it’s going to be asked next” — a self-consistency effect, not necessarily better decomposition reasoning in the abstract.
3. It doesn’t close the problem entirely. b09 and b11 remain unresolved even with the most capable planner I could test — the gain is real, but partial: 2 of 5 questions fixed, 1 partial, 2 unchanged.
4. The clean comparison (Nova Premier) isn’t available due to its EOL date. This run can’t isolate “larger planner” from “planner that’s also the generator” — that separation would have required a third large model without that role conflict.

The conclusion the evidence does support: a CUSTOM planner larger than Haiku decomposes more often (8/15 vs. 3/15 on the multi-hop set) and, when it decomposes toward the right side, moves the metrics substantially — something Haiku never managed to demonstrate. What I can’t cleanly separate, with this design, is how much of that gain is “more capable model” and how much is “same model that already generates the final answer”.

What Changed Since April (And What Didn’t)

One claim from April is now outdated, and two assumptions I started this benchmark with turned out to be wrong. All three get corrected here.

Claude Sonnet 4.6 is now on the judge allowlist for RAG/KB evaluation specifically. In April I had to use Nova Pro because of that restriction, so I left the corresponding update note in the original article instead of leaving that fact hanging there. Even so, I kept Nova Pro as the judge in this benchmark: the design calls for a cross-family judge as an independent fairness control, to avoid the self-preference bias known in LLM-as-judge setups when the judge shares a family with the generator (which is still Sonnet 4.6 in A, B, and C). The new availability doesn’t change that design logic.

The other two are corrections to my own prior research, not to what was published in April.

foundationModelType accepts CUSTOM and MANAGED, with MANAGED as the default. This wasn’t clear in the first pass over the public documentation I did before running anything — only CUSTOM examples were documented. Confirmed both against the updated API reference and against the real botocore shape in the account.

The first boto3/botocore version that supports AgenticRetrieveStream is 1.43.32 — that release shipped the operation and “Managed Knowledge Bases” together, in the same API commit. My machine’s global Python had an older version; I had to isolate the project in its own virtualenv.

Decision Table

With the data in hand, here’s what I’d tell someone evaluating this migration today:

What’s Still Open

This benchmark, like April’s, has a deliberately bounded scope:

• Isolating planner size from role collision. Config E uses Sonnet 4.6 as both planner and generator. The clean separation would have been a large model different from both — Nova Premier was the only option AWS cited, and it fell out of scope due to its end-of-life date (September 14, 2026).
• Larger N on the multi-hop set. 15 questions, even replicated across two runs, is still too few for serious confidence intervals.
• Multi-KB routing, AgenticRetrieveStream’s other core capability that I didn’t touch here — this benchmark used a single Managed KB across all configurations.
• Cost per query compared across planners. This benchmark measures quality and latency, not cost. And the question left open is fairly concrete: if a large planner decomposes almost three times as often, how much does the per-query bill go up against the gain in Correctness? That gets answered by measuring planning tokens per query, not by looking at aggregate account spend.
• Spanish-language corpus, out of scope just like in April.
• Solving b09 and b11, the two cross-document questions that neither the managed planner nor any CUSTOM planner I tested fully solved.

If you replicate this in your own account and the managed planner does decompose on your corpus, I want to know — it would be evidence that the behavior depends more on content type than my data suggests.

Conclusion

Managed Knowledge Base isn’t a quality regression. On simple retrieval, it does the same as my manual April configuration, and it effortlessly solves the ingestion problem that broke two of the five chunking strategies in April. If your only question is “do I lose quality by giving up chunking control?”, the answer with this data is no.

But the “agentic” in AgenticRetrieveStream’s name promises something the default planner doesn’t deliver, and a poorly chosen planner doesn’t guarantee either. It’s not misleading marketing —AWS documents early-exit behavior as normal, and its own code examples never use the default— but it is an easy trap to fall into if you turn the feature on expecting it to “be smarter” without explicitly choosing who does the reasoning. With the managed planner, it was a measured regression. With a small planner, it was real but poorly aimed decomposition. With a large planner —even though it shared a model with my generator, a cleanup I couldn’t fully isolate due to Nova Premier’s retirement— Correctness on multi-hop questions doubled, sustained across two independent runs.

The real advice, if you’re working with this in production, isn’t “turn on the agentic retriever.” It’s “turn on the agentic retriever, pick your own planner —and probably a bigger one than you feel like trying first—, and measure on your own corpus whether it decomposes the questions that genuinely need it.” Because the range I found on the same corpus, with the same multi-hop question, went from “worse than not using it” to “twice as good as using it without thinking,” depending on who was planning.

The full benchmark code —Terraform, numbered scripts, the 15 multi-hop questions with their cross-verification, and the BYOI datasets— is at github.com/codecr/mkb-vs-chunking.

🚀 Final Pro Tip: Before turning on any “agentic” feature in production, ask yourself which model is making the planning decisions and whether that model is the one you chose or the one the service chose for you. And if you’re the one choosing, don’t settle for the first “small, fast” model the documentation suggests — in my benchmark, the difference between a small planner and a large one was bigger than the difference between having a planner and not having one at all.

If you want the full context, the original chunking benchmark is still the reference for manual configurations. And if what you want is to expose a Managed KB as an MCP tool for your agents, that path goes through AgentCore Gateway as a Knowledge Base target —the connector exposes AgenticRetrieveStream and Retrieve as MCP tools— and my article on Amazon Bedrock + MCP covers the protocol context.

See you in the next article! If you replicated this or tried a different planner, tell me about it in the comments — with this particular finding, the more eyes that verify it, the better. 🚀

Official Resources 📚

• Blog: Agentic retrieval for Amazon Bedrock Managed Knowledge Base — source of the MuSiQue numbers and the foundationModelType=CUSTOM examples
• Blog: Build enterprise search for agents with Amazon Bedrock Managed Knowledge Base
• API Reference: AgenticRetrieveStream
• Use agentic retrieval to query a knowledge base
• Build a managed knowledge base
• Create a managed knowledge base
• Customize ingestion for a data source (Smart Parsing by default)
• Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases
• Connect to your knowledge base through AgentCore Gateway (KB as an MCP tool)
• Amazon Bedrock Managed Knowledge Bases as Connector Target
• Evaluate the performance of RAG sources using Amazon Bedrock Evaluations
• Creating a retrieve-and-generate RAG evaluation job (BYOI path)
• Announcement: Amazon Bedrock RAG Evaluation generally available (March 2025)
• Blog: Evaluate models or RAG systems using Amazon Bedrock Evaluations — now GA