ทำไม AI Notetaker ของคุณถึงหยุดบันทึกเสียงกลางประชุม

วันที่ 2 กรกฎาคม GeekBye ปิดการบันทึกการประชุมด้วยตัวมันเอง แถวข้อมูลในฐานข้อมูลบอกทุกอย่าง: ended_reason = 'idle' ระยะเวลา 519 วินาที รายการทรานสคริปต์ 99 รายการ — รายการสุดท้ายถูกเขียนก่อนที่แอปจะตัดสินว่าไม่มีใครอยู่แค่ 2 วินาที

ผู้เข้าร่วมอีกฝ่ายกำลังอธิบายค้างอยู่กลางคัน บรรทัดสุดท้ายของทรานสคริปต์คือเศษประโยคจริงๆ: "...executes it or turns it on or so—"

และนี่ไม่ใช่ครั้งแรก เย็นวันก่อนหน้า อีกเซสชันหนึ่งก็จบลงแบบเดียวกัน สองการประชุม ถูกฆ่าด้วยฟีเจอร์ด้านความเสถียรของเราเอง นี่คือการวินิจฉัยและการแก้ไขที่ปล่อยไปใน GeekBye v2.0.9 — พร้อมบั๊กตัวที่สองที่น่ากลัวกว่า ซึ่งเราแก้ในรีลีสเดียวกัน

Timer เจตนาดีที่ได้ยินแค่เสียงคุณคนเดียว

idle auto-close มีอยู่ด้วยเหตุผลที่ดี คนลืมปิดการบันทึกทิ้งไว้ข้ามคืน แท็บประชุมที่เปิดค้างไว้ก็ปล่อยเสียงหยดติ๋งๆ ไปเรื่อยๆ ไม่มีวันจบ GeekBye จึงเฝ้าดูความไม่เคลื่อนไหว: หลังจาก 60 วินาทีที่ไม่มีกิจกรรมเสียงพูด มันจะแสดงข้อความถามเล็กๆ "Still recording?" (ยังบันทึกอยู่ไหม?) และอีก 30 วินาทีต่อมา ถ้าไม่มีใครตอบ มันจะจบเซสชัน — บันทึกทุกอย่างเก็บไว้อย่างสุภาพ

ข้อบกพร่องอยู่ที่คำคำเดียว: เสียงพูด นาฬิกากิจกรรมนับเฉพาะพลังงานเสียงจากไมโครโฟนที่ต่อเนื่องเท่านั้น นั่นเป็นการตัดสินใจออกแบบโดยเจตนา และไม่ใช่การตัดสินใจโง่ๆ ด้วย — การนับพลังงานเสียงระบบดิบๆ จะทำให้แท็บที่ mute แล้วแต่ยังมีเสียงดัง ปั๊มเซสชันที่ตายแล้วให้มีชีวิตต่อไปได้ไม่รู้จบ ซึ่งคือความล้มเหลวแบบที่ฟีเจอร์นี้เกิดมาเพื่อป้องกันพอดี ส่วนการประชุมที่คุณส่วนใหญ่นั่งฟัง ควรจะถูกครอบคลุมด้วยการตรวจจับหน้าต่างประชุมอยู่แล้ว

ยกเว้นว่าการตรวจจับการประชุมมองไม่เห็นทุกการประชุม แท็บเบราว์เซอร์ ไคลเอนต์แปลกๆ พรีเซนเทชันที่คุณนั่งดูอยู่ — ตรวจไม่เจอทั้งนั้น และในการประชุมที่ตรวจไม่เจอ ที่คุณนั่งฟังไป 90 วินาที — เรื่องปกติสุดๆ เวลาใครสักคนกำลังอธิบาย Databricks pipeline ของเขา — ในสายตาของนาฬิกา idle คุณแยกไม่ออกจากห้องว่างเปล่าเลย

ลองดูไทม์ไลน์ของเซสชันที่ถูกฆ่า: ทรานสคริปต์สุดท้ายจากไมโครโฟนของเรามาถึง 68 วินาทีก่อนจบ จากนั้นคือ 60 วินาทีที่อีกฝ่ายพูด (ถอดเสียงได้สมบูรณ์แบบ แต่นาฬิกาไม่สนใจ) ข้อความถามที่ไม่มีใครสังเกตเห็น การนับถอยหลัง 30 วินาที และการฆ่า — 2 วินาทีหลังคำพูดสุดท้ายของเขา

การแก้ไข: ทรานสคริปต์คือหลักฐานว่ายังมีชีวิต

การแก้ไขนี้เกือบจะน่าอายเมื่อมองย้อนกลับไป: ทรานสคริปต์ที่เข้ามาคือหลักฐานที่หนักแน่นที่สุดเท่าที่จะเป็นไปได้ว่าเซสชันไม่ได้ idle ไม่สำคัญว่าใครเป็นคนพูด โมเดลเสียงพูดเพิ่งรู้จำคำออกมาได้ — นั่นแหละคือการประชุม

ดังนั้น v2.0.9 จึงประทับเวลานาฬิกากิจกรรมทุกครั้งที่มีทรานสคริปต์มาถึง จากฝั่งไหนก็ตาม ส่วนพลังงานเสียงระบบดิบๆ ยังคงไม่นับ — เพลง เสียงรอสาย และเสียงหึ่งของแอร์ ยังคงทำให้เซสชันที่ตายแล้วเป็นอมตะไม่ได้ และเพดานเวลาบันทึกสูงสุดยังคงเป็นด่านสุดท้ายคอยกันทุกอย่างอยู่ มีเพียงเสียงพูดที่ถูกรู้จำเท่านั้นที่ทำให้เซสชันมีชีวิตต่อ ซึ่งคือเส้นแบ่งที่ถูกต้องเป๊ะๆ

