Scaling Generative AI for Manufacturing Operations with RAG and Multi-Model Architecture

georgia-pacific · Other · 2024 · 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: manufacturing operations knowledge transfer

Georgia-Pacific needed to help operators troubleshoot unique factory machines as experienced knowledge lived in people's heads and the company operated many facilities and machines.

Constraints:

• The company has 140-plus facilities and hundreds of operators working at any time.
• Older machines often lack built-in intelligence and vary by setup, tier, and vendor.
• Operators already use many applications, so adoption required clear P&L value and guided workflows.

Architecture

Georgia-Pacific built an Operator Assistant using generative AI, RAG, vector databases, and AWS/Bedrock. They started with a production MVP, created Docgen to capture human machine knowledge into structured text, scaled chatbot use cases across machines and sites, and began deploying Bedrock-agent workflows for work-order automation.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  A["Machine alerts"] --> B["Operator Assistant"]
  B --> C["Operator users"]
  D["Human experts"] --> E["Docgen knowledge capture"]
  E --> F["RAG/vector knowledge base"]
  F --> B
  F --> G["Bedrock agent workflow"]
  H["Graph database"] --> G
  G --> I["Work order system"]

Components

Data flow

Human machine knowledge is captured through Docgen questionnaires as voice or text, transcribed into structured text, stored in suitable data structures/vector stores, and used by LLM/RAG solutions. Operators interact with a guided assistant that surfaces alerts and answers step-by-step troubleshooting questions. Newer agentic workflows use RAG, graph databases, and Bedrock agents to automate work-order planning tasks.

Why this architecture

The architecture starts with operator adoption and knowledge capture: undocumented machine expertise is converted into retrievable text, then served through guided RAG/chatbot interfaces and later agentic work-order automation.

Models used: AWS Bedrock models · Bedrock agents · RAG LLMs

Scale

• Georgia-Pacific has 140-plus facilities.
  “Like I said 140 plus facilities we have hundreds of operators working at any different any time”transcript, stated
• The MVP reached production in six to eight weeks.
  “we got it into production in about a month and a half, six weeks to eight weeks.”transcript, stated
• The system scaled to about 45 use cases/machines in seven to eight months.
  “in about uh 7 or 8 months we have deployed it at around 45 different use cases and machines”transcript, stated
• The deployment had more than 500 users on a given day and 30-40 concurrent users.
  “we have more than 500 users any given day probably 30 or 40 users at any given time”transcript, stated
• The rollout reached 45 sites in Q2.
  “we have already scaled to 45 sites um in Q2”transcript, stated

Alternatives considered (roads not taken)

Build a monolithic architecture

Rejected because: The speaker argues flexible plug-in/plug-out architecture matters for long-term scaling.

Launch a field-of-dreams assistant

Rejected because: Operators already had many tools, so the assistant needed to solve real problems and affect P&L.

Rely only on existing documentation

Rejected because: Critical machine knowledge was undocumented and held by experienced workers.

Patterns

rag-retrieval (retrieval)

The Operator Assistant uses RAG/vector knowledge over machine and operator knowledge to answer troubleshooting questions.

tool-use-orchestration (agent-architecture)

Bedrock agents and graph/RAG data are used to automate work-order planning tasks.

data-quality-loop (knowledge-management)

Docgen captures tacit operator knowledge into structured text so the assistant has usable source material.

Tradeoffs

Deployment strategy

Chose fast MVP in front of users over perfect CI/CD and architecture before launch.

Rationale: The team prioritized user feedback and speed, then improved foundations while scaling.

Knowledge ingestion

Chose interview-based Docgen capture over waiting for existing documentation.

Rationale: The most useful machine knowledge was undocumented and needed to be elicited from operators.

Gotchas (what bit them)

Factory knowledge was tacit, not documented.

Root cause: Experienced workers carried machine-specific troubleshooting knowledge in their heads.

Resolution: Build Docgen to interview experts and turn voice/text answers into structured documents for LLM use.

Operator adoption could fail if the assistant became yet another screen.

Root cause: Operators already had many applications and limited attention.

Resolution: Use guided alerts and questions tied to real operational problems and P&L impact.

Evaluation

Georgia-Pacific evaluates by adoption, user feedback, use-case/site scaling, daily/concurrent users, operational efficiency, production, waste, and future quality metrics.

Metrics: use cases deployed · sites deployed · daily users · concurrent users · efficiency · production · waste · product quality

Outcomes

• The assistant reached production in about six to eight weeks.
• The rollout scaled to around 45 use cases/machines and 45 sites.
• The system had more than 500 users on a given day and 30-40 concurrent users.
• Georgia-Pacific had begun deploying an agentic work-order automation workflow.

The transcript reports current rollout and direction, with some metrics still described qualitatively rather than as finalized business outcomes.