40万工单的AI质检系统：一个实习生的架构抉择

一个人扛起的AI质检项目

在Reddit上，一位IT支持公司的实习生抛出了一个颇具代表性的工程难题：公司把一个大规模AI项目几乎完全交给他独自完成。手上的资源是SQL Server里约40万条历史客户技术问题记录，每条记录都包含客户遇到的问题、支持人员采取的排障或解决动作，以及一个QA团队的复核。

他要构建的，是一个AI助手——面对一个新问题和员工填写的处理动作，系统需要给出三个维度的评分建议：

是否遵循了规定的排障步骤 → +2 / -2
评论/动作是否与问题相关 → +2 / -2
书面评论的语法是否正确 → +2 / -2

关键约束很现实：QA人员仍做最终决定（AI只是辅助），时间只有1-2个月，预算有限，且需要在CPU与GPU成本之间权衡。这不是一个追求SOTA的学术任务，而是一个必须在工程约束下落地的实用系统。

Reddit原帖：一个实习生独自承担大规模AI项目

把问题拆成三个独立子任务

这个项目最大的误区，是把它当成"一个大模型搞定一切"的任务。实际上三个评分维度的技术特性差异巨大，混在一起反而会让架构变得脆弱。更合理的思路是分而治之。

语法检查：最简单的一环

书面评论的语法正确性，几乎不需要训练任何模型。成熟的规则引擎和轻量级工具（如 LanguageTool）就能在CPU上以极低延迟完成检测，完全不涉及GPU成本。把这一项从复杂的ML流水线中剥离出来，能立刻减少三分之一的工程负担。这是整个项目中性价比最高的部分，应该优先快速交付。

相关性判断：embedding的主场

"员工的处理动作是否与问题相关"，本质是一个语义相似度/相关性问题。用一个句向量模型（sentence embedding）把"问题描述"和"处理动作"分别编码，计算二者的语义相关度，再训练一个轻量分类器（逻辑回归、梯度提升树）输出 +2/-2 的判断，是成本与效果都相当均衡的方案。

40万条历史记录在这里价值巨大——它们可以作为标注信号的来源（历史QA的通过/拒绝记录），也可以作为相似案例检索库。embedding模型可以选择能在CPU上跑的小型开源模型，批量离线编码后存入向量库，在线查询时延迟可控。

句向量模型（sentence embedding）的核心原理是将任意长度的文本映射到一个固定维度的稠密向量空间，使语义相近的文本在空间中距离较近。与传统的词袋模型或TF-IDF不同，embedding能捕捉词序和语义关系，例如"网络无法连接"与"断网"会被映射到相邻位置。常用的轻量级开源选项包括 all-MiniLM-L6-v2（384维，模型仅约80MB）和 paraphrase-multilingual-MiniLM-L12-v2（支持多语言），均可在普通CPU上以毫秒级延迟完成单条编码。将40万条历史记录离线批量编码后存入向量数据库（如 FAISS 或 ChromaDB），每次在线请求只需编码新文本并做一次向量检索，整体推理成本极低。逻辑回归或梯度提升树分类器则以历史QA的通过/拒绝标签作为监督信号，将"问题向量"与"动作向量"的拼接或差值作为特征输入，输出二分类结果再映射为 +2/-2 评分。

最难啃的骨头：排障步骤合规性

三个维度里，"是否遵循了规定的排障步骤"是真正的难点，也是作者最纠结的地方。原因在于它需要的不只是语义理解，而是对"标准流程"的结构化知识。

为什么纯分类器不够

不同类型的问题对应不同的标准排障步骤。如果只靠一个分类器从文本里硬学，模型既要识别问题类型，又要判断步骤完整性，容易在数据不均衡的长尾问题上崩溃。更稳健的做法是引入检索增强（RAG）：先根据新问题在历史库中检索出最相似的、曾被QA判定为"步骤完整"的案例，把这些范例作为参照标准。

RAG + LLM 的定位

这正是LLM能发挥价值的地方——但要用在刀刃上。把检索到的标准案例、规定步骤和当前员工的实际动作拼成prompt，让LLM判断"实际动作是否覆盖了应有的关键步骤"。LLM擅长这种需要上下文推理的对比任务，而单纯的embedding相似度做不到。

不过要警惕成本陷阱：LLM推理无论是本地GPU部署还是调用API，都是整个系统里最贵的一环。在1-2个月、预算有限的前提下，建议只对"排障步骤"这一维度动用LLM，另外两个维度用更廉价的方案。

检索增强生成（RAG，Retrieval-Augmented Generation）是一种将外部知识库与语言模型结合的架构模式：先用向量检索从知识库中找到与当前输入最相关的文档片段，再将这些片段作为上下文拼入提示词，供LLM参考生成答案。RAG的核心价值在于让LLM无需将所有领域知识"记忆"在参数中——对于本项目而言，排障步骤规范会随业务变化更新，直接将最新的标准案例注入prompt，比重新微调模型效率高得多。在本地部署场景下，参数量在7B以下的开源模型（如 Llama 3、Mistral 7B）配合4-bit量化可在单张消费级GPU或高性能CPU上运行，适合预算有限的场景做原型验证；若要避免GPU投入，也可先以 OpenAI API 或 Claude API 按量付费调用，仅对排障步骤这一维度计费，将API调用量控制在可预测的范围内。

推荐架构：组合拳而非银弹

综合来看，最适合这个场景的不是任何单一技术，而是一套分层组合：

语法维度：规则引擎/LanguageTool，CPU，近零成本。
相关性维度：sentence embedding + 轻量分类器，CPU即可，利用历史QA标签训练。
步骤合规维度：RAG检索相似优质案例 + LLM做步骤对比推理，这是唯一值得投入GPU/API预算的部分。
统一输出层：三个模块各自产出 +2/-2，汇总成一份建议，交由QA人员做最终裁决。

关于CPU vs GPU

既然QA是最终决策者、系统只是辅助，实时性要求其实没那么苛刻。embedding和分类完全可以离线/异步批处理，CPU足够。只有LLM环节需要考虑GPU，而这部分可以先用小参数量的开源模型在CPU上验证可行性，确认效果后再决定是否上GPU或调用外部API。

给独立实习生的务实建议

这个项目对一个实习生来说规模不小，但拆解后并非不可完成。关键是不要被"大规模AI"的名头吓到，也不要一上来就追求端到端的LLM方案。

先用两周时间把语法检查和相关性判断这两个"低垂的果实"做出可用版本，建立信心和baseline。再把剩余时间集中攻克排障步骤这个核心难点。40万条历史数据的真正价值，不是用来训练一个巨大的模型，而是作为标注来源和检索参照库——这才是数据资产最经济的用法。

在预算和人力都受限的现实里，"能跑、可维护、成本可控"远比"技术最先进"重要。一个由简单模块拼接而成、每一环都可解释可调试的系统，比一个黑盒大模型更容易被QA团队接受和信任。

对于时间和人力双重受限的项目，建立可量化的评估指标与QA团队保持对齐同样关键。建议在项目初期就从历史数据中抽取一个固定的测试集（例如各类问题类型均匀采样500-1000条，保留原始QA判定作为ground truth），每次迭代后在这个测试集上统一评估准确率、F1分数和误报率。这样做有两个好处：一是能客观衡量每个模块的改进是否真实有效，避免凭直觉调参；二是给QA团队一份看得懂的"成绩单"，建立对系统的信任。同时要注意，历史QA标签本身可能存在噪声（不同QA人员标准不统一），在训练分类器前最好做一次简单的标签一致性分析，避免在"脏标签"上过拟合。