劉詩雁：未來印出來了：日化印刷的 AI 賦能之路

1. In one sentence

劉詩雁 shared how his team borrowed the 8D report — a quality management artefact manufacturing has used for decades — as the entry point for knowledge extraction, turning the accumulated judgement of veteran technicians in daily-chemical printing into an AI system that sales, quality assurance and line operators can all simply ask questions of.

2. The session

The speaker's background

The host introduced him as an entrepreneur of more than a decade who describes himself as a "serial entrepreneur who hasn't had his exit yet", carried along by the conviction "make something people want", with products spanning generative AI platforms, chatbots, adtech and HTML5 web solutions. On verification, his formal role is founder and CEO of 戴伊爾斯股份有限公司, English name Sean Liu (INSIDE feature), and he is also a director of Taiwan's data science association, whose registered full name is 社團法人資料科學協會, founded on 6 November 2020 (association about page). He has been active in Taiwan's technical community for a long time, and this session was his hands-on experience helping manufacturing clients take AI from theory to the factory floor.

What daily-chemical printing is

He opened by defining the industry term: daily-chemical printing is, put simply, the business of printing patterns and artwork onto packaging materials of all kinds, covering general packaging print and expanding steadily toward higher technology — QR code printing, NFC tags, anti-counterfeiting labels. On checking, 日化 originally means household chemical products (cleaning products, cosmetics and other non-food household chemicals; see the Wikipedia entry on household chemicals), so daily-chemical printing is the packaging print industry for these consumer goods, carrying both traditional packaging print and modern anti-counterfeiting and connected-label requirements.

Early on, both sides were bewildered

He was candid that when the team first talked to manufacturing clients about adopting AI, both sides were in a state of bewilderment — the team did not understand the client's business deeply enough, and the client was unfamiliar with their technology, because over the previous decade or so manufacturing had already adopted some kind of AI system through the successive waves of "smart manufacturing 2.0, 3.0". So the client's first question was always: what exactly is this AI you want to bring in, and how is it different from what is already in place?

His concrete example was the defect detection system on the client's production line: an ultra-high-speed industrial camera shoots thousands to tens of thousands of frames a minute, synchronised with a fast-scrolling roller photographing printed labels, using a convolutional neural network to judge defects in real time and mark them into the system. He explained that in principle you could do this with generative AI too (a multimodal model with vision fine-tuning, say) and the results might be decent — but neither the response time nor the compute cost at that frame volume is anywhere near what manufacturing can accept. That gave him a key judgement rule: not every scenario suits generative AI, and you have to be clear-eyed about the speed and cost constraints of the setting first.

Why the 8D report was the way in

He focused the direction on "how do you turn a manufacturer's existing data into knowledge that can be explained and conversed with". The way in was a mature quality management framework in manufacturing, the 8D report — the D stands for Disciplines, a framework giving quality assurance staff systematic guidance on how to correct a problem when a customer complaint arrives. On verification, the 8D methodology was first developed by Ford Motor Company in 1986 and formally published in 1987 in the *Team Oriented Problem Solving* manual, later becoming a standard tool for team problem-solving across automotive, assembly, and eventually food and medical industries (Wikipedia entry).

He stressed that the significance of the 8D report is that it is a manufacturer's decades-long quality management history: every customer complaint the company has ever had, which team was assembled at the time, which root causes were found and how it was finally resolved. More importantly, the 8D report's fields inherently link data across multiple internal systems: the product field in the header links to the product database, the part number to the materials database, upward to order and scheduling information, and the assembled team roster to HR records; downward, through the MES (Manufacturing Execution System, which he called "the heart at the core of the whole production line"), it connects to a large volume of shop-floor sensor data, UV energy meters, programmable logic arrays and other IoT data. He was frank that another reason for choosing the 8D report was that it gave the client a reasonable rationale — ask a client for a pile of data outright and they will ask "what problem are you actually solving", whereas the 8D report is an existing framework the client already uses and already values.

He also mentioned a practical detail: even when 8D reports live inside the ERP system, exporting them directly is often not enough, because sales staff replying to a complaint usually need a lot of supplementary data; but that supplementary data frequently has nowhere to live, because the ERP has no matching field, and ends up scattered across the organisation on somebody's laptop. His team used the 8D report number to reassemble that scattered supplementary material, as the corpus for later fine-tuning or retrieval-augmented generation (RAG).

Three pain points: sales, quality assurance, line operators

He narrowed the problem to a relatively simple setting: the needs of sales, quality assurance and front-line operators.

