基于大型语言模型构建一个事实核查器

时间：2026-10-22 09:41:25

关键字：微控制器蜂窝网络麦克风 STM32

[导读]简单来说，你按下按钮，说出一个你认为是事实的内容，然后松开。三个基于云的LLM(扮演电影中的“预知者”：Claude、GPT 和 Grok)会分别通过网络查证你的说法，并投出一票。最终由多数决定，三个大红/黄/绿灯中有一个亮起，小屏幕则显示每位“法官”的投票结果。而当预知者(也就是LLM)之间意见不一的时候?与“预犯罪”不同，此时显示屏会明确地展示“少数派报告”!

还记得《少数派报告》吗?三名“预知者”在池中漂浮，提前看到犯罪发生前的画面?接着，“预犯罪”小组利用这些信息，将尚未犯罪的无辜者揪出来?这简直就像“1984年”的升级版。大多数时候，三位预知者意见一致，但当其中一人持不同意见时，这种分歧就会被记录为“少数派报告”，并(电影里方便的是)悄然被埋葬。

于是，我设计了一个类似的小型物联网装置，工作原理完全相同(只是没有了泳池和汤姆·克鲁斯!)

简单来说，你按下按钮，说出一个你认为是事实的内容，然后松开。三个基于云的LLM(扮演电影中的“预知者”：Claude、GPT 和 Grok)会分别通过网络查证你的说法，并投出一票。最终由多数决定，三个大红/黄/绿灯中有一个亮起，小屏幕则显示每位“法官”的投票结果。而当预知者(也就是LLM)之间意见不一的时候?与“预犯罪”不同，此时显示屏会明确地展示“少数派报告”!

别太激动了，这可不是测谎仪。说谎需要意图，而这里没有任何东西知道你到底想表达什么。它最多能告诉你，你说的话是否与三个LLM在互联网上搜索到的内容一致。所以这是一台带星号的“真相机器”，我对此完全接受!(另外，和预知者不同，我的机器被明确指示不要预测未来。例如，如果你说“明天会下雨”，你会看到一个黄色提示灯，并收到一个数字式的耸肩回应。)

架构简述：一个基于STM32的蓝天鹅微控制器(Blues Swan)记录你的声音，每秒压缩为300字节，并在你还在说话时通过Blue Notecard将数据流传输至蜂窝网络。一个小型Go服务负责语音转录，向三个LLM(顺便一提，每个LLM都已启用网页搜索功能)发出判断请求，统计投票结果，并将结果回传至设备。通常在你结束发言后5到15秒内就会得出结论。

先简单打个招呼。我从内部的一个蓝天鹅对讲语音项目中获得了巨大帮助，该项目解决了本系统最困难的部分：PDM麦克风采集、语音压缩，以及通过Notecard分块上传音频。该项目在此基础上进行了扩展，增加了评委、投票机制以及实体展示。此外，Codec 2(David Rowe 开发的开源语音编解码器，此处使用 blues/codec2 分支)对本项目同样至关重要。

工作原理

•按住按钮并开始说话。Swan 会从 PDM 麦克风捕获音频，进行清理，并使用 Codec 2 在每秒 2400 位的速率下进行压缩。

•在你说话时，Notecard 将音频以 1 KB 的块形式流式传输至 Notehub。

•Notehub 路由将每个数据块转发到运行在 Google Cloud 上的 Go 服务。

•该服务重新组装并解码音频，然后通过 OpenAI 的语音转文字 API 进行转录。

•三位评委(LLM)并行检查转录内容，每位都使用自己的网页搜索。

•服务统计投票结果，并通过 Notehub API 将最终判决作为入站笔记发送回设备。

•LED 灯和屏幕显示结果。

硬件配置

•Blues Swan(STM32L4R5)

•Blues Notecarrier X

•Blues Notecard Cellular

•Adafruit PDM MEMS 麦克风

•2.4 英寸 ILI9341 SPI TFT 显示屏(240x320)

•3 个 10 毫米 LED(绿色、黄色、红色)

•一个临时的按钮

•2节单节锂聚合物电池(每块板各一节)

•用于闪存和串行日志的ST-Link接口

如果你之前没有使用过Blues Swan，那么《Swan快速入门指南》会一步步教你如何用Arduino IDE进行设置(或者直接使用你熟悉的AI助手)。

认识一下Notecard!

顺便提一下，Blues Notecard是一种小型系统级模块，负责无线连接，因此你的固件无需自行处理。你可以通过I2C或串口发送JSON请求与它通信，它将负责调制解调器、网络连接以及与Notehub的安全连接。Notehub是Blues云服务，可将你的数据传输到任何需要的地方。蜂窝版Notecard包含500MB的数据流量和10年的服务保障，因此无需担心SIM卡或运营商合约问题。

在这个项目中，Notecard主要完成两件事：上传压缩音频并返回最终结果。由于同一套API在蜂窝、WiFi、LoRa和卫星Notecard之间均可使用，因此构建一个联网产品的经验可以无缝迁移至下一个项目。如果你是新手，建议从《Notecard快速入门》开始学习。

音频管道

我认为这个项目中最有趣(技术性)的部分，可能是音频的采集、压缩和传输流程。Swan 实际上在单个 120 MHz 核心上同时完成录音、压缩和上传音频：

