AI-Powered Audience Simulation Engine for Market Research
Gen AI Use Cases
AI-Powered Audience Simulation Engine for Market Research
Honda Cars India Ltd is the Indian passenger-vehicle arm of Honda Motor Company, manufacturing and selling across a market that is among the most competitive and fastest-moving in the world. Product and marketing decisions are made against a buyer base that spans metropolitan and tier-two cities, first-time and repeat purchasers, and sharply different priorities around price, running cost, family use, and brand. Understanding that base is the job of the market research function, which supports campaign development, product positioning, and messaging decisions for every launch and refresh across the portfolio.
Case Overview
Project Snapshot
Honda Cars India Ltd is the Indian passenger-vehicle arm of Honda Motor Company, manufacturing and selling across a market that is among the most competitive and fastest-moving in the world. Product and marketing decisions are made against a buyer base that spans metropolitan and tier-two cities, first-time and repeat purchasers, and sharply different priorities around price, running cost, family use, and brand.
Understanding that base is the job of the market research function, which supports campaign development, product positioning, and messaging decisions for every launch and refresh across the portfolio.
Understanding the Business Challenges
Every successful solution starts with understanding the problems, constraints and opportunities that shaped the project.
Honda's audience research depended on manual work: commissioning studies, running focus groups, and assembling findings by hand. A single research cycle took six to eight weeks. That length imposed a hard limit on how often a strategy could be tested, and it meant campaign decisions were routinely made against research that had aged.
The knock-on effects compounded. Because each cycle was expensive, teams asked fewer questions and tested fewer variants. Because findings sat in documents rather than systems, the accumulated understanding of the buyer base lived in the memory of the people who had run the studies. And because agencies were commissioned per cycle, the cost scaled linearly with the number of questions asked.
2.1 Where the Constraint Bit
- Six to eight weeks from question to insight, against campaign cycles measured in weeks.
- Research cost scaling with every additional question, discouraging exploration.
- Findings held in documents and individual recall rather than a queryable system.
- No practical way to test a message against several audience segments in parallel.
- Prior research effectively unreusable once the study that produced it had closed.
Facing Similar Business Challenges?
Our experts can help you plan, build and deliver the right technology solution for your business.
What We Set Out To Achieve
The project was shaped around clear business goals, measurable outcomes and a practical path toward long-term growth.
Agreed with the client before development began, each expressed so that it could be measured rather than asserted.
| Objective | Definition of success |
| Compress time-to-insight | From 6–8 weeks to interactive, sub-5-minute questioning |
| Make prior research reusable | Turn accumulated evidence into a queryable knowledge base |
| Support parallel comparison | Test a message against multiple segments simultaneously |
| Keep every answer checkable | Ground responses in retrievable evidence with attribution |
| Maintain compliance posture | Operate entirely on public data with no personal data stored |
| Scale without headcount | Serve the whole marketing function from one interface |
A Practical Solution Built For Long-Term Success
We transformed the identified challenges into a practical, scalable and sustainable technology solution designed around real business needs.
Capspedia designed and delivered an AI-Powered Audience Simulation Engine on AWS. The platform ingests public web and social data, derives 20 distinct audience profiles through unsupervised clustering with human validation, and builds a dedicated knowledge base for each. Honda's teams then interrogate those profiles conversationally.
The design principle throughout is that the system retrieves and reasons rather than invents. Every response is grounded in retrieved evidence and carries attribution back to the underlying records, so a strategist can inspect the basis of an answer instead of taking it on faith. Where the retrieved evidence does not support an answer, the system says so rather than filling the gap.
How The Solution Was Structured
The solution was broken into focused components, allowing each part of the platform to work together while remaining scalable and maintainable.
| Component | Function |
| Data acquisition | Ingestion of 1 to 3 million public web and social records with full source metadata retained for attribution |
| Preparation pipeline | Normalisation, two-stage deduplication (exact then semantic), language filtering, and quality gating before any ML stage |
| Profile construction | Embedding, unsupervised clustering, and LLM-assisted labelling, with every profile validated by Honda subject matter experts |
| Knowledge bases | 20 profile-specific vector collections holding curated evidence with retrieval metadata |
| Intelligence engine | Retrieval-augmented generation with style injection, so each profile answers in its own register while staying grounded |
| Retrieval validation | A relevance-scoring stage that filters low-confidence passages before they reach the model context |
| Conversation layer | Multi-turn orchestration with context retention and side-by-side profile comparison |
| Web interface | React application: profile selector, chat, comparison views, analytics, and an admin panel |
The System Design Behind The Delivery
A thoughtfully structured architecture connects the application, data, infrastructure and services into a reliable and scalable technology foundation.
The runtime request flow, end to end. Each step is a discrete, independently monitored component per the component standard in CAPS-AI-DTC-001.
- A user question enters through Amazon API Gateway and is authenticated before it reaches any compute.
- An AWS Lambda orchestrator resolves the selected profile or profiles and their permitted evidence scope.
- The question is embedded with Amazon Titan Embeddings for semantic search.
- Amazon OpenSearch Serverless returns candidate evidence from the relevant profile collection, pre-filtered on metadata.
- The retrieval validation stage scores relevance and discards low-confidence passages.
- Amazon Bedrock generates the response with profile style injection, constrained to the retrieved evidence.
- Citations are verified against the retrieved passages before the response is returned.
- Amazon DynamoDB records the interaction for the audit trail; Amazon CloudWatch captures quality and operational telemetry.
The architecture is serverless throughout and defined entirely as code. Every service is reached through private connectivity under least-privilege access, and no data-layer resource is routable from the internet.
Model Selection And Core Approach
The foundation model was selected based on the project's requirements, performance expectations, reliability and ability to support the overall solution architecture.
Model selection followed Capspedia's standard procedure (CAPS-AI-FMS-001): hard constraints applied as a screen first, then weighted scoring of the surviving candidates against criteria fixed before benchmarking began. Candidates were evaluated on identical inputs using a curated evaluation set built from the client's own material.
| Criterion | How it was assessed |
| Output quality | Evaluated against a curated set drawn from real Honda research questions, with human adjudication on relevance and register |
| Instruction adherence | Rate at which the model held the profile voice and respected the refusal rule under adversarial queries |
| Context window | Tested against realistic payloads: retrieved evidence plus conversation history across multi-turn sessions |
| Latency | P50, P95 and P99 measured under representative concurrency, not vendor published figures |
| Unit cost | Modelled per thousand requests at forecast volume including retrieval context overhead |
| Regional availability | Screened first as a hard constraint against the required deployment region |
7.1 Selection Outcome
A mid-tier Claude model on Amazon Bedrock was selected for the generation and reasoning component, with a smaller fast model handling intent classification and guardrail checks. Amazon Titan Embeddings was selected for vectorisation after benchmarking on Honda's own corpus. The decision, the alternatives tested, and the trade-offs accepted are recorded in the engagement's Model Selection Record.
What We Learned Along The Way
Every complex project brings valuable insights. The challenges encountered during delivery helped refine the approach, strengthen the solution and shape better decisions.
Recorded because the resolutions generalise. Each has been carried into Capspedia's practice pattern library and informs how the next comparable engagement is scoped.
Public source data is noisier than it looks
Web and social records carried substantial spam, duplication, and near-duplicate content, and the first clustering pass produced profiles that overlapped enough to be indistinguishable to Honda's reviewers. Two-stage deduplication, exact matching followed by semantic near-duplicate detection, plus automated quality gating ahead of the ML stage, resolved it. The lesson we carry forward is to budget preparation effort against the messiest plausible corpus, not the sample supplied for evaluation.
Voice consistency needs a dedicated cycle, not incidental tuning
Holding a profile's register stable across the full range of questions users actually asked took materially more iteration than the plan allowed. We ran a dedicated refinement sprint with Honda subject matter experts, working through edge cases and deliberately awkward queries. Coherence passed 90% on the evaluation set and finished at 92%. We now schedule a refinement cycle explicitly wherever output register is part of the acceptance criteria.
Retrieval configuration is where answer quality is won
The initial thresholds were permissive, returning passages that were semantically close but contextually irrelevant, which weakened attribution and made some answers hard to defend. Adding a relevance-scoring validation stage before the model context lifted measured relevance to 88%. This reinforced a principle now standard in our practice: evaluate retrieval separately from generation, because most weak answers are retrieval failures wearing a generation costume.
Built To Grow With The Business
The solution was designed to remain reliable under changing workloads while providing the flexibility required for future business growth.
| Layer | Design position |
| Compute | Serverless Lambda across multiple availability zones; no single instance to lose and no capacity to pre-provision |
| Retrieval | OpenSearch Serverless scaling automatically with query volume and collection size |
| Model access | Managed Bedrock endpoints with client-side retry, exponential backoff, and a defined fallback path on unavailability |
| State | DynamoDB with on-demand capacity for conversation history and audit records |
| Storage | S3 with versioning, enabling any prior corpus state to be restored |
| Delivery | API Gateway throttling per caller, protecting shared capacity from a single client or credential |
| Recovery | Corpus and index rebuildable from versioned source data; recovery procedure exercised before go-live |
| Degradation | Defined ladder: reduce retrieval breadth, fall back to a smaller model, then refuse explicitly rather than degrade silently |
The architecture carries no fixed capacity assumption. Profile count, corpus size, and concurrent users each scale independently: adding a profile is an additional vector collection rather than an architectural change, and the monthly refresh runs as a batch workload that does not compete with interactive traffic.
Measurable Business Outcomes
The completed solution delivered tangible improvements, turning the original objectives into meaningful business value and measurable outcomes.