• Sales: they meet the complaint first, and when something like "there's a colour shift problem" arrives, they usually lack the expertise to judge the possible cause, and it takes a long time to find the right internal quality assurance contact — especially since manufacturing lines are often spread across different provinces or plants, making lateral communication expensive.
• Quality assurance: on receiving a complaint they also spend time pinpointing which customer and which specific scenario the problem arose in, and judging who to pull into a resolution team and what the likely root cause is.
• Front-line operators: line yield correlates strongly with operator experience. He described one very concrete phenomenon (speaker's own account): to spread production risk, manufacturers rarely build only in Taiwan, and also place plants in mainland China, Vietnam and Thailand; yields on Taiwanese and mainland Chinese lines are usually very high, but move the same process to Vietnam or Thailand and yield can drop straight to fifty or sixty per cent. So the problem companies keep wanting to solve is: how do you systematically transmit the experience of veteran technicians in the high-yield regions to the lower-yield lines and supply chain.

The result: from two or three weeks to an instant lookup

He showed a de-identified real conversation (the customer identity replaced with synthetic data): after a complaint arrives, sales asks the system directly about past handling of similar colour-consistency issues and whether there are precedents to work from, and the system lists comparable past situations; sales, quality assurance and operators can all query the same interface for what they need. He noted that replying to this kind of complaint used to take two to three weeks on average before anyone was sure how to answer the customer; now quality assurance can quickly locate who to involve and how to form the team, and operators can get the "veteran's wisdom" distilled from the historical record directly. On verification, INSIDE's feature describes the post-adoption effect as "finding the answer within minutes", which contrasts with his spoken two-to-three-weeks baseline and points the same way.

The technical skeleton: ETL is ninety-five per cent of the work

He reduced the whole system to a standard flow: an incoming customer question gets query rewriting, then semantic retrieval (he mentioned the team mainly uses Python for semantic search), with various chunking strategies in between — semantic chunking, percentile chunking, standard-deviation chunking. His key warning: unless you are in a special setting like defect detection, ninety-five per cent of the time in an AI deployment actually goes on ETL (extract, transform, load), and the time genuinely spent on fine-tuning or RAG itself is a small fraction. INSIDE's feature cites the same figure, classifying that work as data integration and standardisation.

He also named the real trade-off inside an enterprise: developing in an open environment, you can freely use OpenAI, Cohere re-ranking, external search APIs and so on to make the answers more complete; but to deploy inside the enterprise you usually have to accept that data cannot leave, which forks into two paths — an on-premises large language model architecture if the budget allows, and a fully open-source route if it does not.

3. Figures and cases

• Industrial camera defect detection: thousands to tens of thousands of frames a minute, with a fast-scrolling roller and a convolutional neural network judging defects in real time (speaker's own account).
• Yield comparison: high on Taiwanese and mainland Chinese lines, potentially dropping to fifty or sixty per cent after moving to Vietnam or Thailand (speaker's own account, no external source).
• Complaint response time: two to three weeks on average before adoption to confirm how to answer the customer; afterwards, historical cases can be looked up quickly (speaker's own account; INSIDE's report cross-cites the same direction).
• ETL share: he estimates that outside special settings like defect detection, about ninety-five per cent of the effort in an AI deployment goes on ETL, with fine-tuning and RAG a small fraction (speaker's own account; INSIDE's report cites the same figure).
• Origins of the 8D methodology: developed by Ford Motor Company in 1986, formally published in 1987 (Wikipedia).

4. Lines worth keeping

• "If we pool all this data together, it becomes a rather good source for extracting the veterans' knowledge."
• "Unless you're in a defect-detection situation like the one just now, ninety-five per cent of the time in an AI deployment goes on ETL."
• "The boss only needs to see that there's some magic in the middle and an answer comes out; but we're all developers here, and we know there's an enormous amount of dirty work going on in between."
• "You used to just ask them to hand over data, and everyone would think, hang on, why do you want all this, what are we actually solving?"

5. Tools and terms mentioned

• 8D report: the manufacturing quality management framework; D stands for Disciplines, used to systematically track how a complaint was handled — see above.
• MES (Manufacturing Execution System): connects ERP, scheduling and shop-floor sensors; he called it "the heart at the core of the whole production line".
• Semantic chunking / percentile chunking / standard-deviation chunking: document splitting methods, used to break long documents into fragments suited to retrieval-augmented generation.
• RAG (retrieval-augmented generation) / fine-tuning: the two technical routes for giving an AI system enterprise-specific knowledge.
• On-premises large language model architecture: one deployment option when data cannot leave the enterprise, as against the fully open-source route.
• NFC tags / anti-counterfeiting labels / QR code printing: the higher-technology lines of business daily-chemical printing has expanded into in recent years.

6. Wider observations

The most surprising thing in this session is the insight that "the 8D report is in fact the veterans' knowledge base" — he did not rush off to build some flashy multimodal or generative demo. He spent time understanding a data skeleton that already existed in the client's industry and that the client already believed in (the 8D report), and then followed that skeleton to extract the knowledge scattered around it. That completes a neat contrast with the two sessions before: 林鉦育 on how banking has to think through the use case before adopting AI, 吳柏翰 on how to choose technically between RAG and fine-tuning, and this session filling in the piece most easily overlooked and most time-consuming — how, in an industry you do not know, you find a data entry point both sides can accept, through interviews on site. His "ninety-five per cent of the time goes on ETL" is probably the most honest sentence of the day.

7. Sources