Migration of Credit AI RAG Application from Multi-Cloud to AWS Bedrock

octus · Finance · 2023 · source Agentic: no · promotional bias: high · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Finance

Octus needed to migrate a production Credit AI RAG product from fragmented multi-cloud infrastructure to a simpler, scalable, compliant architecture.

Constraints:

Architecture

Octus migrated Credit AI from a split Azure/OpenAI plus AWS estate into an AWS-centered RAG architecture. Ingestion starts when new documents trigger Lambda validation, metadata extraction, and Textract layout/text extraction; extracted content is stored separately in S3 with lineage to source documents, chunked through Bedrock knowledge-base workflows, embedded with Cohere, and indexed in Amazon OpenSearch. The Q&A path runs through a Fargate web app and Amazon MSK orchestration layer, embeds the user query, retrieves chunks from OpenSearch, applies Bedrock Guardrails for content safety, PII, hallucination, and relevancy controls, then generates a response. Supporting data services, Terraform/CI-CD, Datadog/CloudWatch/PagerDuty, and per-client knowledge-base isolation carry the production/compliance load.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  lambda-ingestion["lambda-ingestion"] --> amazon-textract["amazon-textract"]
  amazon-textract --> s3-extracted-content["s3-extracted-content"]
  s3-extracted-content --> bedrock-knowledge-bases["bedrock-knowledge-bases"]
  bedrock-knowledge-bases --> cohere-embedding-model["cohere-embedding-model"]
  cohere-embedding-model --> amazon-opensearch["amazon-opensearch"]
  fargate-web-app["fargate-web-app"] --> msk-orchestration["msk-orchestration"]
  msk-orchestration --> cohere-embedding-model
  msk-orchestration --> amazon-opensearch
  msk-orchestration --> bedrock-guardrails["bedrock-guardrails"]
  bedrock-guardrails --> bedrock-generation["bedrock-generation"]
  unified-data-services["unified-data-services"] --> msk-orchestration
  msk-orchestration --> monitoring-alerting["monitoring-alerting"]
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
lambda-ingestion Validates incoming document type/size, extracts metadata, and starts document-processing work. amazon-textract, s3-extracted-content
amazon-textract Extracts text, structure, layout, and relationships from financial documents before LLM processing. lambda-ingestion, s3-extracted-content
s3-extracted-content Stores extracted document content in a separate prefix with lineage back to the source document. amazon-textract, bedrock-knowledge-bases
bedrock-knowledge-bases Chunks extracted content, manages RAG workflow steps, and integrates reranking/knowledge-base capabilities. s3-extracted-content, cohere-embedding-model, amazon-opensearch
cohere-embedding-model Generates embeddings for chunks and user queries using a managed model rather than self-hosted GPUs. bedrock-knowledge-bases, amazon-opensearch, msk-orchestration
amazon-opensearch Vector store and retrieval engine for relevant chunks. cohere-embedding-model, msk-orchestration
fargate-web-app Hosts the user-facing web app and performs initial user validation before query orchestration. msk-orchestration
msk-orchestration Streaming inter-service communication layer that coordinates the query cycle and calls retrieval/model services. fargate-web-app, cohere-embedding-model, amazon-opensearch, bedrock-guardrails, bedrock-generation
bedrock-guardrails Applies content filtering, PII prevention, hallucination controls, and relevancy checks inside the answer pipeline. msk-orchestration, bedrock-generation
bedrock-generation Generates the final answer from retrieved context under AWS Bedrock-managed model access. msk-orchestration, bedrock-guardrails
unified-data-services Normalizes financial identifiers, document ingestion, reference data, and APIs consumed by Credit AI and other Octus products. msk-orchestration
monitoring-alerting Provides Datadog, CloudWatch, and PagerDuty visibility/alerting for production migration operations. msk-orchestration

Data flow

