Building a Grounded AI Profile Assistant on AWS with Bedrock Knowledge Bases

Overview

An AI-powered professional profile assistant gives visitors a conversational interface over curated information such as experience, technical skills, projects and certifications. Instead of navigating a resume or several pages, a visitor can ask about AWS, Kubernetes, cloud security, DevOps, infrastructure automation or AI platform engineering.

The key requirement is that this must not behave like a general-purpose chatbot. Answers must be grounded in explicitly approved information. If the evidence is insufficient, the assistant should decline to make the claim rather than infer experience from related technologies.

This article covers the architecture, what has been implemented, the main design trade-offs and the roadmap. Deployment-specific identifiers, endpoints, keys and resource names are intentionally excluded.

Core design goals

• Ground responses in explicitly approved professional information.
• Avoid unsupported inference and hallucinated experience.
• Use serverless and managed AWS services so operations and cost stay proportional to the workload.
• Keep backend configuration and credentials out of browser code.
• Preserve a clean path toward stronger security, observability, evaluation and multi-source knowledge.

Current architecture

Public Website
   -> React AI chat widget
   -> POST /api/assistant
   -> Next.js Backend-for-Frontend (BFF)
   -> Amazon API Gateway (validation, throttling, usage controls)
   -> AWS Lambda
   -> Amazon Bedrock RetrieveAndGenerate
        -> Bedrock Knowledge Base -> vector retrieval -> Amazon S3 Vectors
        -> Foundation model

Approved resume in Amazon S3
   -> Titan Text Embeddings V2 -> Amazon S3 Vectors

The site is deployed with AWS Amplify. Presentation, application/API, AI/RAG and knowledge concerns are separated so each layer can evolve independently.

1. Knowledge layer

The authoritative source is intentionally small: an approved professional resume stored in Amazon S3. Amazon Bedrock Knowledge Bases manages ingestion and converts the content into representations suitable for semantic retrieval.

• Amazon S3 stores the approved source document.
• Bedrock Knowledge Bases manages the RAG knowledge layer, including parsing and chunking.
• Amazon Titan Text Embeddings V2 creates the vector representations.
• Amazon S3 Vectors provides lightweight vector storage.

For this workload, a lightweight managed vector setup is preferable to operating a larger search or vector database. The goal is infrastructure proportional to the workload, not maximum complexity.

2. Retrieval-augmented generation

The platform uses Bedrock's RetrieveAndGenerate capability. At runtime the question is used to retrieve semantically relevant profile content, which is supplied to the foundation model as generation context.

User question -> semantic retrieval -> relevant profile chunks
  -> grounded generation prompt -> foundation model -> grounded response

The model is not expected to answer profile questions from pretrained knowledge. Retrieved evidence is the factual basis for generation.

3. Grounding strategy

RAG does not automatically guarantee grounding. A model can retrieve relevant content and still make plausible but unsupported inferences. For a professional profile that is unacceptable: experience with one technology must not imply experience with another related one.

Grounding rule: factual claims must be supported by retrieved evidence. When evidence is insufficient, the assistant should say so rather than speculate.

• Make factual claims only from retrieved evidence.
• Avoid speculation and related-technology inference.
• Do not present assumptions as professional experience.
• Return an insufficient-information response when evidence is unavailable.
• Do not expose internal retrieval or knowledge-base terminology to visitors.

Unsupported-question testing is therefore a first-class validation technique. Verifying that the assistant refuses an unsupported claim matters as much as verifying that it answers a supported question correctly.

4. Application and API layers

AWS Lambda sits between API Gateway and Bedrock. It validates the incoming question, invokes the RAG workflow, validates downstream behavior and maps service failures into controlled API responses.

• Questions must exist, be strings, be non-empty and stay within a bounded length.
• AWS service failures are handled separately from unexpected application failures.
• User questions are not unnecessarily written to application logs.

API Gateway adds another trust boundary with request-schema validation, throttling and usage controls. Validation exists at the browser, Next.js, API Gateway and Lambda layers because client-side validation is mainly a UX feature, while server-side validation establishes trust boundaries.

5. Backend-for-frontend pattern

The browser never calls the AWS API directly. It calls a same-origin Next.js endpoint, and the server-side route invokes API Gateway.

Browser -> POST /api/assistant -> Next.js BFF
  -> (server-to-server) API Gateway -> Lambda -> Bedrock

The BFF keeps backend configuration out of client-side JavaScript, adds a validation boundary, normalizes backend errors and decouples the frontend from the AWS API topology.

Important: a BFF is not authentication or abuse prevention by itself. The public endpoint remains callable and needs additional controls for a hardened production deployment.

6. Frontend and error handling

The interface is a React component in a Next.js application. It supports message rendering, Markdown-formatted responses, loading state, bounded input, keyboard submission, multiline input, automatic scrolling, focus restoration and friendly error handling.

Error semantics are preserved across service boundaries, so throttling stays distinguishable from temporary unavailability or a generic upstream failure:

400 -> Invalid request
429 -> Request throttled
502 -> Invalid/upstream failure
503 -> Service temporarily unavailable
500 -> Unexpected application failure

7. Deployment architecture

