Healthcare Search Discovery Using ML and Generative AI on E-commerce Platform

amazon_health_services · Healthcare · 2025 · source Agentic: no · promotional bias: med · source-backed · extracted with prompt 0.5.6 (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: healthcare ecommerce search and discovery

Amazon Health Services needed Amazon.com search to understand healthcare intent and surface relevant healthcare products and services, even when customers searched with symptoms, conditions, treatments, or lay terminology rather than exact product names.

Constraints:

• traditional product search was not designed for relationships among symptoms, conditions, treatments, services, and medications
• queries range from exact medication searches to broad upper-funnel health questions
• existing product algorithms can miss service offerings such as primary care or virtual physical therapy
• health ontology terminology must map lay queries to medical concepts and product/service metadata
• the system must avoid relying on individual customer data
• large-scale product knowledge, embeddings, retrieval, and labeling jobs need to run economically
• relevance quality must be checked with both human labels and LLM labels

Architecture

Amazon Health Services built a three-part search discovery system on AWS. A query-understanding pipeline uses Amazon search engagement data, PySpark on EMR, Athena, SageMaker, and trained ML models to detect health-related searches, distinguishing lower-funnel prescription-medication searches from broader health condition searches. A product knowledge base combines Amazon catalog metadata with LLM-augmented health conditions, symptoms, and treatment keywords generated through Amazon Bedrock batch inference; the knowledge base is embedded and indexed with FAISS for semantic retrieval. A relevance optimization layer retrieves and reranks candidate healthcare offerings, then applies ESCI relevance labels through a combination of human labeling and LLM-based batch classification to connect health search keywords with products and services such as Amazon Pharmacy, One Medical, and Health Benefits Connector.

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

flowchart LR
  A["Amazon search query"] --> B["Query understanding pipeline"]
  B --> C["Pharmacy classifier"]
  B --> D["Health NER model"]
  E["Amazon search engagement data"] --> C
  F["Health ontology sources"] --> D
  F --> G["Bedrock term expansion"]
  G --> D
  G --> H["Product knowledge base builder"]
  H --> I["FAISS similarity index"]
  I --> J["Retrieval and reranking pipeline"]
  J --> K["ESCI relevance labeling"]
  K --> L["Human labeling team"]
  K --> M["LLM ESCI labeling"]
  M --> N["Amazon S3 storage"]
  H --> N
  J --> O["Healthcare search experience"]
  B --> O

Components

Data flow

An Amazon health search first flows through query-understanding models. Specific lower-funnel medication queries are identified by a pharmacy classifier trained from anonymized search engagement data, while broad health queries are annotated by an NER model trained from health ontologies and LLM-expanded alternate terms. Separately, healthcare product and service metadata is enriched with Bedrock-generated health keywords, embedded, and indexed with FAISS. At search time, a query embedding retrieves candidate products or services from the FAISS index. Candidate query-product pairs are reranked and labeled using the ESCI framework with both human labeling and Bedrock batch inference, producing relevant healthcare offerings and discovery pathways in the Amazon search experience.

Why this architecture

AHS combined classifiers, NER, LLM augmentation, vector retrieval, and ESCI relevance labeling because healthcare search has both exact medication intent and ambiguous symptom/condition intent. The system needed ontology-aware query understanding, semantically enriched product knowledge, and validated relevance matching, not only traditional ecommerce keyword matching. AWS batch and ML services let the team scale ontology expansion, embeddings, and LLM labeling without relying on manual work for every query-product pair.

Models used: pharmacy classifier · health NER model · large language model · Amazon Bedrock models · FAISS embeddings · bi-encoder · cross-encoder

Scale

• The solution is used daily for health-related search queries.
  “This solution is now used daily for health-related search queries, helping customers find everything from prescription medications to primary care services.”article, stated
• The Pharmacy classifier training used Amazon search data processed at scale with EMR and Athena.
  “This process used PySpark on Amazon EMR and Athena to collect and process Amazon search data at scale.”article, stated
• Large-scale product knowledge embedding jobs were run as scheduled SageMaker Notebook Jobs.
  “Through the combination of these technologies, we built a robust foundation of healthcare product knowledge that could be efficiently searched and matched to customer queries.”article, stated
• LLM relevance labeling ran at scale across top health searches.
  “we conducted large-scale inference across the top health searches, connecting them to the most relevant offerings using similarity search.”article, stated
• One Medical Pay Per Visit covers treatment for more than 30 common conditions.
  “Pay-per-visit is a one-time virtual visit option to find treatment for more than 30 common conditions like acne, pink eye, and sinus infections.”article, stated

Alternatives considered (roads not taken)

Use traditional product search algorithms unchanged

Rejected because: Traditional ecommerce search was not designed to map symptoms, conditions, treatments, and healthcare services to each other.

Use only exact medication/product intent

Rejected because: The search experience needed to serve both spearfishing medication queries and broad upper-funnel condition queries such as back pain, acne, or high blood pressure.

Depend only on existing ontology terms

Rejected because: For health concepts without enough alternate terms, the team used LLMs to expand the knowledge base with lay and medically relevant variants.

Use only human labeling for relevance

Rejected because: Human labels established reliable ground truth, but Bedrock batch jobs scaled labeling across top health searches and product matches.

Use customer-level personal data for matching

Rejected because: The implementation guidance says the approach does not use individual customer data, relying instead on aggregated search keywords, product metadata, ontology data, and labels.

Patterns

rag-retrieval (retrieval)

AHS implemented RAG-style semantic matching by embedding customer health queries, searching a FAISS index built from LLM-enhanced product knowledge, and retrieving candidate healthcare offerings for reranking and labeling.

fine-tuning-adaptation (model adaptation)

The team trained a pharmacy classifier from Amazon search engagement data and fine-tuned a health NER model from ontology and LLM-expanded health concepts.

human-in-the-loop-gate (evaluation)

Human labelers created a substantial ground-truth benchmark using ESCI guidance tailored to AHS products and services before LLM labeling was used at scale.

eval-driven-development (evaluation)

Relevance quality was evaluated through ESCI exact/substitute/complement/irrelevant labels, human benchmarks, LLM batch classification, and high-confidence labels used as ground truth.

structured-output-contract (data contract)

The system used the ESCI framework as a structured relevance contract and maintained mappings from embeddings back to original knowledge base items for accurate reverse lookups.

privacy-preserving-processing (privacy)

The search discovery system connected aggregated health search keywords and product metadata without relying on individual customer data.

cost-aware-routing (operations)

The implementation guidance routes batch processing to cost-efficient infrastructure such as EMR on EC2 Spot Instances and uses caching for frequently searched queries.

Tradeoffs

Combine classifier and NER approaches for query understanding

Chose separate models for spearfishing prescription intent and broad health concept detection over one generic health-search classifier.

Rationale: Exact medication searches and ambiguous symptom/condition searches sit at opposite ends of the search-intent spectrum and require different handling.

Use Bedrock LLMs to augment knowledge and labels

Chose LLM expansion and batch labeling with few-shot prompts over manual ontology/product curation and labeling only.

Rationale: LLMs expanded health terminology and relevance labels at a scale that would otherwise require far more manual budget.

Use FAISS embeddings for healthcare product matching

Chose semantic vector search over enriched product knowledge over keyword-only product matching.

Rationale: Healthcare search requires semantic connections between lay health queries and relevant products or services, which embeddings can capture better than exact keyword matching alone.

Use both human and LLM relevance labels

Chose hybrid ESCI labeling with human ground truth and LLM batch classification over all-human labels or all-LLM labels.

Rationale: Human labels provide trustworthy benchmark data, while LLM batch jobs scale relevance labeling across large health-search candidate sets.

Avoid individual customer data

Chose aggregated search keywords, product metadata, ontology terms, and labels over personalized health matching based on individual customer data.

Rationale: The healthcare search implementation guidance explicitly emphasizes privacy and compliance by not using individual customer data.

Gotchas (what bit them)

Healthcare service offerings do not behave like ordinary ecommerce products.

Root cause: A query such as back pain treatment may imply medications, doctor appointments, virtual physical therapy, or other services that traditional product search does not surface.

Resolution: AHS built specialized query understanding and matching to connect health intent with service-based offerings as well as physical or pharmacy products.

Broad health queries are ambiguous until the system understands intent.

Root cause: Queries such as high blood pressure may refer to medical care, prescription medication, monitors, books, or other informational and product categories.

Resolution: The NER and query-understanding system detects broad health concepts and triggers experiences that help customers refine or disambiguate intent.

Ontology coverage can be too sparse for customer language.

Root cause: Health concepts may lack enough alternate lay terms, synonyms, misspellings, or treatment-related keywords in the existing knowledge base.

Resolution: AHS used LLMs through Bedrock to expand alternate terms and enrich product knowledge before embedding and search.

Semantic retrieval needs reverse lookups to avoid losing product identity.

Root cause: Embeddings support similarity search, but the system still needs to map each vector result back to the original product or service knowledge item.

Resolution: The team maintained careful mappings from embeddings to original knowledge base items.

Manual relevance labeling alone would not scale economically.

Root cause: Large-scale health search-product matching requires labeling many query-product pairs across top health searches.

Resolution: Use human labels for reliable benchmark creation and Bedrock batch inference for large-scale ESCI labeling.

Evaluation

AHS evaluated relevance through a two-pronged ESCI labeling process: human labelers created ground truth on a substantial sample with AHS-tailored guidance, and Bedrock batch jobs labeled top retrieved healthcare product matches with few-shot ESCI examples. The system also used high-confidence human and LLM labels to establish ground truth, thresholded FAISS similarity search, and ongoing model-performance monitoring/retraining recommendations.

Metrics: ESCI labels: exact, substitute, complement, irrelevant · human ground-truth sample for system performance · LLM-based batch labeling of top health-search product matches · FAISS similarity-score thresholding · model performance monitoring and retraining as needed

Outcomes

• The solution is now used daily for health-related search queries on Amazon.
• Customers searching for acute or chronic conditions can see medically vetted relevant offerings alongside products and services on Amazon.com.
• The system created additional discovery pathways for healthcare services such as doctors, prescription medications, and partner programs.
• AHS reports semantic connections between customer queries and healthcare solutions without using individual customer data.

The production system uses AWS services for daily health-related Amazon searches, processing search data at scale with EMR and Athena, scheduled SageMaker jobs for knowledge-base embeddings, Bedrock batch inference for large-scale LLM labeling, and FAISS vector search for healthcare product/service matching.