For ingestion, a new document triggers Lambda, which validates document type and size, extracts metadata, calls Textract for text/layout/structure, and writes extracted content to a separate S3 prefix with lineage. Bedrock chunks that text, Cohere creates vectors, and OpenSearch stores them for retrieval. For Q&A, the Fargate web app validates the user, MSK coordinates the query cycle, the query is embedded, relevant chunks are fetched from OpenSearch, Bedrock Guardrails checks quality and security, and the model generates the answer back to the user. Data services supply normalized financial identifiers and document APIs, while monitoring and alerting watch the production system.

5 supporting quotes
“As soon as the new documents, new data come in, Lambda gets triggered to do that initial validation, first on the document types, document size, and extract the relevant metadata from each document.”transcript, stated
“Amazon Textract is responsible to extract the text and the structural information from the document while preserving the document layout and relationship between different content elements.”transcript, stated
“make a call to a Cohere embedding model to get the semantics or the vectors for those chunks and store it in a vector store. Here, Octus chose Amazon OpenSearch Service for efficient retrieval.”transcript, stated
“First, the web app is hosted on AWS Fargate which scales as per the traffic. And going back to the non-negotiable requirement on scaling and less maintenance or overhead”transcript, stated
“It has out-of-the-box integration with Amazon Bedrock Guardrails so that you can have quality checks and security controls right within your pipeline.”transcript, stated

Why this architecture

Octus wanted to simplify a component-heavy multi-cloud system without losing swapability, compliance, or production scale. Bedrock consolidated managed RAG steps, model access, guardrails, and AWS service integration where most Octus data/services already lived. The architecture pushes undifferentiated RAG infrastructure to managed providers, keeps per-client knowledge bases physically isolated for compliance, and leaves engineering teams focused on customer features instead of GPUs, CUDA errors, cross-cloud data movement, and external safety calls.

4 supporting quotes
“We wanted to simplify that architecture by pushing the expertise to the provider as much as we can so that we can actually focus on building high-value features for our customers”transcript, stated
“The multi-cloud approach has its own set of challenges and costs, not to say that you cannot achieve it. But if you can simplify, why not?”transcript, stated
“we have a lot of services and data in AWS already backing our other products. So there's an economy of scale between those services and services that are powering Credit AI.”transcript, stated
“they wanted to have these physical isolation or boundaries between these two knowledge bases and don't want to rely on the client ID on the documents.”transcript, stated

Models used: Cohere embedding models · Amazon Bedrock models

Scale

Alternatives considered (roads not taken)

Continue operating a split Azure/OpenAI plus AWS architecture

Rejected because: The split required shuttling data between clouds and increased operational complexity and cost.

“we have partly product hosted in Azure, which is the OpenAI side of Credit AI, but then everything else is in AWS. That led us to a couple of different challenges.”transcript, stated
“we have to shuttle data back and forth between AWS and Azure, which led to its own set of operational challenges and complexity.”transcript, stated

Fixed-size chunking for the production document corpus

Rejected because: It worked for small documents but performed poorly on long, complex financial documents because chunks could cut mid-sentence, mid-paragraph, or mid-table.

“with any POC, we tried was fixed. It works well as long as you have small documents. But Octus had long, complex documents.”transcript, stated
“it might chunk the document mid-sentence, mid-paragraph. Or if you have a long financial table, it can chunk mid-table. So for large, complex documents, the results were not promising.”transcript, stated

Hierarchical parent/child chunking with larger parent chunks

Rejected because: It produced promising results, but the chosen Cohere embedding model had a 512-token limit that could not handle larger parent chunks.

“When Octus tried that, it gave really promising results. So the idea here is to have a two-layer structure.”transcript, stated
“But here there is a catch. The embedding model which they chose had a token limit of 512 tokens. So the larger parent chunks were not being handled by the Cohere embedding model.”transcript, stated

Self-hosted embedding models on dedicated GPUs

Rejected because: The self-hosted setup was costly, hard to scale, and could take down the whole pipeline when the instance failed.