The Next.js application is deployed with AWS Amplify. Configuration needed by server-side routes is supplied to the server-side environment rather than exposed through browser-visible variables.

Source repository -> Amplify build -> Next.js production build
  -> Amplify Hosting / server runtime -> public website

A practical lesson: build-time and server-runtime configuration are not always equivalent. Deployment configuration should be treated as part of the architecture rather than assuming a locally working setup behaves identically in production.

Architectural alternatives and trade-offs

A central decision is how much of the RAG pipeline Bedrock manages versus how much application code controls.

1. Bedrock RetrieveAndGenerate (current): Bedrock manages most retrieval and generation orchestration. This keeps application code small and fits a straightforward RAG workload over a small authoritative source. The trade-off is less control over context construction, reranking and model routing.
2. Knowledge Base Retrieve + Converse: The application retrieves chunks, then handles filtering, reranking, context selection, prompt construction and token budgeting before calling the Converse API. This gives high control and observability, at the cost of more logic to build, test, secure and operate.
3. Custom retrieval + Converse: Retrieval itself moves into the platform layer, enabling multiple indexes, hybrid search, custom embeddings, authorization-aware or tenant-aware retrieval and model routing. It offers maximum flexibility with the highest complexity, which is unnecessary for a small profile assistant.

Capability	RetrieveAndGenerate	Retrieve + Converse	Custom + Converse
Managed retrieval	Yes	Yes	Optional
Managed RAG orchestration	High	Partial	Low
Context control	Moderate	High	Full
Custom reranking	Limited	High	Full
Model routing	Limited	High	Full
Multi-source orchestration	Moderate	High	Full
Application complexity	Low	Medium	High
Operational responsibility	Low	Medium	High
Current platform fit	Strong	Future option	Currently excessive

The design uses the highest-level abstraction that satisfies the current requirements while keeping a path to more orchestration. More control is not automatically better if the workload does not justify the extra complexity.

Why not use Converse alone?

The Converse API provides a standard interface to supported foundation models, but it does not make private professional information available to the model. A grounding instruction tells the model how to use evidence; it does not retrieve that evidence. A Converse-based RAG design still needs retrieval, grounding instructions and generation. The common lower-level pattern is Knowledge Base Retrieve, application-controlled context construction, then a Converse call. RetrieveAndGenerate simply lets Bedrock manage more of that orchestration.

Cost-conscious design

Because volume is low, cost is an architectural constraint. The platform favors serverless compute, managed RAG, managed embeddings, lightweight vector storage and usage controls over permanently running application or search infrastructure. The aim is not simply minimizing cost, but avoiding infrastructure whose cost and operational overhead the workload does not justify.

Current security model

This is a baseline security posture, not a claim of a final security architecture.

• Backend invocation happens server-side rather than from browser code.
• Backend API credentials are not embedded in browser JavaScript.
• Input is validated at multiple boundaries and bounded in length.
• API Gateway applies throttling and usage controls.
• Application errors are controlled, and user questions are not unnecessarily logged.
• Strict grounding instructions reduce unsupported factual claims.
• The public frontend is separated from the AWS backend through a BFF.

An API key is a consumption-control mechanism, not user authentication. Likewise, putting backend configuration behind the BFF prevents direct browser exposure but does not make the public BFF abuse-proof.

Future knowledge architecture

The approved knowledge domain can expand beyond the resume while keeping a controlled trust model. Candidate sources include technical projects, technical articles, professional credentials, Stack Overflow contributions and selected website content.

External sources should be ingested and normalized rather than giving the model arbitrary internet access on every question. That separates knowledge acquisition from question answering and keeps source provenance controllable.

External professional source
  -> scheduled / controlled ingestion
  -> fetch -> normalize -> metadata enrichment
  -> Amazon S3 -> Knowledge Base sync -> vector index

Metadata such as source, content type, topic, technology, issuer and date can support source-aware retrieval and filtering as the corpus grows.

Roadmap

1. Current foundation: controlled knowledge source, Bedrock Knowledge Base, managed RAG with grounding rules, Lambda and API Gateway, validation and throttling, Next.js BFF, React interface and Amplify deployment.
2. Production hardening: stronger abuse protection and rate control, improved secret and configuration management, observability and alerting, prompt-injection testing, Bedrock Guardrails evaluation, privacy and logging review, and reliability improvements.
3. AI evaluation: a repeatable dataset of supported, unsupported, ambiguous and adversarial questions so prompt, retrieval and model changes can be measured instead of inspected manually.
4. Multi-source knowledge: expand the controlled corpus with normalization and metadata-aware ingestion.
5. Advanced RAG orchestration: move to Retrieve, filter/rerank, authorization, context construction and Converse only when requirements such as reranking, source-aware retrieval, authorization filtering or detailed retrieval observability justify the added complexity.

Conclusion

This platform is a small but complete AI application architecture: controlled knowledge, semantic retrieval, grounded generation, serverless application logic, API controls, server-side web integration and a public conversational experience. It favors managed services and a controlled knowledge domain, and the next stage is strengthening security, observability, evaluation and governance.

Architectural principle: use the simplest abstraction that satisfies the current requirements, preserve clear trust boundaries, and evolve toward greater control only when the workload demands it.