去年年底我做了个挺有意思的业余项目，名字叫The Truth Machine: A Push-to-Talk Fact Checker。简单说，它是一个按住说话、松手自动核查事实的小工具——你说一句"我觉得蜂蜜放多久都不会坏"，我这边松开按钮，几秒后返回给你一条结论："该说法在密封保存条件下基本成立，但存在含水量和污染前提，置信度中高。"整个过程不用打字，不用切窗口搜索，不用翻十几个网页交叉对比，你要做的就是按住按钮，把话说清楚。
这个项目的起因特别朴素：我在听播客、刷短视频、跟朋友吃饭闲聊的时候，经常听到各种听着很专业但仔细一想有点可疑的说法。比如"喝咖啡会让人脱水""空调除湿模式比制冷模式省电""某种维生素能显著预防感冒"。以前遇到这种情况，我一般会当场存疑，然后过五分钟就忘掉了。想当场验证？太麻烦——掏出手机、解锁、打开搜索页、想关键词、翻结果、来回比对来源，一套流程走完，饭桌上的话题早就跳到下一轮了。我在想，能不能做一个工具，把验证的摩擦成本降到几乎为零，让"随手一查"变成"开口一查"。
这个项目从开始到跑通第一个端到端原型，大概花了我两周的业余时间。这篇文章把我的完整思路、技术选型、踩过的坑以及最后留下来的设计取舍都写出来。它不一定适合所有人直接抄作业，因为涉及不少本地模型和API的组合，但对想做语音交互工具、实时核查系统、或者单纯好奇"机器测谎"怎么落地的人来说，应该能提供一份有价值的参考。
1. 这条路的关键问题：为什么是"按住说话"而不是"喊一嗓子"
先说交互设计，这是The Truth Machine最早定下来的核心决策。
从一开始我就没打算做一个类似语音助手的东西。你喊一声"嘿助手，帮我查一下蜂蜜会不会变质"，听起来很自然，但实际用起来问题特别多。首先是唤醒误触，设备在客厅里，电视里有人喊一句类似唤醒词的话，它就醒了，然后开始听你后半句，识别结果乱七八糟；其次是持续监听带来的隐私心理压力，很多人对着一个"永远在听"的设备说话会不自觉地拘谨，尤其聊到个人信息的时候；最后也是最关键的——自然语言指令解析本身就是一个大坑，"帮我查一下XX是不是真的""XX这个说法靠谱吗""你听说过没有，XX"这类变体太多了，你得先猜用户到底要做核查还是要闲聊还是单纯在问问题。
Push-to-Talk完全绕开了这一堆麻烦。
它背后的逻辑极其简单：物理按压动作本身就构成了完整的指令边界。我按下按钮的那一刻，就是在说"我开始发起一次核查"；我开口说的话，就是"要核查的原始断言"；我松手的那一瞬间，就是在说"我的话讲完了，现在开始处理"。不需要唤醒词，不需要意图分类，不需要判定"这句话到底是不是一个问题"。整个交互协议变成了一次干净的录音+传输+处理。
这里有一个很多做语音产品的人容易忽略的技术红利：按压本身就是最完美的语音活动检测（VAD）信号。
传统语音助手要处理一整套端点检测问题——什么时候人开始说话？什么时候停顿是语气停顿而不是句子结束？背景噪音里有没有人声？这些问题每一样都要花大量算力和调参去解决。而Push-to-Talk把问题直接简化掉了：我按下按钮才开始录音，所以按下之前的噪音天然与我无关；我松手就结束录音，所以结尾的静音段最多修剪个几百毫秒就够了；整个录音被物理地封装为一个"语义单元"，里面几乎必然包含完整的人声和完整的句子边界。我后面甚至把自动VAD模块整个删了，就保留了一个简短的端点修剪函数，效果反而更稳。
再说延迟感知。手指按住按钮的时候，用户知道系统正在录音，此时系统处于"充电"状态。松手之后用户开始等待结果，但物理按压本身已经给了用户一个"预期建立"的过程。实测下来，从松手到结果返回，只要控制在3秒以内，用户就不会产生明显焦躁感；而如果是普通语音助手那种"说完了还要等唤醒词回味一下"的状态，用户的心理等待时间会拉长一倍都不止。
硬件上，我的原型用的是一个USB小按钮，驱动程序把它映射成键盘上的一个按键。桌面端我用的是空格键按住说话，长按启动录音，松开触发提交；移动端我用的是触摸按住录音组件，用的是浏览器的Pointer Events。整套交互代码其实不超过100行，但却是整个项目里用户反馈最好的一部分。
这也是我强烈建议所有想做类似工具的人先想清楚的一个点：不要一上来就堆模型，先把你的人机交互协议定义明白。哪怕你后面换再强的ASR、再强的LLM，只要交互边界是模糊的，整个产品用起来就会透着一股蠢劲。
2. 五段式核查流水线：从声波到证据链的完整通路
The Truth Machine的技术骨架是一条五段式流水线：音频采集与修剪、语音转写、声明拆解、证据检索、评估输出。这一节我把每一段的选型理由和核心实现讲透。
2.1 第一段：音频采集与端点修剪
这部分我用的是平台自带录音API加一个轻量修剪逻辑。因为物理按键已经给出了清晰的开始和结束信号，所以我不需要实时判断人声从哪里开始，只需要在录音结束后处理掉开头结尾的空音即可。
具体做法是：对PCM音频做峰值检测，找第一个超过固定阈值的采样点和最后一个低于静音阈值的采样点，各向外多保留400毫秒，然后截取中间部分。这个逻辑听起来土，但实测在安静环境下准确率非常高，而且几乎没有算力开销。
def trim_silence(pcm, sample_rate, threshold=0.015, pad_ms=400): import numpy as np data = np.frombuffer(pcm, dtype=np.int16).astype(np.float32) / 32768.0 frame_len = int(sample_rate * 0.02) # 20ms一帧 rms = np.sqrt(np.square(data.reshape(-1, frame_len)).mean(axis=1)) voiced = np.where(rms > threshold)[0] if len(voiced) == 0: return b'' pad_len = int(sample_rate * pad_ms / 1000) start = max(0, voiced[0] * frame_len - pad_len) end = min(len(data), (voiced[-1] + 1) * frame_len + pad_len) return data[start:end].tobytes()注意一个实际问题：USB按钮映射成键盘按键后，用户有时候会不小心按住太久，录进去一大段45秒的独白。这种情况在原型阶段处理策略就是截取前30秒拒绝后面的内容，同时在界面提示"请把断言控制在20秒以内"。这不是模型能力不够，而是检索阶段如果句子太长，拆出来的声明太多，会严重拖慢端到端延迟。让用户把话说明白、说明短，是对整个系统最大的优化。
2.2 第二段：语音转写，本地小模型还是云端大模型
语音转写这块我一开始想偷懒，直接调云端的ASR服务。后来发现两个问题：一是有时候只是临时验证一小段话，我不想为了这一句话把一个包含敏感信息的音频传到云端；二是我的原始版本就跑在树莓派和旧笔记本上，网络波动会直接把延迟拖到不可接受。
所以最后我选的是本地Whisper——更具体地说，是Whisper的小型模型（small）。为什么不用tiny？tiny的中英文混合识别能力太弱了，实测"蜂蜜"识别成"粉末"的次数多到让我怀疑人生；为什么不用medium或large？因为这只是一个"拿到文本去做检索"的前置步骤，不需要逐字逐句的广播级精度，small在中文和英文上的表现已经足够好，而且在CPU上跑一段10秒的音频，small大约只要1到1.5秒。
转写时有一个参数让我对比了很久，就是initial_prompt。很多人直接忽略这个参数，但我在实测中发现，给Whisper一行上下文提示能显著改善口语化的断句和专有名词。比如我设置initial_prompt="以下是一段关于日常生活常识的中文口语，请转写为简体中文。"，蜂蜜、咖啡、维生素这类生活词的识别错误率能下降三到五个百分点。这个参数本质上是在引导Whisper的解码器倾向于某种词汇分布，代价很小，收益却肉眼可见。
2.3 第三段：把一整句话拆成可核查的原子命题
这一段是整个流水线里最容易被低估的环节。很多人以为语音转出来之后直接丢给搜索引擎或者直接丢给大模型验证就行了，实际上这是错的。因为一句日常断言往往是复合句，里面可能包含了几个独立的命题，它们的真伪完全不同。
举一个我测试时用过的真实例子："蜂蜜含水量低所以不会变质，但如果你把它放在潮湿环境里还是会吸水发酵。"这句话里至少涉及三个独立命题：
- 蜂蜜含水量低；
- 蜂蜜在这样的条件下自身不会变质；
- 潮湿环境下蜂蜜会吸水发酵。
如果把这整句话作为一个整体去检索，搜索引擎返回的页面可能有的在讨论蜂蜜结晶，有的在讨论蜂蜜的抗菌性，有的在讨论储存方式，相关性会被摊得很薄，最后的评估结果就会模棱两可。
我的解决方案是让一个语言模型专门做声明拆解。输入是转写文本，输出是一个结构化的声明列表，每一条都包含主语、谓语、宾语或者更一般的形式化表述，并且要求它们必须是"可以被证据支持或反驳的最小命题"。
我用的声明拆解提示大致长这样：
请把下面的口语断言拆解为独立的知识命题列表。 规则： - 每个命题必须是一个可验证的陈述句； - 拆解后不要保留原句中的立场词、推测词； - 如果原句是绝对的（比如"永远""绝对"），保留这种绝对性； - 输出JSON数组，每个元素包含：statement(命题文本), keywords(3-5个用于检索的关键词)。 内容：{transcribed_text}为什么要求保留绝对性词？因为我发现很多日常谣言恰恰就藏在绝对化表述里。"牛奶不会变质"和"牛奶在冷藏条件下可以保存较长时间"是完全不同的两个命题。前者几乎必然为假，后者才需要具体证据链来支撑。我踩过的坑是：拆解模型为了求稳，会自动把绝对化表述软化，导致最后核查出来的结论跟用户实际想表达的意思对不上。
2.4 第四段：多源检索，我为什么不只用一个搜索接口
拿到原子命题和关键词之后，就是证据收集。这一段我有一个原则：至少两个独立的检索源，且每个源之间不能有暗线关联。
为什么强调这一点？因为现在很多搜索结果的正文页面互相抄袭严重，A网站抄B网站，B网站抄C网站，最后看起来有十几个来源在支持同一说法，实际上底层只有一篇原创内容。如果不做源独立性检查，你核查出来的"多源一致"是彻头彻尾的幻觉。
我的检索层结构是这样的：
- 第一路走常规搜索引擎API，取搜索结果的前五条链接，再抓取页面正文；
- 第二路走一个本地的学术/百科语料库检索，比如Wiki数据、一些公开的科普文章集合，这一路用来兜底，保证即使搜索引擎返回一堆SEO内容农场页面时，本地语料库依然能提供相对权威的解释；
- 第三路，也是我后来加的，是对已抓取页面的域名做聚类去重：如果五个结果里有三个都来自同一个媒体集团或者同一个内容聚合站群，那么在后续计分时，这三个只算一个独立来源。
正文清洗我也踩了不少坑。很多页面直接用requests抓下来是乱码，得先判断字符集；有的页面正文藏在嵌套div里，抓回来的是一坨导航菜单和广告文本。我最后用了readability类的正文提取库，再对清洗后的文本做段落切分和向量化，与声明做相似度排序，取top-k段落作为证据段。
这一步的伪代码大致是这样：
def retrieve_evidence(claim, keywords): pages = search_api(keywords) # 第一路 pages += local_corpus_search(claim) # 第二路 cleaned = [clean_page(p) for p in pages] chunks = [chunk_paragraph(c) for c in cleaned] scored = rank_chunks(claim, chunks) # 向量相似度 independent = dedup_by_source_domain(scored) return independent[:8]这里有个体验上的细节：证据段至少要保留三家独立来源才算稳。如果检索完只找到一篇孤立的博客文章，哪怕它说得头头是道，我也倾向于在结论里降低置信度，而不是直接采信。
2.5 第五段：评估输出，先给证据，再下判断
最后一段交给评估模型，但不是简单地问它"这句话对不对"。我的评估提示要求模型先引用证据，再做判断，再给置信度。顺序不能反。一旦让模型先给判断再凑证据，它就会倾向于自我合理化；而如果强制它先陈述"根据来源A说了什么，来源B说了什么，来源C的数据是……"，再得出结论，模型的自洽性和可解释性会强很多。
判定标准我用了五档：完全真实、大部分真实、混合（部分真实部分虚假）、大部分虚假、完全虚假。除此之外还有两个特殊输出：无法证实（证据不足）和来源冲突（多个可信来源给出相反结论）。
为什么保留"无法证实"和"来源冲突"这两个看起来有点泄气的选项？因为我发现，如果强制模型在所有情况下都站边，它就会用非常含混的措辞把结论糊弄过去，比如"该说法有一定道理，但需要具体分析"——这种废话等于没说。而把"无法证实"作为合法选项之后，模型反而更敢于给出明确判断，因为它知道不用在所有时候都硬撑。这个设计帮我找回了大量被模糊化吞掉的判断质量。
3. 置信度计算：怎么避免"机器认为自己对了"的自我欺骗
如果只是让LLM输出一个置信度数字，那本质上是在问模型"你对自己刚才说的话有多自信？"——这种置信度是主观的，而且LLM普遍过度自信。所以我设计了一个三层合成的置信度体系，尽量把主观成分压到最低。
3.1 第一层：证据一致性
证据一致性衡量的是多个独立来源之间的结论是否互相吻合。做法是：对每一段证据分别跑一遍分类，得到该段证据支持"真实""虚假"还是"中性"的极性判断，然后计算这些判断之间的一致性。
如果三个独立来源都支持"真实"，一致性很高，这一层得高分；如果两个支持真实、两个支持虚假，一致性就趋近于零，这一层拉低总分并触发"来源冲突"输出。我用的是类似简单Cohen's Kappa的思路，但为了轻量，直接用了极性格一致率。
这层的关键在于"独立来源"四个字。如果没做去重，三个来自同一篇转载链的网页会被当成三个独立投票者，一致性虚高，所以去重这一步必须在计分之前完成，否则整套置信度就是一个数字游戏。
3.2 第二层：来源可信度加权
不同来源的权重天生不该一样。一篇发表在同行评议期刊的论文摘要，和一条个人社交平台帖子的说服力，我们不搞一刀切，但要给一个初始权重。我的初始权重表大致如下：
| 来源类型 | 初始权重 |
|---|---|
| 学术论文/官方统计机构 | 1.0 |
| 权威媒体/百科 | 0.8 |
| 一般新闻网站 | 0.6 |
| 垂直领域专业博客 | 0.5 |
| 个人博客/论坛/社交平台 | 0.3 |
| 被我拉黑的SEO农场/站群 | 0 |
但权重不是死的。如果低权重来源提供了具体的一手证据，比如拍了实验照片、贴了完整的实验数据，它的实际说服力会高于一篇没有细节的权威媒体评论。所以我在这一层还加了一个"证据具体性"的调节因子：证据里是否包含数字、实验条件、时间戳、可验证的引用来源。公式大致是：
source_score = base_weight * (0.6 + 0.4 * specificity_factor)specificity_factor是0到1之间，通过证据是否含数字、年月日、机构名、方法描述等简单特征打分。
3.3 第三层：模型校准与自反证
第三层设计到最后变成了一场跟自己较劲的过程。LLM给出的结论置信度不可尽信，但我可以给它设定一个"必须尝试反驳自己"的义务。具体做法：在评估提示末尾加了一步——"现在请站在反对该结论的立场上，列出最强的三条反驳证据；然后结合这些反驳，重新评估你刚才的判断是否过于乐观。"
这一步的心理学道理其实不复杂：模型跟人一样，顺着自己思路往下写会越写越自信；强制它换立场找理由，它就能发现自己原来论据里的漏洞。我在几十个测试例子上对比过，加入强制反驳环节之后，模型输出的置信度普遍下降5到10个百分点，但判断的准确率和人类评估者的一致性反而上升了。
最后的总体置信度是三层分数加权合成：证据一致性占40%，来源可信度占30%，模型自衡量占30%。综合分映射到五档判定：0.8以上为完全真实或完全虚假，0.6至0.8为大部分真实或大部分虚假，中间为混合。
3.4 "无法核实"不是失败，它也是结论
我必须单独说一下这一点。很多做事实核查的人都想追求一个100%的判定，但我发现，当检索到的证据不足或者来源冲突严重到无法形成有效结论时，老老实实输出"无法证实"或者"来源冲突"才是对这个系统信誉最好的保护。
有一说一，一个敢说"我暂时不知道"的机器，比一个永远自信满满但偶尔胡说八道的机器，可信度高得多。在真实使用场景里，我反而观察到用户对"无法证实"结果的接受度远高于对一个硬凑出来的低质量结论。因为它符合直觉——你自己查资料的时候不也经常遇到查了半天查不清楚的情况吗？
4. 真机实战翻车记录：六个把系统打蒙的典型案例
端到端原型跑通之后，我拿它做了大量真实场景测试。这里记录六个最有代表性的翻车案例，每个都对应一个具体的系统缺陷和修复方案。这部分内容是我觉得对同行最有参考价值的。
4.1 案例一："蜂蜜"识别成"粉末"，检索全部跑偏
现象：我说"蜂蜜不会变质"，松手后系统返回来一大篇关于"粉末保鲜注意事项"的证据链，结论是"大部分真实"。
排查链路：先在转写日志里看文本，发现ASR输出的是"粉末不会变质"。问题出在环境噪音——我测试的房间里风扇声比较明显，加上"蜂蜜"和"粉末"的音节结构确实接近。Whisper小模型在信噪比不高的情况下把这俩搞混了。
修复方案：加了两个改动。第一，修剪函数里提高阈值，把20ms帧的RMS阈值从0.01调到0.02，弱化风扇底噪的影响；第二，在ASR之后加了一遍拼音模糊自查——对转写结果里置信度低于某个阈值的词，重新用ASR的compression_ratio_threshold等参数做二次解码，并对比几个候选词在检索结果里的表现，选搜索命中更合理的那个。
4.2 案例二：复合句被拆成一个命题，结论以偏概全
现象：我测试"蜂蜜含水量低所以不会变质，但潮湿环境下会发酵"，系统只核查了"蜂蜜含水量低"，返回"完全真实"，完全忽略了后面关于潮湿环境下会发酵的部分。
排查链路：声明的拆解阶段出了问题。LLM倾向于把一个复杂因果句当成一个整体命题，尤其是当因果词"所以""因此"出现的时候，它经常把整句打包成一个"因果复合命题"。这对检索阶段是致命的，因为搜索引擎最擅长处理的是简单陈述，复合因果句会让搜索结果分散到"蜂蜜特性""蜂蜜储存"两个方向，每一个方向都证据不足。
修复方案：在拆解提示里加了一条明确规则："含有因果连接词（所以、因此、导致、由于）时必须拆成原因命题和结果命题两个独立条目。"同时要求拆解模型输出每个命题的"可检索性评分"，如果评分低于阈值，就在检索时把相邻命题合并检索。这算是一套"先拆后并"的双保险。
4.3 案例三：搜索引擎返回的SEO内容农场证据污染
现象：核查"喝咖啡会脱水"时，系统抓回来的证据里有一篇标题夸张的内容农场文章，通篇没有任何数据来源，只是复述了一遍"咖啡利尿，所以会脱水"，但因为它关键词匹配度极高、排名靠前，被选进了top证据段，导致结论偏向"完全真实"。
排查链路：看证据面板时我发现，返回的八段证据里有两段来自同一个站群的不同域名，还有一段明明是在讨论奶茶和咖啡因的混合饮料，被段落切分硬生生切进来。问题本质是检索阶段只看了关键词相似度，没有做"来源可信度排序+正文主题一致性"的双重过滤。
修复方案：加了两层过滤。第一是在检索前维护一份内容农场域名黑名单，命中直接丢进权重0的桶；第二是对候选证据段落做一次主题分类，跟声明主题差异过大的段落直接淘汰，不再参与后续计分。这个改动之后的证据干净程度提升非常明显。
4.4 案例四：时间敏感型声明，"去年有效，今年失效"
现象：核查"某地区2022年降水量创下历史新高"时，爬到的数据页面混杂了1998年的历史数据和一份2023年的灾害报告。系统没有区分时效性，把多个不同年份的数据混在一起当成"证据一致性高"。
排查链路：这类问题属于"声明的隐含时态"没有被显式提取。用户说"去年创纪录"，其实隐含了"这个说法在2022年成立，在2023年是否依然成立需要另查"的时效结构。我的声明拆解阶段没有提取TIME属性，评估模型也没有被要求先判断声明是否有时效窗口。
修复方案：在声明结构里增加一个可选字段valid_window，拆解模型如果判断命题涉及时间，就输出"截至某年某月"或"年份范围"；同时要求证据抓取时保留页面的发布时间或数据更新时间，在评估阶段把超出声明时效窗口太久远的证据降权。这个字段后来被证明是通用性的增强，不只对历史数据有用，对很多关于"当前状态"的半衰期很短的断言也有效。
4.5 案例五：评估模型的天生乐观主义
现象：测试几组完全错误的断言，比如"常温下蜂蜜永远不会变质""微波炉加热食物会产生致癌物质"，系统给出的判定虽然是"虚假"，但置信度只有0.55至0.6，远低于我对这些明显错误命题的预期。
排查链路：我查看了评估模型输出的logprob分布，发现它非常倾向于选中性温和的措辞。进一步检查发现，模型在生成结论时，先写出了一串"虽然...但是..."的让步句，然后才给出否定判断。这种语言模式在常见的对话场景里是被社会化的——AI助手总被训练成尽量显得客观、温和，不轻易把话说死。
修复方案：一个是我在前面提到的强制反驳环节；另一个是把评估提示里加入"该命题为伪时，请直接使用'错误'一词，不要使用'可能不准确'或'值得商榷'等委婉表达"这种风格约束。另外我在最终置信度映射上做了一个校准实验，把模型自评分数整体压低了10个百分点，然后重新测量了与人工标注的一致性，找到了校准点。这套校准流程以后遇到换模型时也可以复用。
4.6 案例六：一次彻底的"无法证实"，让系统躲过了一个大坑
现象：测试"市面上某品牌的空气净化器能去除99%的甲醛"时，系统检索到的来源包括品牌官网、一个第三方评测论坛的讨论帖、一篇某装修媒体的软文。三个来源没有一方提供可验证的独立检测报告，而且评测帖里有两个用户提到"感觉没啥用"但没有任何实测数据。
排查链路：这一例不算是bug，但它让我意识到"无法证实"这个输出分支在什么情况下会被触发。系统最终输出了"无法证实：证据不足"，置信度0.60。我当时觉得很惊喜：模型没有因为品牌官网的华丽数据就站队"真实"，也没有因为个别用户差的体验就站队"虚假"。
复盘结论：这恰恰是声明拆解阶段的功劳——它把"甲醛去除率99%"从"空气净化器值得买"这个大命题里拆出来了。大命题里掺杂了太多主观价值和选购偏好，机器不该也不适合判对错；但"99%是独立检测还是一手自夸"则是一个可以被证据检索回答的客观问题。这种边界感，我认为就是事实核查器最应该守住的底线。
5. 对话场景里的判定陷阱：绝对化表述、因果倒置和模糊概念
跑完上面那些案例之后，我对系统做了一次压力测试，专门拿各种"语言陷阱"来打它。结论是：事实核查的本质不只是核对事实，更是核对表述的结构。
5.1 绝对化表述是最大的核查稻草
"永远""绝对""百分之百""没有任何副作用""完全不含有害物质"——这类词一旦出现在断言里，几乎等于给系统递了一份大礼。因为绝对化表述只需要一个反例就能推翻，所以在我的评估提示里有一条规则：如果声明包含绝对化限定词，默认进入"高度怀疑"通道，检索时优先搜索反例证据。
实际效果很好。比如"维生素C能完全预防感冒"这个断言，如果按普通检索，你翻到的正面信息比较多，因为确实有部分研究支持大剂量维C能缩短病程；但如果优先搜索反例，会发现系统性回顾研究的结论更偏向"不能预防"。两路证据交叉之后，系统给出"大部分虚假"而不是"部分真实"，这个判断我认为更接近现代医学共识。
5.2 相关性被说成因果性
另一类非常难处理的陷阱是因果倒置。比如"长期睡眠不足的人更容易感冒，所以睡眠不足导致感冒"——这里其实是观察性相关，不是因果链条。我的薄弱环节在于：评估模型本身的科学素养决定它能否区分相关和因果，而我作为系统设计者，只能通过提示词引导。
我测试出的一个经验是：当声明里出现"所以""导致"这两个词时，单独跑一轮"是否存在其他解释"的反证检索。如果检索结果里有互相矛盾的解释模型，就在结论里明确打出"结论：存在相关性证据，但因果推断证据不足"。加了这个步骤后，系统在健康医疗类断言上的可信度提升不少。
5.3 模糊概念导致的永久半真半假
有一类声明，你不管怎么查都只能得到一半结论，因为主要概念本身就是模糊的。比如"某某食物有利于肠道健康"——什么叫"肠道健康"？菌群多样性？排便规律？还是没有炎症反应？不同研究可能用了完全不同的观察指标。遇到这种情况，我要求系统在结论里明确输出"该说法取决于如何定义XX概念"，这样虽然不是机器追求的干净结论，但却是人类可理解的最准确表达。
6. 从原型到真正可交付的工具：延迟、隐私和边界感
最后一个部分聊聊产品化。The Truth Machine跑通原型之后，我确实动了念头想做成一个日常能用的工具，于是又花时间解决了几件在原型阶段被无视的事。
6.1 延迟优化：从八秒压到三秒
第一版端到端延迟是8秒左右，分布在：音频传输0.1秒、ASR转写1.5秒、声明拆解1秒、检索3.5秒、评估1.5秒、其余开销0.4秒。最痛的是检索，因为搜索引擎和正文抓取都是网络往返。
我的优化组合拳：
- ASR换用量化后的int8模型，速度快了30%，精度下降可接受；
- 声明拆解模型换成小模型做初拆，只对评分低于阈值的高难句才升级成大模型；
- 检索结果做带时间的缓存，同一个命题24小时以内直接命中缓存，不重新抓取；
- 证据段落切分和向量化提前到缓存阶段完成，查询时只做相似度计算。 三板斧下来，常规场景基本稳定在2到3秒，体感好了一个数量级。
6.2 隐私与本地化：一个离线走的版本
不是所有人都愿意把语音传到云端，所以我把整个流水线做了一份完全本地的变体：Whisper.cpp负责转写，Llama.cpp跑拆解和评估，本地SQLite里放了一份维基百科的子集加上我手工整理的科普文章库。检索不走搜索引擎，只走本地全文索引。精确度确实比在线版本差一些，但胜在完全离线、音频不离开设备，对隐私敏感型用户这是唯一能接受的形态。
6.3 边界感：哪些话我不帮人核查
这是我在项目收尾阶段想得最多的一件事。The Truth Machine不应该是一个什么都能裁断的"全知裁判"，它更适合做一个"给证据链让用户自己下判断"的工具。在我实际使用的过程中，最让我觉得舒服的反馈不是它给出了某个多漂亮的结论，而是它总能在结论下面附上几个来源链接、几段证据摘要，让我自己判断"这个来源值不值得信"。
它对我的最大价值其实是发现了"很多我以为稳的说法，其实证据链薄弱得很"。不管是为了在饭桌上多一个话题切入点，还是为了让自己的转发少一点拍脑袋，这个按一下说出声、松手出结论的小机器都帮了大忙。
)
