Deconstructing the Cloud Value Add
I rebuilt a RAG pipeline on two different cloud providers and came to the same conclusion.
I rebuilt the same RAG pattern twice last week.
Once on AWS: Titan embeddings into S3 Vectors, with retrieval logic I owned. Once in vCTOA on GCP: Gemini embeddings into Firestore vector search, with my own hybrid retrieval policy sitting above it.
Different clouds. Same lesson.
The managed RAG product is not the architecture. The architecture is the evidence model. The managed products are Bedrock Knowledge Base on AWS and Discovery Search on GCP.
Managed services are convenient. I’ll happily borrow the vendor’s judgment on plumbing: auth, scaling, APIs, storage durability, vector indexes, operational mechanics. The question is what happens when you stack borrowed judgment on top of borrowed judgment.
That is where DAPM drift starts. The focus here is the RAG pipeline, but I see this pattern across many of the services cloud providers are stacking into managed offerings.
Chunking is one of those decisions.
A transcript has natural seams. So does a log line, a support ticket, a contract clause, a design document, a framework definition, or a customer interview. Those seams are domain knowledge. They are not preprocessing details.
When a default chunker flattens the source material, it does more than split text. It changes the unit of evidence. It changes what metadata survives. It changes what can be filtered later. It changes what the model is allowed to retrieve.
This surfaced in the quality of semantic search in vCTOA. I know the corpus well. I’d ask vCTOA about recent topics I’d discussed across it, and even though the data existed in both the corpus and the index, one-size-fits-all chunking gave me results with weak evidence.
Before deconstructing the pipeline, I added every kind of hack to improve the evidence. All of it added latency to the application.
In the AWS build, the useful path was not exotic. Same Titan embedding model. Same S3 Vectors substrate. The difference was that I kept the chunking knob.
One pre-segmented unit became one vector. My labels stayed attached. That 1:1 control let me filter retrieval by category later instead of hoping semantic search guessed the right neighborhood.
The GCP version of vCTOA is the same pattern. I retired the always-on managed vector search index and moved retrieval to Firestore vector search, but kept the retrieval policy in application code: framework graph first, time-scoped search next, full corpus fallback only when needed.
That is the pattern I trust now. Rent the plumbing. Own the chunking.
Because chunking is the cheapest thing to get wrong and one of the hardest things to claw back after a service has already decided what your evidence is.