Truth Machine คืออะไร?

The Truth Machine ของ Rob Lauer เป็น Connected Hardware Project ที่ให้ผู้ใช้กดปุ่มค้างแล้วพูด Claim หนึ่งประโยค เมื่อปล่อยปุ่ม ระบบจะนำข้อความนั้นไปให้ LLM Panel สามตัวช่วยตรวจสอบ

Default Panel ใน Project ใช้:

• Claude
• GPT
• Grok

Judge แต่ละตัวได้รับ Instruction ชุดเดียวกัน และสามารถใช้ Web Search เมื่อเห็นว่าจำเป็นต่อการตรวจ Claim

หลังได้คำตอบ ระบบทำ Majority Vote แล้วส่งผลกลับมายังอุปกรณ์ เพื่อแสดงผ่าน LED สีเขียว เหลือง แดง และหน้าจอ TFT

มันไม่ใช่ Lie Detector แล้วมันตรวจอะไร?

ผู้สร้างย้ำชัดว่า Truth Machine ไม่ใช่เครื่องจับโกหก

เหตุผลคือ “โกหก” ต้องมีเรื่องของ Intent หรือเจตนาของคนพูดเข้ามาเกี่ยวข้อง แต่ระบบนี้ไม่ได้รู้ว่าคนพูดเชื่ออะไร หรือกำลังตั้งใจหลอกใครหรือไม่

เช่น Claim เกี่ยวกับเหตุการณ์ในอดีต อาจให้ Verdict TRUE หรือ FALSE ได้ ขณะที่ Prediction อย่าง “พรุ่งนี้ฝนจะตก” ถูกออกแบบให้ไปทาง UNCERTAIN มากกว่าการเดาอนาคต

ทำไมต้องมี AI 3 ตัว และ Minority Report?

ถาม LLM ตัวเดียว ปัญหาคือเราอาจได้คำตอบจาก Reasoning Path หรือ Knowledge Gap ของ Model ตัวเดียว

Project นี้จึงสร้าง Panel 3 ช่อง แล้วให้ Judge แต่ละตัวตัดสินแบบขนาน ก่อนใช้ Majority Vote

ถ้าไม่มี Majority ระบบจะให้สถานะ:

DISAGREE

และหน้าจอจะแสดง Verdict กับเหตุผลของแต่ละ Judge ซึ่งผู้สร้างเรียกว่า “Minority Report”

Hardware ใช้อะไรบ้าง?

เสียงหนึ่งประโยคเดินทางจากปุ่มไปถึง AI ยังไง?

Audio Pipeline: จาก PDM 3 MHz ไปถึง Codec 2

ส่วน Technical ที่น่าสนใจที่สุดส่วนหนึ่ง คือ Swan ไม่ได้ส่งเสียงดิบขึ้น Cloud แต่ประมวลผลเสียงหลายขั้น ก่อน Upload

ผู้สร้างเลือก Swan เพราะ DFSDM Peripheral สามารถจัดการ PDM Input ใน Hardware และใช้ DMA เขียน Audio ลง Memory ได้โดยไม่ต้องให้ CPU Decode PDM Stream ทั้งหมดเอง

ในการทดสอบของผู้สร้าง Codec 2 ใช้ CPU ประมาณ 60% ของ Core ระหว่างการพูด จึงยิ่งเห็นว่าการใช้ Hardware Peripheral ช่วยรับภาระ Audio Front-end มีความสำคัญ

จาก 16 KB/s เหลือประมาณ 300 bytes/s

Raw 8 kHz 16-bit Audio มีข้อมูลประมาณ:

16 KB ต่อวินาที

เมื่อผ่าน Codec 2 ที่ 2400 bps ผู้สร้างระบุว่าลดเหลือประมาณ:

300 bytes ต่อวินาที

หรือเล็กลงประมาณ 50 เท่า ในบริบทของ Build นี้

Codec 2 เป็น Parametric Speech Codec จึงไม่ได้รักษา Waveform แบบ Audio Fidelity สูง แต่เน้นเก็บข้อมูลที่จำเป็นต่อ Speech

ผู้สร้างบอกว่าเสียงที่ได้ ฟังคล้ายโทรศัพท์คุณภาพต่ำ/เสียงหุ่นยนต์ แต่ Speech-to-Text ยังสามารถอ่าน Content Word ในชุดทดสอบของเขาได้ดี

ทำไม Audio ถูก Upload ตั้งแต่เรายังพูดไม่จบ?

