上文讲到置信度系统可以让记账这件事儿变得越用越顺手，那本文就讲讲我是如何应用置信度系统的。
想象一个场景：你刚在楼下买了一杯咖啡，没等小票打完，手机App已经自动为你填好了账单的所有信息，而你所要做的，只是看一眼，点个确认。这并非科幻，而是我正在打造的AI记账App的核心体验，而实现这一切的‘幕后英雄’，就是我今天要分享的——AI置信度系统。
置信度
什么是置信度呢？
从应用的角度讲，置信度就是AI对自己回复答案的把握程度，就像人做判断题时会想‘我有八成把握选对’一样。系统用它来决定什么时候直接相信AI，什么时候需要让人类再检查。
因此对于置信度系统简单说就像是给AI装上了一个“学习和纠错”的大脑，它会记住你的每一次修正，从而让你的AI伙伴从一个需要你事事操心的新手，成长为能预判你想法的得力助手。你也可以把它想象成，你招了一个非常聪明的实习生：一开始他什么都问你，但你教他几次后，他就能完美地帮你预判并处理好所有工作了。
引入置信度系统前 (当前流程 - “单核CPU模式”)
现在的 AI 记账流程就像一个能力很强但很忙的“全能专家”（智谱API）。无论问题大小，我们都得把所有材料（OCR/语音识别文本）递给他，然后排队等待 TA 一个人处理所有事情（识别账单字段），最后给我们一份完整的报告（JSON串）：
graph LR A[获取输入] --> B[单一处理核心] B --> C[等待与返回] C --> D[本地后处理] A["获取输入：OCR/语音识别出原始文本"] B["单一处理核心：将全部文本脱敏后发送给智谱API"] C["等待与返回：等待网络传输和云端计算，API返回JSON"] D["本地后处理：对JSON串标准化和映射"]瓶颈： 整个流程的效率完全取决于网络延迟和云端API的响应速度。对于每一个账单，这都是一个无法避免的、固定的时间开销。
引入置信度系统后 (新流程 - “智能流水线模式”)
新的记账流程就像一条高度自动化的智能流水线。每个工位只做自己最擅长、效率最高的事情。
graph LR subgraph "输入与本地预处理" A["<b>1. 获取输入</b><br>OCR/语音识别文本"] --> B["<b>2. 预清洗与提取</b><br>规则引擎去除噪声<br>正则匹配(金额/日期/收支分类)"]; end subgraph "本地智能识别核心" B --> C["<b>3. 本地AI模型矩阵</b><br>NER模型(商品/账户)<br>分类模型(交易分类)"]; end subgraph "核心决策与增强" C --> D["<b>4. 本地终审裁定</b><br>结合用户历史偏好<br>计算<b>本地总置信度</b>"]; D --> E{"本地总分是否 >= 阈值?"}; E -- 否/低于阈值 --> F["<b>5. 云端记账专家会诊 (可选)</b><br>调用智谱等大模型API"]; end subgraph "统一出口与输出" G["<b>6. 质检与映射</b><br>标准化映射<br>择优选择与终审"]; H["<b>7. 最终产出</b><br>返回结构化JSON<br>更新本地偏好档案"]; end E -- 是/高于阈值 --> G; F -- 返回专家建议 --> G; G --> H;获取输入
- 目标： 将原始的、非结构化的用户输入（无论是图片 OCR 识别还是语音）转换为纯文本字符串。说明： 这是所有处理的起点。这一步的识别质量，是整个流水线性能的基石。
第一工位 (预清洗与正则匹配) ：首先，通过规则引擎（例如一个“停用词”列表）去除所有明确的噪声（如“点击查看详情”、“支付成功”等）。然后通过本地的、速度最快的正则规则引擎瞬间“抢”走它认识的交易金额和交易日期，并根据关键词初步判断收支分类。
第二工位 (本地AI模型矩阵)：
- 目标： 在用户设备端，通过轻量级的Core ML模型，完成核心的智能识别任务。说明：这是“智能”的主要来源。通过并行或串行调用两个核心模型
- NER模型： 负责“实体提取”，找出文本中的具体名词，如
商品说明和账户。分类模型： 负责“意图理解”，判断整段话最可能属于哪个交易分类。第三工位 (本地裁定与调度中心)：
- 目标： 本地的置信度系统首选根据用户的“历史习惯”和系统的“标准规则”来校准AI的初步预测。并对前两个工位的结果进行打分和汇总。说明： 这是第一个关键决策点。它会汇总正则和本地AI的输出，并优先考虑用户的历史偏好。然后，通过加权公式（
最终置信度 = (模型分 * 权重A) + (历史偏好分 * 权重B) + (映射相似度分 * 权重C)）计算出总分。def calc_confidence(model_score, user_habit, similarity): return (model_score * 0.6) + (user_habit * 0.3) + (similarity * 0.1) - 如果分数够高（高频场景）： 直接跳到第七步，流程结束。如果分数不够高（疑难场景）： 才触发第五步。
（可选）第四工位 (云端记账专家会诊)： 调用智谱等大模型 API 处理本地无法解决的“硬骨头”（置信度评分低于我们设定的阈值时），将专家得出的结果再传回第三工位进行置信度计算。
第五工位 (质检与映射)：
- 目标：这是所有路径的唯一汇合点，负责产出最终的、标准化的结果，进行最后的组装和评分。说明：
- 如果流程来自本地（高频场景）： 它会对本地的结果进行最后的标准化映射和组装。如果流程来自云端（疑难场景）： 它会对云端返回的“专家建议”进行同样的标准化映射，并与本地结果进行择优比较（选择置信度更高的那个），确保最终结果的可靠性。
最终产出
- 目标： 向App返回一个干净、可用、且包含置信度信息的数据对象，并为下一次学习做准备。说明： 生成的结构化JSON串将被用于在UI上展示。同时，如果用户对结果进行了修正，这次的修正行为会被记录下来，用于更新本地的用户偏好档案，后续遇到相同或相似的场景，系统会结合AI模型的实时预测和用户的历史偏好档案，进行一次动态的加权计算，得出一个个性化的置信度分数。
优势： 对于80%的常见账单，流程可能在前三个本地工位就已经结束了，根本不会走到调用云端API那一步。
可以明显看到流程变得很复杂了，你是否有很多的疑问和问题。我们从其中最核心问题开始：
问题一：流程变复杂，是否会导致性能变差、效率低下？“
答案：恰恰相反。新流程在绝大多数场景下，会比旧流程快得多 ，记账效率和用户体验将得到显著提升 。
虽然流程图看起来步骤更多，但关键在于这些步骤的执行位置和执行方式。
“网络延迟” vs “本地计算”：
- 旧流程： 最大的时间杀手是网络延迟（
Network Latency）。一次API的往返，即使API本身响应很快，也至少需要几百毫秒到一秒以上的时间。这个开销是每次记账都必须支付的。新流程： 前三到四步（正则、Core ML、置信度打分）全部在用户手机本地完成。这些操作利用的是手机本地的计算资源，执行时间是以毫秒计算的。对于本地能处理的账单，整个过程耗时将远低于一次网络API调用的时间。“串行等待” vs “并行处理”：
- 旧流程： 本质上是串行的，你必须等待云端返回结果，才能进行下一步。新流程： 多个本地识别器可以并行工作。在拿到OCR文本的瞬间，金额识别器、日期识别器、NER模型、分类模型可以同时开始计算，互不干扰，进一步压缩了本地处理的总时间。
“一视同仁” vs “快慢车道”：
旧流程： 无论是记一笔简单的“打车”，还是一笔复杂的“海外购物退税”，都得走一遍完整的、耗时相当的云端API流程。
新流程： 为不同复杂度的任务设置了“快车道”和“慢车道”。
- 快车道（80%的场景）： “打车”、“星巴克咖啡”这类高频、简单的账单，会直接在本地的“快车道”上被秒级处理，用户体验极佳。慢车道（20%的场景）： 只有那些真正复杂的、全新的账单，才需要走到调用云端API的“慢车道”。即使用户这次多等了一秒，但换来的是一个精准的结果，并且这次学习将使得下一次同类记账能走上“快车道”，这种体验上的权衡是用户完全可以接受的。
问题二：收支类型 (Income/Expense) 和 备注 (Notes) 字段在什么时候确定？
1. 【收支类型 (Income/Expense Type)】
可以发现，上述流程中，这个字段通常在第一工位 (正则匹配) 或 第二工位 (本地AI) 就能以极高的置信度被确定。
主要方式 - 规则与关键词匹配 (第一工位)： 这是最快、最常见的方法。我们可以在OCR文本中，通过预设的关键词列表来进行判断。
- 支出关键词： “支付”、“付款”、“消费”、“购买”、“费用”等。收入关键词： “收入”、“收款”、“退款”、“转入”、“到账”、“收益”等。处理逻辑： 只要文本中命中收入类关键词，就大概率判定为
收入，否则默认为支出。这个逻辑非常简单，但能覆盖99%的场景。辅助方式 - 分类模型判断 (第二工位)： 我们的本地多分类模型，在输出交易分类的同时，也可以被训练成输出收支类型。例如，当模型将交易分类为“工资收入”或“理财收益”时，它自然就知道这笔是收入。
因此对于 “收支类型” 这个字段，因为其判断逻辑相对简单明确，几乎总是在本地处理阶段早期就被确定下来，很少需要动用云端AI。
2. 【备注 (Notes)】
对于“备注”字段，它在自动化流程中的处理方式比较特殊。基于之前我自己的记账经验，设计理念是“留白”，默认置空，依赖用户手动填写或通过特定交互触发，但为未来的智能留出接口。
- 默认置空 (Default to Empty)： 系统的主要任务是精准地填充前6个核心字段。 “备注”字段在自动识别流程中，优先级是最低的，系统不会主动去“猜测”一段描述是否应该作为备注。因为“备注”是高度个人化、非结构化的信息，AI的“猜测”很可能画蛇添足，反而干扰用户。引导用户手动填写： 鼓励用户在确认账单前，将一些额外的信息（如“和朋友聚餐AA”、“这次是给妈妈买的礼物”等）手动填入备注栏。未来的智能预测（可选的高级功能）： 在更高级的版本中，可以设计一个逻辑：当系统完成所有核心字段的提取后，如果还有一些“无法归类”且有意义的文本片段剩下（比如“和xx的晚餐AA”、“帮xx代买”），系统可以询问用户：“是否需要将‘和朋友聚餐AA’这段信息添加到备注中？” ，这需要训练一个额外的、能区分“无意义噪声”和“有意义的补充说明”的简单分类模型，可以作为未来迭代的方向。
问题三：触发“第四工位 (云端专家)”的条件是什么？
因为触发第四工位意味着本次记账的效率会显著下降，所以这个触发条件（阈值）的设定，是整个系统性能和准确度之间最重要的权衡（Trade-off） 。
触发的核心逻辑是：当一个或多个关键字段的“置信度分数”低于我们设定的阈值时，就请求云端支援。
主要受哪些字段的影响比较大？
影响最大、我们最需要关注其置信度分数的，是那些最模糊、最影响账单核心意义的字段：
【交易分类 (Transaction Category)】(最高权重):
为什么重要： 这是记账的核心意义所在，也是最容易出错、最体现“智能”的字段。一笔消费被分错类，整个记录就失去了意义。
触发场景：
- 当本地分类模型对OCR文本给出的最高分分类，其分数依然低于阈值（比如低于
0.6）。这说明模型自己也“拿不准”这到底属于什么消费。当文本中出现了全新的、从未见过的商家或商品名，本地模型没有任何历史经验可循。[商品说明 (Product Description) / 账户 (Account)] (次高权重):
- 为什么重要： 这是分类判断的重要依据。如果连“买的啥”，“用啥付的款”都识别不出来，分类的准确性就无从谈起。触发场景： 当本地的NER模型无法从文本中识别出任何一个可信的商品或账户时。
如何酌情考虑触发条件？
我准备设计一个 “加权计分卡” 系统来决定是否触发云端调用，而不是简单地看单个字段。
Step 1: 为每个字段设置一个“重要性权重” (Weight):
交易分类: 权重 0.5 (最重要)商品说明: 权重 0.3账户: 权重 0.1金额和日期: 权重 0.05 (因为正则识别通常很准，权重可以很低)Step 2: 计算总置信度分数：
总分 = (分类置信度 * 0.5) + (商品置信度 * 0.3) + ...Step 3: 设置触发阈值 (Threshold):
- 我们可以设置一个总分阈值，比如
0.6。IF 总分 < 0.6 THEN 调用云端API这种加权方式的好处：
- 更智能： 它不会因为一个次要字段（比如“账户”）识别不准就轻易调用昂贵的云端API。只有当最重要的字段（如“分类”）出问题时，才更有可能触发。更灵活： 可以根据用户反馈和后台数据，动态地调整这些权重和阈值，在成本和准确度之间找到最佳的平衡点。例如，对于追求极致准确率的用户，可以设置一个更高的触发阈值，而对于普通用户可以设置一个更注重效率的阈值。
通过这种精细化的控制，我们可以确保绝大多数记账请求都能在本地高效完成，只把最棘手的难题交给“云端专家”，从而实现整体用户体验的最优化。
问题四：为什么“过于丰富”的交易类别列表会“毒害”AI？
常见的记账 app 中，一般可选的交易分类很丰富，并且会有一级分类，二级分类的设定，你们觉得这个设计的使用率高吗？
数据稀疏性问题 (Data Sparsity):
- 假设有10个一级分类和50个二级分类。用户一年记账1000笔，平均每个一级分类有100条数据，这对于训练模型来说是足够的。但如果分散到50个二级分类，平均每个类别只有20条数据，甚至很多长尾的二级分类（如“宠物-医疗”、“家居-维修”）一年都只有几条数据。用如此稀疏的数据去训练模型，模型根本无法学到有效的模式，最终的预测结果会非常糟糕，置信度也会一直处于低位。
分类边界模糊性 (Ambiguity):
- 很多二级分类之间的界限非常模糊。比如，一顿“商务午餐”，应该属于“餐饮美食-午餐”还是“人情社交-商务宴请”？这种连人类都需要思考一下的分类，AI会更加困惑。这种模糊性会导致模型在多个可能的二级分类上都给出差不多的低置信度分数，使得置信度系统难以做出“裁定”。
增加了“选择题”的难度：
- 对于AI来说，10个选项的单选题（一级分类）和50个选项的单选题（二级分类）的难度是指数级增长的。选项越多，犯错的概率就越大。
因此，我选择了 “只保留一级交易分类，并保证交易分类之间的差异化” 这个思路：
- 专注核心，提升准确率： 让AI模型（无论是本地的还是云端的）只专注于预测10-15个差异巨大、边界清晰的一级分类（如“餐饮美食”、“交通出行”、“购物消费”、“住房物业”等）。这大大降低了模型的学习难度，可以将有限的训练数据集中在最重要的分类上，从而显著提升一级分类的预测准确率和置信度。与置信度系统完美配合： 当AI的预测目标变得简单且明确后，置信度系统的“打分”也会变得更加可靠。系统可以更自信地判断出：“这次消费95%的可能是‘餐饮美食’”，而不是在“餐饮-午餐”、“餐饮-晚餐”、“餐饮-外卖”之间犹豫不决。
那么，如果真得有二级分类的需求，如何满足？
在和 Gemini 讨论之后，Gemini 推荐了一个思路，可以将二级分类的处理“后置”，从一个复杂的“AI多分类问题”转变为一个简单的“用户交互或规则匹配问题”。流程如下：
AI预测一级分类： AI的核心任务是精准地预测出这笔消费属于 “餐饮美食” 还是”人情往来“。
系统/用户处理二级分类：
- 方案A (用户自选 - 最简单): 当用户看到AI预填的“餐饮美食”后，如果他想进一步细分，可以点击这个分类标签，此时App再弹出一个只包含“餐饮美食”下属二级分类（午餐、晚餐、外卖、买菜等）的列表，供用户选择。方案B (规则辅助): 甚至可以加入一些简单的规则来辅助。例如，
IF 时间 in 11:00-14:00 AND 分类 is '餐饮美食' THEN 推荐二级分类 = '午餐'。方案C (记忆用户偏好): 系统可以记住，用户在“餐饮美食”这个一级分类下，最常用的是哪个二级分类，并将其作为默认推荐。总结一下，我们应该让AI做它最擅长的事——在模糊的信息中找到最核心的、差异化最大的模式（一级分类） 。然后，将更精细、更具个性化的二级分类任务，交还给更可靠、成本更低的业务逻辑和用户交互来完成。这种 “AI主外，规则主内” 的分层处理思想，正是构建一个健壮、高效、且用户体验优秀智能系统的关键。
记账 app 的核心目标
将记账从主动的"记录"转变为被动的"确认"，通过AI置信度系统可以实现：
智能预填：AI自动预填最可能的值
主动提醒：低置信度时主动提示用户确认
持续学习：记住用户习惯，不断优化预测准确性
通过记账流程的剖析可见，置信度系统不仅是智能记账的关键组件，更是AI应用浪潮中的核心审核机制。它如同一位智能质检员，持续评估AI输出的准确性并动态适配用户习惯——这正成为人机协同领域极具价值的研究方向。
置信度系统的本质，是让AI学会说‘我不确定’——而这恰恰是它真正懂你的开始。
因此关于这个 app 的后续构想：
一个面向未来的“超级发烧友”功能构想
既然流程已经完善，我们可以畅想一下未来。当我们给记账 App增加一个“发烧友”或“实验室”模式，将“置信度阈值”这个参数开放给用户自己调节。让app 的适配度再升一个等级。面对不同的用户可以自定义不同的阈值：
- 追求效率的用户： 可以将阈值调低（比如0.6，但一般不得<0.4，避免错误蔓延），这意味着他们信任AI的判断，希望尽可能减少手动干预。追求极致准确的用户： 可以将阈值调高（比如0.9），这意味着他们希望AI在有一点点不确定时，都把决策权交还给自己。
置信度系统的本质，是让AI学会说‘我不确定’——而这恰恰是它真正懂你的开始。
你会如何设计置信度权重？是更相信模型预测（权重A↑），还是更依赖用户习惯（权重B↑）？评论区等你方案！
文章较长，能看到这里实属不易，需要完整架构图或Core ML模型部署指南吗？关注我，我整理完成之后会做完整的分享。
