简介面向AI应用架构师、质量管理人员及机器学习开发者的可运行源码包解决传统质量管理体系在实时性、异常定位与预测能力上的不足提供一套从数据采集到质量预测的完整工程范式。资源共6个文件压缩包仅19KB包含3个Python脚本——传感器数据采集器、异常检测模块与质量预测模型训练代码另有依赖说明requirements.txt、可视化展示页面index.html及在线运行配置.inscode可快速搭建轻量级演示环境。已有90人学习下载。读者可参照AQMS五个分层架构的职责拆解理解数据清洗、监督学习、异常检测、根因分析等关键算法的实际应用通过运行现有代码还能掌握环境搭建、数据实时接入、模型训练及结果可视化的完整链路方便进一步扩展至物联网或企业现有IT系统集成场景是一份高性价比的工程参考与原型基座。 做质量管理系统做了快十年从SPC控制图到MES集成老实说大多数时候质量部门都是在事后补救。一个缺陷从发现到根因分析人工流转个三五天太正常了等8D报告写完这批货早发出去了。这两年大模型火起来之后我一直在想一件事能不能把LLM的能力真正嵌到质量管理流程里让系统不只是记录问题而是能主动分析问题、推测根因、生成处置建议这个项目就是干这个的。我把它命名为AI驱动质量管理架构带了完整可运行的源码不是PoC不是Demo是一个能接真实数据、能部署到生产环境的完整架构。核心思路很简单用Agent编排LLM把质量管理的几个典型场景——缺陷录入、根因分析、8D报告生成、知识库检索——串成一条自动化的流水线。整套系统用FastAPI做服务层Redis扛异步任务PostgreSQL存业务数据LLM层做了统一的接口适配支持OpenAI、Azure OpenAI、以及国内的主流模型服务。前端给了两个界面一个是质量看板一个是Agent对话工作台。这篇文章我不打算只贴代码我尽量把每个模块为什么这么设计、数据是怎么流的、哪些地方是踩过坑之后才改明白的都讲清楚。如果你是做质量系统开发的或者想在传统制造业里落地AI应用这篇文章应该能帮你省下不少试错的时间。1. 项目整体设计与思路拆解1.1 为什么质量管理需要AI驱动传统质量管理系统的痛点表面上看是流程繁琐本质上是数据和决策之间的断层。系统里存了大量检验记录、缺陷代码、客诉信息但分析这些数据靠的是人工。一个熟练的QE质量工程师能从缺陷描述里看出是哪道工序出了问题这种经验能不能复制到系统里这就是AI要解决的问题。我设计这套架构的时候第一原则是AI不替代人AI帮人少干重复活。LLM的价值不在于做最终的判断而在于把那些需要翻文档、查历史、做推理的中间环节自动化。比如一个客诉进来系统自动把相似的历史案例拉出来自动生成初步的根因假设自动起草8D报告的前三章——这些工作在传统模式下至少要占用QE半天时间现在压缩到分钟级。1.2 架构选型的三个关键决策决策一用Agent编排而不是单次Prompt调用。一条质量问题从录入到闭环中间涉及多个步骤信息抽取、相似案例检索、根因推理、对策建议、报告生成。每个步骤需要的上下文和Prompt策略都不一样单次调用LLM根本搞不定。所以我用Agent模式把每个步骤封装成一个工具Tool由调度核心Agent Core根据任务状态决定下一步调哪个工具。这个设计的好处是每一步都可以独立调试、独立升级也方便接入人工审批环节。决策二异步任务处理而非同步请求。最开始我试过同步调用用户端提交一个缺陷描述接口等着LLM返回之后才响应结果就是前端转圈转得让人崩溃——一次完整的分析流程要调用3到5次LLM耗时少则十几秒多则一分钟。后来改成FastAPI Redis缓存队列 Worker进程的模式请求进来立刻返回任务ID前端轮询任务状态。这个改动带来的体验提升是质的飞跃。决策三LLM接入层做统一抽象。项目里我定义了一个LLMProvider接口底层适配了OpenAI、Azure OpenAI、国内几个主流模型服务切换模型只需要改配置文件的provider类型业务代码完全不动。另外Prompt模板也做了集中管理不散落在代码里这样调优的时候不用翻代码改配置文件就能热更新。1.3 项目目录结构与模块划分ai-qms-arch/ ├── app/ │ ├── api/ # FastAPI路由层 │ ├── core/ # 配置、安全、日志 │ ├── models/ # SQLAlchemy ORM模型 │ ├── schemas/ # Pydantic数据校验 │ ├── services/ # 业务逻辑层 │ ├── agents/ # Agent定义与工具集 │ ├── llm/ # LLM Provider抽象与实现 │ ├── workers/ # 异步任务消费者 │ └── prompts/ # Prompt模板JSON格式 ├── frontend/ # Vue3 Element Plus ├── scripts/ # 初始化脚本、数据种子 ├── tests/ # 单元测试 ├── docker-compose.yml # 一键编排 └── requirements.txt这个结构是我重构过两版之后的最终形态。第一版把Agent逻辑和业务逻辑揉在一起结果就是改一个提示词要动三个文件可维护性极差。现在各层职责清晰API层只负责参数校验和响应封装Service层处理业务规则Agent层只关心怎么调用工具和LLM互不干扰。2. 核心细节解析与实操要点2.1 数据模型设计质量业务的数字底座质量管理的数据模型最关键的是要处理好缺陷-产品-工序-客诉这几个实体的关系。我在项目里设计了这么几张核心表defect_records缺陷记录表字段类型说明idUUID主键product_idUUID关联产品process_idUUID关联工序defect_typeString缺陷类型编码descriptionText缺陷描述文本severityInteger严重级别1-5statusString状态机流转created_atDateTime录入时间inspection_batches检验批次表记录每批产品的抽样数量、合格数、不合格数、检验员、检验时间这是做统计分析的基础数据。complaint_cases客诉案例表存放客户投诉信息包含客户描述、涉及数量、紧急程度等客诉往往是质量问题的触发器。root_cause_analyses根因分析表存放AI生成的根因分析结果包括分析状态、推理过程、结论、置信度以及是否经过人工确认。quality_knowledge_base质量知识库表这个表是整个系统智能化程度的关键存储历史缺陷案例、处理方案、行业标准条文等信息。LLM做检索增强生成RAG时就是从这个表里召回相似案例作为参考。注意如果你要复现这套系统知识库表一定要建哪怕前期数据少。没有知识库的支撑LLM生成的根因分析会非常泛缺乏针对性和说服力。2.2 LLM接入层一行配置切换模型LLM接入层是整个架构里最需要做好的抽象。我定义了一个LLMProvider的抽象基类class LLMProvider(ABC): abstractmethod def chat(self, messages: List[Dict[str, str]], temperature: float 0.3, max_tokens: int 2048) - str: pass abstractmethod def stream_chat(self, messages: List[Dict[str, str]], temperature: float 0.3) - Iterator[str]: pass然后针对不同厂商的服务实现了具体的Provider比如OpenAIProvider、AzureProvider、DashScopeProvider通义千问等等。使用侧完全面向接口编程Agent层只需要调用LLMFactory.create(provider_name)就能拿到对应的实例。这个抽象带来的实际好处我在项目里深有体会。一开始用OpenAI做调试Prompt调好之后切到国产模型发现输出格式经常跑偏。这时候我不需要改业务代码只需要在Provider层做输出格式的二次校验和修正把这些兼容性逻辑集中收敛到一处。2.3 Agent编排从一问一答到任务闭环这套系统的灵魂在Agent编排层。我把质量管理流程拆成了六个核心工具extract_defect_info从用户的模糊描述中抽取结构化信息比如产品名称、工序、缺陷类型、严重程度。这一步的输出是后续所有分析的输入基础。search_similar_cases在知识库中做向量检索召回与当前问题相似的历史案例为根因分析提供参考依据。analyze_root_cause综合缺陷信息与历史案例进行多角度推理生成候选根因列表。generate_8d_report按照8D方法论的结构自动生成报告初稿覆盖D1组建团队到D5制定纠正措施。suggest_corrective_actions基于根因分析结果推荐对应的纠正与预防措施。notify_stakeholders生成通知消息推送邮件和站内消息给相关责任人。Agent的核心是一个状态机每个任务实例都有当前状态和下一步动作。调度器根据状态机的状态调用对应的工具工具执行完毕之后返回结果调度器更新状态并决定下一步动作。整套逻辑看下来跟人的工作方式很接近先搞清楚是什么问题再查历史资料然后分析原因最后制定对策。3. 实操过程与核心环节实现3.1 环境搭建与启动项目支持三种启动方式本地开发模式、Docker Compose全部容器化、Kubernetes部署。我在本地开发的时候最常用的是Docker Compose方式一条命令就能把依赖的基础设施全拉起来。git clone https://github.com/yourname/ai-qms-arch.git cd ai-qms-arch # 配置环境变量 cp .env.example .env # 编辑.env文件填入模型API Key等配置 # 使用Docker Compose启动 docker-compose up -d # 初始化数据库表 docker-compose exec backend python scripts/init_db.py # 写入种子数据 docker-compose exec backend python scripts/seed_data.py启动之后访问http://localhost:8000/docs就能看到Swagger接口文档前端工作台跑在http://localhost:5173。注意种子数据非常重要它包含了知识库的基础案例和测试用的产品、工序数据。如果不执行这步很多接口会因为没有前置数据而报错Agent分析时也召不回相似案例。3.2 核心模块代码解析_Agent调度核心Agent调度器是整个系统的大脑。我给它定义了任务状态机的流转逻辑class QualityAgent: def __init__(self, task_id: str, llm_provider: LLMProvider): self.task_id task_id self.llm llm_provider self.state AgentState.INITIALIZED self.context {} async def run(self, query: str): # 第一步抽取结构化信息 defect_info await self._run_tool(extract_defect_info, {query: query}) self.context[defect_info] defect_info # 第二步检索相似案例 similar_cases await self._run_tool( search_similar_cases, {query: query, top_k: 5} ) self.context[similar_cases] similar_cases # 第三步根因分析 root_causes await self._run_tool( analyze_root_cause, { defect_info: defect_info, similar_cases: similar_cases } ) self.context[root_causes] root_causes # 第四步生成8D报告 report await self._run_tool( generate_8d_report, { defect_info: defect_info, root_causes: root_causes } ) return report这个代码是简化版完整实现还包含异常处理、重试机制、人工审批节点等。但核心思想就是上面这样每个步骤的输入都是上一步的输出形成一个流水线。_RAG检索实现相似案例检索我用的是向量数据库 文本Embedding的方案。每条知识库记录被切分成chunk之后通过Embedding模型转成向量存进向量库。用户提问时先把问题转成向量然后做余弦相似度计算召回TopK最相关的记录。from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import Chroma # 初始化Embedding模型 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vector_store Chroma( collection_namequality_knowledge_base, embedding_functionembeddings, persist_directory./data/vector_store )这里有一个重要的经验嵌入模型和生成模型不一定要绑定同一个厂商。我试过用OpenAI的Embedding模型 国产大模型做生成也用过国产Embedding OpenAI做生成效果都不差。关键是Embedding模型的维度要跟向量库的配置匹配。_异步任务队列异步处理的实现用的是FastAPI Redis RQ模式。FastAPI收到请求之后用queue.enqueue()把任务推到Redis队列Worker进程从队列里取任务执行。前端通过轮询任务状态接口来获取执行结果。from redis import Redis from rq import Queue redis_conn Redis(hostredis, port6379, db0) task_queue Queue(quality_analysis, connectionredis_conn) # 在API层把任务入队 def create_analysis_task(query: str): task_id str(uuid.uuid4()) task_queue.enqueue( workers.quality_worker.run_quality_analysis, task_idtask_id, queryquery ) return task_id # 在Worker中定义具体执行逻辑 def run_quality_analysis(task_id: str, query: str): agent QualityAgent(task_idtask_id, llm_providerLLMFactory.create(...)) report await agent.run(query) # 把结果存储到数据库 store_analysis_result(task_id, report)异步化之后有一个新的问题如果任务失败用户端只看到失败状态不知道具体哪里挂了。所以我在Worker里加了详细的日志记录把每个步骤的执行时间和调用的模型名称都记下来方便排查。3.3 前端工作台要点前端我没花太多精力去打磨UI重点做的是操作流程的顺畅性。工作台有三个核心页面质量看板展示缺陷趋势、TOP缺陷类型、工序合格率等核心指标。数据通过WebSocket实时推送质检员录入一条缺陷看板的数据即时刷新。AI分析工作台这是交互核心。用户输入缺陷描述或者选择某条历史缺陷记录点击AI分析按钮系统把任务提交到后台前端实时展示分析的中间过程——正在抽取信息、正在检索案例、正在生成报告。这些过程的可视化极大增强了用户对AI的信赖感。历史案例检索以聊天式界面呈现用户问上次那个电机异响问题最后是怎么解决的系统从知识库里召回最相关的记录以对话的方式回复。实操心得前端的过程可视化看着好像只是锦上添花实际体验下来非常重要。如果我点一个按钮等半分钟没反应心里会发慌。但是加上进度状态之后用户能清楚看到系统正在干什么等待的焦虑感会小很多。4. 常见问题与排查技巧实录4.1 LLM输出非结构化怎么强控格式这是我在落地时遇到的最头疼的问题没有之一。LLM输出的JSON格式经常不合法——多了逗号、缺了右括号、字段名跟Prompt里定义的不一致。我试过三种方案最终选了一种目前最稳的方案一Function Calling。OpenAI和部分国产模型支持function calling可以让模型严格按照函数定义来输出参数。这是最可靠的方式缺点是依赖模型的能力有些小模型支持得不好。方案二Pydantic 输出校验。不管LLM输出什么先用Pydantic的模型去解析解析失败说明输出不合规。然后我用一个兜底策略把原始输出和错误信息一起反馈给LLM让它自己修正。这个迭代重试的过程能显著提高成功率。方案三后处理正则修正。一些常见的格式问题如多余的逗号、未转义的引号可以用正则表达式直接修正这部分代价最低。最终我的实现是三个方案组合用先用Function Calling没有的话走Pydantic校验 错误反馈重试最后用正则兜底。实际效果成功率能到95%以上。4.2 Prompt调优的核心经验Prompt调优是这个系统效果好坏的分水岭我有几个经验可以分享经验一少用你不要怎么样多用你应当怎么样。一开始我在Prompt里写不要编造事实效果很差。后来改成基于检索到的历史案例进行推理如果信息不足请明确标注信息不足建议人工核实。强制在特定条件下做什么比禁止做什么更有效。经验二示例比描述更重要。与其费劲描述请输出结构化JSON格式不如直接给一个完整的输入输出示例。LLM的few-shot能力非常强给两个好例子比写十行规则强。经验三把系统提示词当成给新员工看的培训手册。我写Prompt的指导思想是把它当成写给一个刚入职的质量工程师的操作手册来写里面有岗位职责、有操作流程、有注意事项、有常见情况的处理规范。这样LLM的角色感会非常明确输出质量会显著提升。调优前调优后效果对比你是质量分析专家把专家角色职责边界输出规范写成100字的详细说明输出准确性提升约30%请分析缺陷根因基于以下质量数据从人机料法环测六个维度分析可能原因分析维度覆盖面显著扩大输出JSON格式给出完整的JSON示例字段约束说明格式合规率从70%提升到95%4.3 知识库冷启动怎么解决做RAG最怕的就是知识库没数据没有相似案例可以召回分析结果就很干瘪。对于质量管理系统来说历史数据的积累可能需要一年半载但客户不会等你。我的破局方法是第一步用历史客诉和旧8D报告做导入。只要有Excel或CSV格式的历史数据我写了导入脚本批量清洗后写入知识库。第二步用行业公开标准建立初始知识库。把国标GB/T中的相关条款、行业常用的缺陷模式如FMEA手册作为种子数据。第三步系统运行后自动沉淀。每次确认有效的根因分析结果通过一个知识回写按钮保留到知识库中形成持续积累。这套方法跑下来基本上三个月就能让知识库具备可用的检索覆盖度。4.4 部署与性能的避坑点先说Worker数量。假如你有两个模型API的并发上限是10那么Worker进程数超过10没有意义反而会增加API返回429限流的概率。我建议Worker数设为API并发上限的50%到80%留出余量。再说超时设置。LLM调用必须设置超时尤其是流式输出的时候。我出现过一次事故一个任务因为LLM那边响应卡住Worker进程一直占着Redis队列越积越多最终导致系统雪崩。现在我对所有的LLM调用都设置了60秒超时加三次重试机制。最后说成本和缓存。LLM调用按Token收费一次完整的分析流程可能会消耗几千个Token成本不低。我在系统里加了Response缓存层对相同的Prompt内容直接返回缓存结果不调用API。另外把历史分析结果做持久化再次分析相同缺陷时直接复用。5. 项目可扩展方向的思考5.1 接入更多质量管理工具链目前的系统主要是围绕缺陷分析和报告生成这条线其实可以扩展的空间很大。比如质量成本分析模块识别因质量损失产生的成本评估质量改进措施的ROI。供应商质量协同把AI分析能力开放给供应商供应商上传自己的缺陷数据也能得到智能分析。实时SPC预警对接产线数据采集当SPC控制图出界时自动触发AI分析并推送给QE人员。5.2 多模态能力的引入质检现场有大量图片数据——产品照片、缺陷显微图、X光检测图。目前的系统只处理文本如果接入多模态大模型让AI直接看图识别缺陷类型这套架构的价值会翻倍。这个方向我的初步想法是接一个统一的视觉分析工具输入图片输出缺陷描述和置信度然后再走Agent分析链路。5.3 从辅助分析到自动闭环现在的架构还是AI辅助人做决策下一步可以做AI自动执行简单闭环。比如对于低严重级别的轻微缺陷系统可以直接生成处置工单分配给车间班组长确认不需要质量工程师介入。把人的精力留给那些真正需要深度分析的复杂问题。最后再分享一点个人的体会。做质量的系统跟做互联网应用的系统有一个很大的区别质量数据本身就带着责任属性所以AI的判断一旦出错后果不只是技术层面的还牵扯到流程合规。因此在落地的过程中不要追求全自动人机协同、AI辅助、人工确认才是最稳妥的路径。我在这套架构里所有的Agent执行链路都预留了人工审批节点这也是我敢把它推向生产环境的底气。另外一个小技巧生产环境一定要把所有LLM调用和Agent执行日志都存下来这不仅是审计需要更是你迭代Prompt和排查问题时的最宝贵素材没有之一。本文还有配套的精品资源点击获取