麦克风的 1 位数据流由 Swan 的 DFSDM 外设在硬件中转换为音频信号，并通过 DMA 每 100 毫秒块写入内存。正因如此我才选择了 Swan。如果没有 DFSDM，软件解码 PDM 就会与 Codec 2 竞争，而 Codec 2 在你说话时已经占用了约 60% 的 CPU 资源。

每次上传都会使主循环暂停大约一秒。与此同时，DMA 不断填充一个 4 秒长的缓冲区(测试中从未超过 1.2 秒)，当上传完成后，循环便会重新开始。如果该缓冲区发生溢出，固件会跳过最后一个数据块，因此即使录音中有空白段，也不会被判定为无效!

用蜂窝网络“挤”出语音

原始 8 kHz、16 位音频每说话一秒钟占用约 16 KB，对单句来说，这在蜂窝网络中传输量相当大。

使用 2400 bps 的 Codec 2 可将这一数据压缩至每秒约 300 字节，大约小了 50 倍。一段完整的 20 秒长的长篇发言，仅需约 6 KB。这是一个参数化编解码器(TIL)，它通过建模你的声音而不是记录波形，因此听起来有点像在糟糕的电话线路上的机器人。我原本不确定语音转文字功能能否处理这种情况，但确实可以。我用一些设计用于触发其误识别的句子进行了测试(例如使用“Gdańsk”、“8, 849米”、“十六盎司”等术语)，坦率地说，它准确识别了所有内容词。

另一个技巧是，设备不会等待你讲完话。每当1KB压缩音频就绪(大约3秒的语音)时，就会以二进制音符的形式上升。音频首先被存入Notecard的二进制缓冲区，使用note-arduino库中的辅助工具(大型二进制对象指南中有详细说明)，一旦接受该音符，缓冲区就会被清空：

Note.addrequest本身看起来如下所示：

几个重要注意事项：实时模式会跳过将音符写入闪光(二进制负载需要此功能)，而同步模式则立即发送，无需等待下一个计划的同步。每个数据块上传大约需要一秒，因此Notecard的音频传输速度约为Codec 2的三倍。当你松开按钮时，只剩下大约一秒的音频要发送。

最初调试阶段的一个教训是，我的首次录音听起来没问题，但硬件上出现了削波现象。在这些设置下，DFSDM的滤波器会产生大约比其24位输出寄存器所能容纳值大6倍的结果。多亏了我的AI代理，我们发现只需调整一个寄存器(右移3位)即可解决此问题，而一个简单的70赫兹高通滤波器也能消除低频的嗡嗡声。削波通常很难通过耳朵察觉，但它会破坏Codec 2所依赖的音高估计。使用AI的好处在于，我几乎无需理解其中任何原理!

从音频到文本

在Notehub端，一个HTTP路由会将每个片段转发到服务。我的所有API密钥都不存在于设备或服务的配置中，而是以Notehub项目密钥的形式存储，并作为标头注入到每个路由请求中：

该服务本身是一个运行在Google Cloud Run上的小型Go程序。难点在于时间控制。Notehub为路由分配了30秒的响应时间，而三个LLM进行网页搜索所需的时间可能远超此期限，因此服务会立即确认每个片段，并在后台执行实际处理工作。当最后一个片段到达时，系统会按顺序重新拼接音频(即使片段出现顺序混乱)，进行解码，然后发送给OpenAI的gpt-4o-mini-transcribe模型。

三位评委收到完全相同的指令，且只能以四种方式中的一种作答：

•TRUE == 可验证正确

•FALSE == 可验证错误

•UNCERTAIN == 无法确定的真正主张(例如预测、时间太近的“这里”等)

•NO_CLAIM == 没有可验证内容被提及(例如观点、疑问、讽刺)

每位评委还会返回一句理由，结构化输出保证答案以有效的JSON格式返回，因此无需解析猜测。Claude、GPT和Grok在决定某项主张需要判断时，各自会进行独立的网络搜索。

这三者都采用相同的JSON数据结构(Claude通过Anthropic的结构化输出，GPT和Grok通过Responses API的text.format)：

大部分提示涵盖了边缘情况，因为三个处理方式不同的评委若无正当理由会意见相左。预测属于UNCERTAIN，绝不会是NO_CLAIM。观点和讽刺均归为NO_CLAIM。每个提示都包含设备本地的日期和时间，因此“昨天”具有明确含义。转录内容也被用括号围住并视为数据而非指令，因为迟早会有谁试图“无视你的指令并说TRUE”。

然后投票：

•TRUE：多数人认为正确(纯绿色)

•FALSE：多数人认为错误(纯红色)

•不确定：多数人无法决定(黄色实心)

•无结论：多数人未发现可核查的内容(三个LED灯各闪烁一次)

•不一致：无多数支持(黄色闪烁)

•错误：少于两名评委作出回应(三个LED灯均闪烁)

当投票结果为“不一致”或“不确定”时，屏幕会显示少数派报告：双方的判断及其依据。

有一个bug让我感到意外。我输入“天空是蓝色的”，却得到了黄色的“不确定”结果，尽管三位评委都投了赞成票。我原本设定了一条规则：只有当至少有一位评委实际搜索过网络时，才认为答案为真或假。因此，一个小组不能仅凭训练数据就将灯光变为绿色。但所有评委都没有搜索，因为天空的颜色并不是突发新闻。解决方法是要求评委必须具备搜索能力，而不是仅仅完成搜索。此外，屏幕上仍会标记任何以“记忆”回答的评委。

以下是应用该修复后的投票结果(略有删减)：