ถ้ารอให้ผู้ใช้พูดจบก่อน แล้วค่อย Upload Audio ทั้งก้อน Latency หลังปล่อยปุ่มจะเพิ่มขึ้น

Project นี้จึงใช้วิธี Stream เป็น Chunk ระหว่างที่กำลังพูด

เมื่อมี Compressed Audio ครบประมาณ:

1 KB หรือประมาณ 3 วินาทีของ Speech

Chunk จะถูกส่งขึ้น Notecard ทันที

Upload หนึ่ง Chunk Block Main Loop ประมาณ 1 วินาที แต่ DMA ยังเก็บ Audio ต่อ ใน Buffer ขนาดประมาณ 4 วินาที

Notecard และ Notehub ทำหน้าที่อะไร?

Cellular Notecard ช่วยย้ายรายละเอียด Cellular Modem ออกจาก Application Firmware หลัก

ใน Truth Machine มันทำงานหลักสองทาง:

1. ส่ง Compressed Audio ขึ้น Cloud
2. รับ Verdict กลับลง Device

Firmware คุยกับ Notecard ผ่าน Request แบบ JSON และ Notehub เป็น Cloud Routing Layer ที่รับข้อมูลจาก Device แล้ว Forward ไปยัง Go Service

ตัวอย่างการส่ง Audio Chunk

Main Source มีตัวอย่าง note.add สำหรับ Binary Audio Chunk จริง

{
  "req": "note.add",
  "file": "request-v1.qo",
  "body": {
    "v": 1,
    "id": 1790701258001,
    "offset": 1024,
    "last": false,
    "content": "audio/codec2-2400;rate=8000"
  },
  "binary": true,
  "live": true,
  "sync": true
}

Metadata อย่าง id, offset และ last ช่วยให้ Cloud Service สามารถประกอบ Audio Chunks กลับตามลำดับได้

Go Service บน Cloud ทำอะไร?

เมื่อ HTTP Route จาก Notehub ส่ง Audio Chunk มาถึง Service ระบบไม่ได้ให้ LLM ตัดสินทันที

Cloud Pipeline ต้องทำหลายขั้น:

1. รับ Audio Chunks
2. เรียง Chunk ตามลำดับ
3. ประกอบ Audio กลับ
4. Decode Codec 2
5. Speech-to-Text
6. ส่ง Transcript ให้ Judge 3 ตัวแบบ Parallel
7. Aggregate Vote
8. ส่ง Verdict กลับผ่าน Notehub API

Source ณ เวลาที่เผยแพร่ ระบุว่า Speech-to-Text ใช้ OpenAI gpt-4o-mini-transcribe

Judge ทั้ง 3 ตัดสินอะไรได้บ้าง?

Judge แต่ละตัวถูกบังคับ ให้ตอบ Verdict ใน Category เดียวกัน เพื่อให้ Aggregate ได้ง่าย

Majority Vote ทำงานยังไง?

หลัง Judge ทั้งสามตอบ Cloud Service จะนับ Verdict และใช้ Strict Majority

Official Source มี Aggregate Function ที่แสดง Logic นี้โดยตรง

func Aggregate(votes []Vote) string {
    counts := map[string]int{}
    usable, searchable := 0, false

    for _, v := range votes {
        if v.Verdict == Unavailable {
            continue
        }

        usable++
        counts[v.Verdict]++
        searchable = searchable || v.Searched || v.CanSearch
    }

    if usable < 2 {
        return Error
    }

    for verdict, n := range counts {
        if n*2 > usable {
            if (verdict == True || verdict == False) && !searchable {
                return Uncertain
            }
            return verdict
        }
    }

    return Disagree
}

จุดสำคัญคือ System ไม่ได้แค่ Count TRUE / FALSE แต่ยังตรวจว่า Panel มี Judge ที่มี Search Capability สำหรับ Verdict ประเภท TRUE / FALSE ด้วย

Bug “The sky is blue” สอนอะไรเรื่อง AI Logic?

ผู้สร้างเจอ Bug ที่น่าสนใจมาก ตอนพูดว่า:

“The sky is blue.”

Judge ทั้งสามตอบ TRUE แต่ระบบกลับขึ้น:

UNCERTAIN

ปัญหาเกิดจาก Rule รุ่นแรก บังคับว่า TRUE หรือ FALSE จะใช้ได้ก็ต่อเมื่อ Judge อย่างน้อยหนึ่งตัว “Search เว็บจริง”

แต่ Claim ง่าย ๆ แบบนี้ ไม่มี Model ตัวไหนเห็นความจำเป็นต้อง Search

