Before the master retires: how to capture factory tacit knowledge using AI, a real-world RAG implementation

One extruder and a man counting down to retirement

Last winter, we took a call from a mid-size plastic extrusion shop. They had an extruder that had been running for seventeen years. Whenever they switched materials, seasons changed, or humidity shifted, the temperature control would drift and create a surface defect the team called orange peel. Only one person could consistently fix it: a technician named Chen, thirty-one years on the job, eight months from retirement.

When you asked how he troubleshoots these failures, he had one answer: I just listen to the sound and I know.

This problem sits at the core of manufacturing knowledge transfer. Our role wasn't to replace Chen, but to extract what was in his head before he left, the kind of knowledge that never makes it into an SOP. We've worked on projects like this before. This is what we actually learned: what we did, what failed, and the numbers it produced.

Why tacit knowledge doesn't stick around

The value of an experienced technician isn't his ability to recite specification tables. Those are in the manual. His value lies in extracting a root cause from a dozen uncertain signals: the batch number, the humidity level, screw speed, the temperature he feels at the die head, the specific sound he hears. These cues converge in his mind in seconds into a single action.

Tacit knowledge is difficult to transfer for three reasons. First, the technician can't explain it well because it's intuitive judgment, not a procedure you can list step by step. Second, it sits scattered across hundreds of individual cases, each recorded as we handled it this way, with no common structure. Third, it walks out the door with the person.

The traditional approach involved training videos and handover manuals. They end up in a shared folder, unopened, because when a production line stops, technicians don't have time to search through a two-hundred-page PDF for the relevant section. Knowledge on a shelf is the same as lost knowledge.

How we used RAG to extract it

RAG lets you turn scattered case experiences into searchable answers. We broke the work into three pieces.

First: collection. This had to happen while Chen was still there. We didn't ask him to write anything, because documentation burdens people and what they write down isn't always what they actually do. We spent three weeks shadowing him instead. Every time something went wrong, we recorded audio and video. Afterward we'd play it back: Why did you adjust the speed before the temperature? His exact reasoning, the way he said it, went into a transcript. Those transcripts became the foundation for the whole system.

Second: structure. Raw transcripts don't work with models, you get garbage results. We took each failure case and fit it into a template: what went wrong, which signals showed up, how he narrowed it down, what the actual root cause was, what he did, and when that fix wouldn't work. That last column mattered most. The real skill wasn't knowing what to do, it was knowing when the standard approach wouldn't work.

Third: connecting RAG to the interface. A technician on the floor types a question into a tablet the way he'd ask someone: After material changeover, orange peel at die exit, sounds muffled. The system pulls matching cases from the structured library, generates a troubleshooting path with source attribution, and includes the original case number. If the system doesn't have an answer, it says so. We built that into the design.

Eight months live: what the data showed

The demonstration generated enthusiasm. But adoption metrics told a different story. Here's what happened before and after launch.

That 68% usage rate in month eight started at 20% in month one. The floor team didn't trust it: How does a machine know anything? The shift happened at two in the morning when something broke. A young technician ran it through the system, solved it in ten minutes, never called Chen. By morning, people knew about it. Usage climbed from there. Tools get adopted when they work, not when they're announced.

One mistake we made

The first version included everything Chen said, even his hedges: I'm not sure, but let me try this. The system treated those hunches the same as confirmed fixes. A technician acted on one suggestion and made the defect worse. That taught us to add confidence marking during the structuring phase. We stored his confirmed countermeasures separately from his real-time experiments and surfaced them differently. Tacit knowledge contains both gold and noise. Take all of it and you weaken the signal.

Manufacturing knowledge transfer isn't fundamentally a data engineering problem. It's about being on site, next to the right production line, with access to someone who knows what he's doing. Our approach puts engineers on the floor to shadow the work, gets the RAG system into actual production, and ensures the night shift uses it because it works, not because it's a nice platform handed down. Chen's retirement date won't change. Capturing that knowledge before he leaves is the only measure that matters.