รายละเอียดหนึ่งจาก code review ที่ควรส่งต่อ: เวอร์ชันแรกของการแก้ไขประทับเวลานาฬิกาอยู่ในเส้นทาง speaker-attribution — ซึ่งทรานสคริปต์บางส่วนสามารถข้ามได้อย่างถูกต้อง review จับได้ว่าการเปลี่ยนแปลงในอนาคตอาจนำบั๊กกลับมาแบบเงียบๆ กับทรานสคริปต์ชุดที่สำคัญที่สุดพอดี (ของผู้พูดอีกฝ่าย) ตอนนี้การประทับเวลาเป็นแบบไม่มีเงื่อนไข อยู่ก่อนการแตกแขนงใดๆ พร้อมเทสต์ที่จะ fail ถ้าใครย้ายมัน

รีลีสเดียวกันแก้อะไรบางอย่างที่น่ากลัวกว่า

ระหว่างทดสอบการแก้ไขเหล่านี้ เราเจอบั๊กอีกตัวแบบเจ็บจริง: crash ในโปรเซสอินเทอร์เฟซทำให้เดสก์ท็อปทั้งหมดคลิกอะไรไม่ได้เลย

overlay ของ GeekBye คือหน้าต่างโปร่งใสแบบ always-on-top ที่ครอบทั้งหน้าจอของคุณ โดยค่าเริ่มต้นมันเป็นแบบ click-through อินเทอร์เฟซจะสลับให้มันรับ interaction ตอนคุณกำลังใช้พาเนลอยู่ การสลับเหล่านั้นมาจากโปรเซสอินเทอร์เฟซ — ดังนั้นเมื่อโปรเซสนั้น crash ตอนพาเนลเปิดอยู่ หน้าต่างล่องหนก็ค้างอยู่ในโหมด interactive โดยไม่มี UI ที่มีชีวิตอยู่ข้างหลัง ทุกคลิกบนเดสก์ท็อปของคุณตกลงบนบานกระจกล่องหนที่ตายแล้ว ทางหนีเดียวคือ force-quit แอป

crash handler ของ v2.0.9 ตอนนี้คืนค่า click-through ทันทีและ reload อินเทอร์เฟซ — โดยจำกัดที่สาม reload ต่อนาที เพื่อไม่ให้ crash-loop หมุนไปตลอดกาล (เกินเพดานแล้ว แอปจะเลิกพยายาม reload แต่เดสก์ท็อปของคุณยังใช้งานได้ ซึ่งคือส่วนที่สำคัญจริงๆ) code review ทำให้เรื่องนี้คมขึ้นเช่นกัน: การกู้คืนถูก scope ไว้เฉพาะหน้าต่าง overlay เพราะการเหมาใส่ click-through ให้หน้าต่างปกติที่ crash — เช่น ไดอะล็อกอัปเดต — จะสร้างการล็อกแบบตรงกันข้ามขึ้นมาแทน

คุณตรวจสอบการแก้ไขนี้ด้วยตัวเองได้แบบโหดๆ เลย: เปิดพาเนลของ GeekBye แล้ว force-kill โปรเซส "GeekBye Helper (Renderer)" ใน Activity Monitor แล้วดูแอปกู้เดสก์ท็อปของคุณกลับมาภายในหนึ่งวินาที

บั๊กคู่นี้สอนอะไรเรา

1. ทุก proxy ของคำถาม "ผู้ใช้ยังอยู่ไหม" ล้มเหลวที่ไหนสักแห่งเสมอ พลังงานไมค์ล้มเหลวกับคนที่นั่งฟัง การตรวจจับหน้าต่างล้มเหลวกับเบราว์เซอร์ ทรานสคริปต์ที่ถูกรู้จำล้มเหลวกับ... ยังไม่มีอะไรที่เราเจอเลย เพราะมันไม่ใช่ proxy — มันคือตัวโปรดักต์เอง
2. อะไรก็ตามที่ขับเคลื่อนโดย renderer ต้องมีแผนรับมือกรณี crash ถ้าโปรเซส UI ที่ตายแล้วสามารถทิ้ง state ระดับ OS ไว้ข้างหลังได้ (mouse capture, always-on-top, content protection) โปรเซสหลักต้องเป็นเจ้าของการรีเซ็ต
3. การเป็นผู้ใช้ตัวยงที่สุดของตัวเองคือกลยุทธ์การหาบั๊ก บั๊กทั้งคู่เล่นงานเราในการประชุมจริง ก่อนที่ลูกค้าจะสังเกตเห็นมากกว่าหยิบมือ คอลัมน์ ended_reason ที่เราเพิ่มไว้เพื่อ observability เมื่อหลายเดือนก่อน คือสิ่งที่ทำให้การวินิจฉัยเป็นแค่ query ฐานข้อมูล ไม่ใช่การเดา

การแก้ไขทั้งสองเดินทางจากการวินิจฉัยไปถึงรีลีสที่ notarize แล้วและปล่อยจริงภายในหนึ่งวัน แต่ละอันมาพร้อม PR ที่ผ่านการ review และ regression tests ถ้าคุณใช้ GeekBye v2 อยู่ คุณได้รับมันไปแล้วตั้งแต่ v2.0.9 ผ่าน auto-update

สำหรับเรื่องราวที่เหลือของรีลีสนี้ อ่านเพื่อนบ้านในซีรีส์ ทำไม AI ถอดเสียงถึงฟังศัพท์เทคนิคผิด (v2.0.11) งานปูพื้นด้านความเสถียรในทำไม AI notetaker ของคุณถึงหยุดทำงานบน Wi-Fi ห่วยๆ และวิธีที่ overlay ยังคงล่องหนระหว่างการแชร์หน้าจอโดยไม่ขโมยคลิกของคุณ