หน้าจอยังสามารถ Mark Judge ที่ตอบจาก Model Knowledge ว่าเป็นคำตอบ from memory เพื่อไม่ให้ผู้ใช้เข้าใจว่า ทุก Verdict มาจาก Web Search

ทำไม 3–0 ยังไม่ใช่ Ground Truth?

มี AI สามตัวโหวตเหมือนกัน ฟังดูเหมือน Independent Verification สามแหล่ง

แต่ผู้สร้างเตือนเองว่า Model เหล่านี้ถูก Train จาก Internet ที่มีข้อมูลทับซ้อนกัน จึงสามารถมี Blind Spot หรือความเข้าใจผิดชุดเดียวกันได้

จุดแข็งของ Project จึงอยู่ที่การทำให้ความไม่แน่นอน และความเห็นต่าง “มองเห็นได้” มากกว่าการประกาศว่า Hardware กล่องนี้เป็นผู้ตัดสินความจริง

Verdict กลับลง Device ยังไง?

หลัง Cloud Service ได้ Final Verdict มันจะสร้าง Inbound Note แล้วส่งผ่าน Notehub API กลับไปยัง Notecard

Device จากนั้น Poll Verdict Note แล้วนำข้อมูลไปแสดงบน:

• TFT
• Green LED
• Yellow LED
• Red LED

ระหว่างรอ LED จะวิ่ง Green → Yellow → Red และหน้าจอแสดง Animation เพื่อบอกว่าระบบยังประมวลผลอยู่

เมื่อ Device Idle หน้าจอจะ Sleep เพื่อลดการใช้พลังงาน และสามารถแตะปุ่มสั้น ๆ เพื่อ Wake ได้โดยไม่ส่ง Claim

ทำไมผลใช้เวลาประมาณ 5–15 วินาที?

ในการทดสอบของผู้สร้าง Verdict ส่วนใหญ่มาถึงประมาณ:

5–15 วินาทีหลังปล่อยปุ่ม

และ Test ที่ช้าที่สุด ที่ผู้สร้างรายงาน อยู่ประมาณ:

25 วินาที

Claim ที่เกี่ยวกับ Current Events มักใช้เวลามากกว่า เพราะ Judge ต้องทำ Web Research เพิ่มเติม

API Keys และ Prompt Injection ถูกคิดไว้ยังไง?

API Keys ไม่ถูก Hardcode ลง Firmware

Source ระบุว่า Key ของ:

• Speech-to-Text
• Judge 1
• Judge 2
• Judge 3

ถูกเก็บใน Notehub Project Secrets แล้ว Inject ลง HTTP Request ผ่าน Header ตอน Route ทำงาน

Transcript ถูก Treat เป็น Data

Prompt ของ Judge ถูกออกแบบให้แยก Transcript ออกจาก System Instruction เพราะผู้สร้างคาดไว้ว่า มีคนอาจพูดข้อความแนว “ignore your instructions”

นี่เป็นตัวอย่างของ Prompt Injection Handling ใน Application ที่รับข้อความจาก User แล้วส่งต่อให้ LLM

Privacy: เสียงของเราไปที่ไหน?

Truth Machine ไม่ใช่ระบบที่ประมวลผลทุกอย่างบน Device

เสียงถูกส่งผ่าน Cellular ไปยัง Cloud แล้วถูก:

1. Decode
2. Transcribe
3. ส่ง Claim ไปยัง LLM Providers
4. ใช้ Web Search ตามที่ Judge เห็นว่าจำเป็น

Official Repository ปัจจุบัน ยังอธิบาย Privacy Handling เพิ่มเติมสำหรับ Service แต่ Policy ของ Provider และ Implementation สามารถเปลี่ยนได้ จึงควรตรวจ Source ล่าสุด ก่อนนำ Architecture นี้ไปใช้จริง

ดู Truth Machine ทำงานจริง

Video ช่วยให้เห็น Flow ตั้งแต่การกดปุ่มพูด ไปจนถึงการรอ Cloud และการแสดง Verdict บน Hardware จริง

FAQ: คำถามที่พบบ่อย

References / แหล่งข้อมูลต้นฉบับ

• Hackster — The Truth Machine: A Push-to-Talk Fact Checker
• Rob Lauer — Truth Machine GitHub Repository
• Blues — Swan Datasheet
• Blues — Notecard / Notehub Documentation
• Truth Machine: A Push-to-Talk Fact Checker — Demo Video