Self-Learning Generative AI System for Product Catalog Enrichment

amazon · E-commerce · 2026 · source Agentic: yes · 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: product catalog enrichment

Amazon Catalog needed to enrich millions of daily product submissions with accurate structured attributes and searchable content while reducing manual scientist intervention, cost, and error rates.

Constraints:

• The catalog processes millions of products and encounters edge cases, evolving terminology, and domain-specific ambiguity.
• Large models provide accuracy but do not scale efficiently to catalog volume.
• Smaller models are cheaper but struggle on ambiguous cases where sellers need help most.
• The system must learn from worker disagreements, seller feedback, customer returns, negative reviews, and expert input without retraining every time.

Architecture

Amazon built a self-learning multi-model architecture: lightweight generator/evaluator workers process routine product attributes through consensus; disagreements route to a more capable supervisor agent in Bedrock AgentCore with specialized tools and access to catalog systems; the supervisor resolves disputes, extracts reusable learnings, and stores them in a hierarchical DynamoDB-backed knowledge base; a memory manager injects relevant learnings back into worker prompts, while SQS human review and CloudWatch observability support production operations.

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

flowchart LR
  A["Product data submissions"] --> B["Generator-evaluator workers"]
  C["Amazon Bedrock Runtime and EC2"] --> B
  B --> D["Supervisor agent"]
  D --> E["Catalog investigation tools"]
  E --> F["Seller and customer feedback signals"]
  D --> G["Learning aggregator"]
  F --> G
  G --> H["Knowledge base and memory manager"]
  H --> B
  D --> I["Human review queue"]
  I --> K["Domain experts"]
  K --> H
  J["CloudWatch observability"] --> D
  J --> H

Components

Data flow

Product data enters generator-evaluator workers on EC2/Bedrock Runtime; agreed outputs are stored directly; disagreements and post-inference seller/customer feedback route to the supervisor agent; the supervisor investigates with specialized tools and catalog/customer signals; reusable learnings flow through an aggregator and memory manager into a hierarchical knowledge base; future worker prompts receive category-relevant learnings so similar cases need fewer supervisor calls.

Why this architecture

Amazon used asymmetric workers and a supervisor because most catalog cases can be handled cheaply by consensus, while disagreements identify high-learning-value cases where a stronger model and richer context are worth the cost. The resulting knowledge base lets future worker prompts benefit from past investigations without retraining.

Models used: Amazon Nova Lite · Anthropic Claude Sonnet · LLM-based memory manager · smaller worker models · supervisor model

Scale

• The catalog processes millions of daily submissions.
  “This complexity, multiplied by millions of daily submissions, makes catalog enrichment an ideal proving ground for self-learning AI.”article, stated
• A single learning can improve future extraction across thousands of products.
  “A single well-crafted learning can immediately improve accuracy across thousands of products.”article, stated
• The knowledge base remains relatively fixed in size even as inference volume scales.
  “the knowledge base itself, which remains relatively fixed in size regardless of inference volume.”article, stated

Alternatives considered (roads not taken)

Use large models for all products

Rejected because: Large models could improve accuracy but would not scale efficiently to Amazon catalog volume.

Use only smaller worker models

Rejected because: Smaller models struggled with ambiguous cases and needed supervisor help when disagreements surfaced.

Treat worker disagreements as ordinary errors

Rejected because: Amazon found disagreements were often indicators of complexity and learning opportunities.

Manually review millions of outputs

Rejected because: Auditing the knowledge base is more scalable than reviewing outputs one by one.

Patterns

multi-agent-orchestration (agent-architecture)

Generator/evaluator workers handle routine extractions and a supervisor agent investigates disagreements with richer context and tools.

eval-driven-development (learning-signal)

The system uses worker disagreement, seller feedback, returns, and negative reviews as evaluation signals that drive learning.

agent-memory (learning)

Reusable learnings are stored in a hierarchical knowledge base and injected into future worker prompts.

human-in-the-loop-gate (quality-control)

Human review and domain experts audit or refine the knowledge base instead of reviewing every product output.

Tradeoffs

Use smaller workers plus a stronger supervisor.

Chose cheap consensus path with selective supervisor escalation over one large model for every product.

Rationale: Routine cases stay inexpensive while ambiguous cases get deeper investigation and learning extraction.

Audit the knowledge base.

Chose knowledge-base review and expert edits over sampling millions of outputs.

Rationale: The knowledge base stays relatively fixed and traceable while inference volume scales.

Learn-then-deploy or deploy-and-learn based on use case maturity.

Chose two operating modes for new versus understood domains over one learning rollout strategy.

Rationale: New use cases need pre-production learning and approval; understood use cases can improve continuously in production.

Gotchas (what bit them)

Manual improvement could not keep pace with catalog variety.

Root cause: Scientists analyzing failures, updating prompts, testing, and redeploying is resource-intensive at millions-of-products scale.

Resolution: Let disagreements invoke supervisor investigations that generate reusable learnings automatically.

Too-low or too-high disagreement rates are both unproductive.

Root cause: Too-low rates may mean noise or model limitations; too-high rates imply immature workers/prompts and excessive supervisor calls.

Resolution: Identify a task-specific sweet spot where disagreement indicates learnable complexity.

Supervisor investigations must become reusable knowledge, not just one-off corrections.

Root cause: Millions of product-level cases make individual fixes unscalable.

Resolution: Aggregate and place learnings in a hierarchical knowledge tree that workers retrieve by category.

Evaluation

Amazon evaluates through worker disagreement rates, supervisor-call rates, seller updates/appeals, returns, negative reviews, knowledge-base traceability, observability, and domain-expert audits.

Metrics: worker disagreement rate · supervisor calls · seller updates and appeals · returns and negative reviews · knowledge-base traceability · learning impact

Outcomes

• Error rates fell continuously through accumulated learnings rather than retraining.
• Supervisor calls naturally decline as accumulated learnings prevent repeated classes of disagreements.
• The system learned industry-specific terminology, contextual category rules, and requirements no pretrained model would encounter.

The design targets millions of daily product submissions, using cheap worker consensus for routine cases and selective supervisor calls for high-learning-value cases.