“Octus was managing these embedding models on dedicated GPUs, which was giving them challenges to scale, and it was very costly.”transcript, stated
“previously, once that instance goes down, the entire pipeline is down. Now, because of the managed service, they don't need to worry about the model upgrades or the CUDA errors.”transcript, stated

External third-party hallucination/relevancy checks

Rejected because: TrueLens added latency, cost, and another external call; Bedrock Guardrails put safety and relevancy checks in the pipeline.

“Earlier, Octus was using a third-party application, TrueLens, to make the call. And that added latency and some more cost to their infrastructure.”transcript, stated
“So instead of having multiple calls and bringing external service complexity, it's one call and there is built-in safety as part of Amazon Guardrails.”transcript, stated

Patterns

rag-retrieval (retrieval)

Credit AI uses managed RAG capabilities for ingestion, retrieval, prompt augmentation, and response generation.

“Where you can build the entire end-to-end workflow, whether it is ingesting documents, retrieval, prompt augmentation, or response generation.”transcript, stated

privacy-preserving-processing (governance)

The migration had to satisfy SOC2, legal, governance, and financial-compliance concerns.

“Obviously, you have to think through SOC-2 compliance, all of your legal compliance, governance type of concerns.”transcript, stated

safety-policy-enforcement (governance)

Bedrock Guardrails are used for content filtering, PII-leakage prevention, hallucination controls, and relevancy checks.

“So for financial compliance, there is no PII leakage and there is no inappropriate content which is given back to the user.”transcript, stated

Tradeoffs

Move from self-managed and multi-cloud pieces to managed Bedrock services.

Chose Amazon Bedrock managed services over managing GPU and RAG infrastructure independently across clouds.

Rationale: The migration reduced infrastructure ownership and cost while improving document sync speed.

“We are not managing anymore our own GPUs.”transcript, stated

Use semantic chunking for complex financial documents.

Chose LLM-assisted semantic chunking over fixed chunking and hierarchical parent chunks.

Rationale: Fixed chunks broke long financial documents at bad boundaries, and hierarchical parent chunks hit the Cohere embedding model's token limit; semantic chunking cost more but produced better results.

“So the third chunking strategy Octus tried was semantic, where you use a large language model to identify the natural breakpoints within your document.”transcript, stated
“But here the catch was there is a cost associated with it. But Octus was okay to absorb the cost because it gave really good results.”transcript, stated

Physically isolate each client's private knowledge base.

Chose separate knowledge bases per client over shared knowledge base partitioned only by client ID.

Rationale: Financial-services customers and auditors demanded stronger physical data boundaries for private client documents.

“it was a deliberate decision to keep client A data in a separate knowledge base and client B data in a separate knowledge base”transcript, stated
“because your customers demand and auditors require you to have physical boundaries between the data.”transcript, stated

Move guardrails into the Bedrock pipeline.

Chose Bedrock Guardrails built into the RAG path over third-party TrueLens calls for hallucination/relevancy checks.

Rationale: In-pipeline guardrails reduced external-call complexity, token usage, latency, and cost.

“Earlier, Octus was using a third-party application, TrueLens, to make the call. And that added latency and some more cost to their infrastructure.”transcript, stated
“since Guardrails is built within the pipeline, there is no need to make these external calls. The token usage is low, and the response and performance is better.”transcript, stated

Gotchas (what bit them)

Production GenAI migration adds requirements that prototypes can ignore.

Root cause: POCs can tolerate small user counts, loose latency, and weaker infrastructure quality; production cannot.

Resolution: Octus defined non-negotiables around sub-second latency, thousands of users, high availability, disaster recovery, accuracy, and compliance.

“In production, you're talking about thousands of concurrent users.”transcript, stated

Evaluation

The case reports operational results after migration, including cost and sync-time improvements.

Metrics: infrastructure cost · cost per question · document sync time · latency · accuracy

“So the cost went down by 78%.”transcript, stated

Outcomes

The source frames the system as production for sophisticated financial-services customers.

“and now we're able to sync documents in minutes just because we can scale those embeddings with Amazon Bedrock.”transcript, stated