Scaling Knowledge Management with LLM-powered Chatbot in Manufacturing

osram · Tech · 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: manufacturing knowledge management

OSRAM needed to preserve and retrieve shop-floor manufacturing knowledge as experienced workers retired and documentation remained scattered across old tools and file formats.

Constraints:

• The plant was a brownfield facility built in 1961 with long historical tool and file-format complexity.
• Operators, maintenance workers, engineers, and scientists had different knowledge needs and backgrounds.
• The solution needed to work for shop-floor users and be deployable beyond one department or plant.

Architecture

OSRAM, Adastra, and AWS built a Bedrock/Claude RAG chatbot over plant documentation. The pipeline ingests documents into S3, preprocesses them, stores retrievable data in OpenSearch, combines vector/RAG retrieval with keyword search for technical terms, serves answers through a simple UI, collects feedback, and uses CI/CD and infrastructure-as-code so the solution can scale to other departments and plants.

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

flowchart LR
  A["Plant knowledge sources"] --> B["S3 landing bucket"]
  B --> C["Preprocessing and ingestion"]
  C --> D["OpenSearch vector and keyword store"]
  D --> E["Amazon Bedrock Claude"]
  E --> F["Streamlit chatbot UI"]
  F --> G["Shop-floor users"]
  G --> A
  F --> H["Feedback loop"]
  H --> I["CI/CD and Terraform pipeline"]

Components

Data flow

Plant documents and legacy knowledge sources are collected in S3, preprocessed and ingested, stored in OpenSearch/vector structures with keyword support, retrieved for Amazon Bedrock/Claude, returned to a Streamlit user interface, and improved through user feedback and CI/CD-driven deployments.

Why this architecture

OSRAM chose RAG plus hybrid search because plant knowledge was scattered, technical terminology needed lexical matching, and the project needed a scalable production deployment path rather than a demo.

Models used: Amazon Bedrock · Claude · Amazon Nova models (future option)

Scale

• The OSRAM plant dates back to 1961.
  “The plant was built 1961. So quite an old plant and therefore we have big challenges.”transcript, stated
• The deployed solution reported over 85% accuracy with a target above 90%.
  “last week, we could deploy a new solution with an accuracy of over 85%. We expect in the coming weeks to get this to way above 90%.”transcript, stated
• The team designed the pipeline to scale to other departments and plants.
  “it can be easily deployed to for other departments in the future also for other plants”transcript, stated

Alternatives considered (roads not taken)

Vector-only retrieval

Rejected because: Technical terms in manufacturing documentation made keyword search useful alongside vector retrieval.

Proof-of-concept chatbot without production foundations

Rejected because: The team wanted value quickly and a path to scale, so it built CI/CD and infrastructure-as-code.

Keep knowledge access through many existing tools

Rejected because: Retrieving information took too much time and shop-floor workers needed a simple interface.

Patterns

rag-retrieval (retrieval)

The chatbot retrieves plant documentation from a vector store and passes it to Bedrock/Claude for answer generation.

hybrid-search (retrieval)

OSRAM combines vector/RAG retrieval with keyword search because manufacturing documentation contains specialized terms.

data-quality-loop (knowledge-management)

User feedback is fed back into the solution so the chatbot improves after deployment.

Tradeoffs

Retrieval design

Chose hybrid vector and keyword search over only using vector database retrieval.

Rationale: Technical terms in plant documentation made lexical matching necessary even with a vector database.

Deployment foundation

Chose CI/CD and infrastructure-as-code from the beginning over one-off proof of concept.

Rationale: The team wanted a path to scale across departments and plants.

Gotchas (what bit them)

Retiring workers threatened to take plant knowledge with them.

Root cause: Institutional manufacturing experience was held by experienced employees rather than easily searchable systems.

Resolution: Use a knowledge chatbot and ingestion pipeline to preserve and expose that knowledge to workers.

Technical terms were hard to retrieve with semantic search alone.

Root cause: Manufacturing terminology and documentation made exact terms important.

Resolution: Combine keyword search with vector/RAG retrieval in OpenSearch.

A complex interface would not fit shop-floor work.

Root cause: Employees needed a simple access path rather than many different tools.

Resolution: Build a simple chatbot UI over the retrieval system.

Evaluation

The team evaluates the chatbot with answer accuracy, user feedback, deployment readiness, and whether it can scale to more departments and plants.

Metrics: accuracy over 85% · target above 90% · feedback incorporation · department and plant deployment readiness

Outcomes

• OSRAM deployed a chatbot solution with over 85% accuracy.
• The team expected accuracy to improve above 90%.
• The architecture supports deployment to other departments and plants.
• The solution gives shop-floor workers a simple UI over scattered plant documentation.

The case is an early production/deployment report rather than a mature multi-plant rollout.