วิธีสร้าง Voice Agent ด้วย AI (คู่มือฉบับสมบูรณ์)

นี่คือความจริงที่ไม่มีใครบอกผู้สร้าง AI เอเจนท์เสียงไม่จำเป็นต้องใช้

โมเดลที่ดีที่สุด สิ่งที่พวกเขาต้องการคือ

TLDR; ถ้าคุณรู้สึกว่าการอ่านน่าเบื่อ หรือสมาธิคุณสั้นลง คุณสามารถใช้ไฟล์ skill ที่ฉันสร้างขึ้นเพื่อรับบทความทั้งฉบับและวางลงในเอเจนท์ของคุณ ➡️https://github.com/codejunkie99/voice-agent-builder

สิ่งที่คุณต้องสร้างคือ:

• pipeline แบบ real-time ที่มี latency budget จริง
• ห้าองค์ประกอบที่ต่อกันในลำดับที่ถูกต้อง
• การ grounding ที่แข็งแกร่งพอที่จะทำให้โมเดลซื่อสัตย์
• กระบวนการทบทวนรายสัปดาห์ที่เสริมประสิทธิภาพแบบทบต้น

OpenAI เปิดตัว GPT-Realtime-2 เมื่อวันที่ 7 พฤษภาคม 2026 Salesforce AI Research ตีพิมพ์บทความ VoiceAgentRAG ในวันที่ 1 มีนาคม สัปดาห์เดียวกับที่ Deepgram Flux ย้ายจาก beta สู่ GA ชิ้นส่วนต่างๆ ไม่ใช่ปัญหาอีกต่อไป

สิ่งที่ยังคงเป็นปัญหาคือวิธีการต่อชิ้นส่วนเหล่านั้น และสิ่งที่คุณเขียนให้เอเจนท์พูด

ฉันใช้เวลาสามเดือนที่ผ่านมาสร้าง voice agent ที่รับโทรศัพท์ได้จริง ฉันจะไม่แสร้งทำเป็นว่ามันราบรื่นเลย

• การสร้างครั้งแรกฟังดูเหมือนตู้ kiosk ฉันทิ้งมันภายในสองวัน
• การสร้างครั้งที่สอง "จอง" การนัดหมายปลอมสี่ครั้งในชั่วโมงแรกก่อนที่ฉันจะสังเกตเห็น
• การสร้างครั้งที่สามรั่วหน่วยความจำเพราะฉันลืมล้าง context cache หลังจาก background extractor เขียนข้อเท็จจริงใหม่
• กว่าจะมีอะไรทำงานได้ ระบบก็เป็นการเขียนใหม่ครั้งที่สี่

เวอร์ชันที่ฉันจะปกป้องในตอนนี้มีคุณสมบัติเล็กๆ น้อยๆ ที่ฉันจะอธิบายในอีก 6,000 คำถัดไป

• pipeline มีงานเดียวภายในงบประมาณเดียว ห้าองค์ประกอบ, ครบวงจรต่ำกว่า 700ms, ไม่มีข้อยกเว้น
• ความรู้อยู่ในเอกสารของคุณและถูกดึงข้อมูลด้วย dual-agent cache ไม่ใช่ดึงออกจากหัวของโมเดล
• การออกแบบบทสนทนาคือวินัยของการเขียนเพื่อหู ไม่ใช่ตา ทีมส่วนใหญ่มองว่านี่เป็นเรื่องของความสวยงาม มันไม่ใช่
• ทุกเทิร์นจะเขียน log ที่มีโครงสร้างซึ่งฉันสามารถเล่นซ้ำกับ config ปัจจุบันได้ 90 วันต่อมา

บทความนี้คือสิ่งที่ 90 วันนั้นสอนฉันจริงๆ รวมถึงสองหรือสามสิ่งที่ฉันจะเดิมพันเป็นอันดับแรกถ้าฉันเริ่มต้นใหม่วันนี้🔽🔽

voice agent จริงๆ แล้วคืออะไร

voice agent ไม่ใช่ chatbot ที่มีไมโครโฟนต่อพ่วง มันไม่ใช่ TTS wrapper รอบ text API

มันคือระบบเสียงแบบ real-time ที่ถูกจำกัดด้วย latency ห้าองค์ประกอบประสานงานภายในกรอบเวลา 300 ถึง 800 มิลลิวินาที

Pipeline ตามลำดับเหตุการณ์ที่เกิดขึ้นจริง:

1. ผู้ใช้พูด
2. เสียงถูกบันทึก
3. STT แบบสตรีมมิ่งถอดความทีละคำ ในขณะที่บุคคลนั้นยังพูดอยู่
4. เอเจนท์อ่าน transcript และดึงความรู้ที่เกี่ยวข้องจากเอกสารของคุณ
5. LLM สร้างคำตอบ
6. TTS พูดคำตอบออกมาดังๆ
7. ผู้ใช้ได้ยิน

ทุก ๆ ลูกศรเหล่านั้นคือองค์ประกอบที่คุณสามารถเลือก ปรับแต่ง และสลับเปลี่ยนได้

ฉันลองสร้างด้วยวิธี chatbot ก่อน STT เสร็จ ส่งไปที่ LLM รอคำตอบเต็ม ส่งไปที่ TTS รอเสียงเต็ม แล้วเล่น

มันรู้สึกแย่มาก เหมือนคุยกับตู้ kiosk ภายในสองวันฉันลบมันทิ้ง

เหตุผลที่มันรู้สึกแย่ไม่ใช่เพราะตัวเลข latency แย่ มันใช้ได้บนกระดาษ เหตุผลคือมนุษย์ไม่ได้สนทนากันเป็นเทิร์น พวกเขาสนทนากันเป็นกระแสที่ซ้อนทับกัน

• เอเจนท์ต้องเริ่มคิดคำตอบในขณะที่ผู้ใช้ยังพูดประโยคไม่จบ
• TTS ต้องเริ่มพูดก่อนที่ LLM จะเขียนเสร็จ
• STT ต้องฟังต่อไปในขณะที่เอเจนท์กำลังพูด เพื่อที่จะรู้ว่าเมื่อไหร่ควรเงียบ

voice agent ที่ถูกขัดจังหวะไม่ได้ไม่ใช่ voice agent มันคือเครื่องตอบรับอัตโนมัติ

สามสถาปัตยกรรม

มีเพียงสามแบบเท่านั้น เลือกตามสิ่งที่คุณต้องการควบคุม

Chained pipeline

• บริการ STT, LLM, TTS แยกกันต่อเข้าด้วยกัน
• สามโมเดลอิสระ แต่ละตัวเชี่ยวชาญในงานของตัวเอง
• ข้อความไหลระหว่างกัน
• Latency อยู่ที่ประมาณ 600 ถึง 700ms บนแพลตฟอร์มที่มีการจัดการที่ดี
• ควบคุมได้มากที่สุด, แก้ไขจุดบกพร่องได้มากที่สุด, อัปเกรดทีละเลเยอร์ได้ง่ายที่สุด

Half-cascade

• เสียงถูกส่งตรงไปยัง multimodal model ที่ได้ยินเสียง ไม่ใช่ transcript
• จับความหงุดหงิดในน้ำเสียง, คำถามที่บอกเป็นนัยโดยน้ำเสียงที่สูงขึ้น, การเปลี่ยนภาษากลางประโยค
• เอาต์พุตยังคงส่งผ่าน TTS ที่เชี่ยวชาญเพื่อควบคุมเสียง
• Latency ลดลงเหลือ 300 ถึง 500ms

Native speech-to-speech

• โมเดลเดียว, เสียงเข้า, เสียงออก
• ไม่มีเลเยอร์การถอดความ, ไม่มีการส่งต่อข้อความ
• ทุกแล็บใหญ่ส่งมอบโมเดลเสียงแบบ native ในปี 2026
• Latency ลดลงเหลือ 200 ถึง 300ms ต่ำกว่าเกณฑ์ที่ผู้โทรจะสังเกตเห็นว่ากำลังพูดกับ AI

จะเริ่มต้นด้วยแบบไหน

1. เริ่มต้นด้วย chained pipeline เครื่องมือที่ดีที่สุดมีอยู่สำหรับมัน ย้ายไป speech-to-speech เมื่อคุณได้พิสูจน์ผลิตภัณฑ์ของคุณบน pipeline และต้องการการปรับปรุง latency แบบก้าวกระโดด
2. ฉันลอง speech-to-speech ก่อนสำหรับทุกอย่าง มันยอดเยี่ยมสำหรับขั้นตอนการจอง
3. มันพังตรงแบบฟอร์มรับข้อมูล 12 ขั้นตอน เพราะโมเดลเดี่ยวไม่สามารถเก็บ state machine ไว้ในหัวได้โดยไม่มี context บวมเมื่อถึงเทิร์นที่เก้า
4. ฉันย้ายอันนั้นไปยัง chained pipeline ที่มีเลเยอร์ state machine จริง และอัตราความสำเร็จพุ่งจาก 61% เป็น 89% ภายในสามวัน
5. การกำหนดขอบเขตเครื่องมือตามแต่ละ state คือการแก้ไขทั้งหมด

ห้าองค์ประกอบที่คุณต้องต่อ

chained pipeline ทุกอันมีองค์ประกอบเดียวกันห้าอย่าง ห้าภารกิจที่ต้องทำให้สำเร็จก่อนที่เอเจนท์ของคุณจะรับสายแรก

หู (Streaming STT)

โมเดล STT แปลงเสียงที่เข้ามาเป็นข้อความแบบ real-time ทีละคำ ในขณะที่บุคคลนั้นยังพูดอยู่ นี่คือองค์ประกอบที่สำคัญที่สุดใน stack ของคุณ ข้อผิดพลาดในการถอดความที่นี่จะส่งผลกระทบต่อทุกอย่างที่ตามมา

สิ่งที่ควรมองหาในปี 2026:

• ความแม่นยำแบบสตรีมมิ่ง แม่นยำในขณะที่บุคคลนั้นพูด ไม่ใช่แค่หลังจากพูดจบ
• Word Error Rate 6 ถึง 8% บนเสียง production จริงถือว่าดี เกิน 12% จะทำให้ผู้ใช้หงุดหงิดทุกๆ สายที่สาม
• การตรวจจับการจบเทิร์นในตัว การอัปเกรด UX ที่ใหญ่ที่สุดเพียงอย่างเดียวของปี 2026

ทำไมการตรวจจับการจบเทิร์นถึงสำคัญ:

• STT ทั่วไปคืน transcript มันไม่ได้บอกคุณว่าผู้พูดพูดจบหรือยัง
• ถ้าไม่มีมัน เอเจนท์ของคุณจะขัดจังหวะกลางประโยคหรือรออย่าง awkward สองวินาที
• โมเดล STT แบบสตรีมมิ่งรุ่นปี 2026 มาพร้อมกับการตรวจจับการจบเทิร์นภายในเครือข่ายเดียวกับที่ผลิต transcript
• โมเดลจะปล่อยสัญญาณ turn-complete เมื่อมันตัดสินใจว่าผู้พูดพูดจบแล้ว
• สัญญาณใช้บริบทเชิงความหมาย ไม่ใช่แค่ความเงียบของเสียง มันจับการพูดค่อยๆ เบาลงและไม่สนใจการหยุดหายใจ
• เปลี่ยนไปใช้สิ่งนี้ถ้าผู้ให้บริการของคุณมีให้ การหยุดก่อนที่เอเจนท์จะเริ่มพูดจะลดลง 200 ถึง 400ms ในทุกเทิร์น

สมอง (LLM)

LLM อ่าน transcript, ประวัติการสนทนา, ความรู้ที่ดึงมา, และตัดสินใจว่าจะพูดอะไร นอกจากนี้ยังตัดสินใจการกระทำ ไม่ใช่แค่คำพูด

กฎเฉพาะสำหรับเสียง:

• ใช้โมเดลเล็กที่รวดเร็ว ไม่ใช่รุ่น flagship โมเดล reasoning ชั้นนำใช้เวลา 1500ms ในการสร้างคำแรก นั่นคือความเงียบที่เป็นอันตราย โมเดลที่เล็กกว่าในตระกูลเดียวกันมักจะชนะในเทิร์นเสียง
• เลื่อนไปใช้โมเดลใหญ่เฉพาะสำหรับการเรียกเครื่องมือที่ซับซ้อนซึ่งต้องการการวางแผนจริงเท่านั้น
• จำกัด system prompt ที่ 800 โทเค็น มันโหลดซ้ำทุกเทิร์น prompt ขนาด 4000 โทเค็นเพิ่ม latency ให้กับทุกข้อความ

Function calling ในภาษาที่เข้าใจง่าย:

• คุณกำหนดแต่ละฟังก์ชันด้วยคำอธิบายว่ามันทำอะไรและต้องการข้อมูลอะไร
• LLM อ่านคำอธิบายและตัดสินใจว่าจะเรียกใช้เมื่อใดตามสถานะการสนทนา
• ไม่มี conditional logic tree LLM จับคู่ความตั้งใจกับฟังก์ชันจากภาษาธรรมชาติ

ความล้มเหลวในการผลิตที่พบบ่อยที่สุดกับ function calling ไม่ใช่สิ่งที่คุณคาดหวัง:

• LLM ไม่แสดงข้อผิดพลาดเมื่อไม่สามารถเรียกฟังก์ชันได้ มันจะเล่าสิ่งที่กำลังทำแทน
• "ฉันยืนยันการจองของคุณแล้ว" ไม่มีอะไรถูกเรียก ผู้ใช้คิดว่าพวกเขาจองแล้ว แต่ไม่ได้จอง
• วิธีแก้ไขคือกำหนดขอบเขตเครื่องมือตามสถานะปัจจุบัน สถานะ "เก็บชื่อ" ต้องไม่เปิดเผย book_appointment สถานะ "ยืนยันรายละเอียด" ต้องไม่เปิดเผย check_availability
• state machine คือราวกันตก ไม่ใช่ system prompt

ความรู้ (RAG)

RAG คือกลไกที่ช่วยให้เอเจนท์ของคุณตอบคำถามจากเอกสารของคุณแทนที่จะเป็นข้อมูลฝึกอบรมของโมเดล

ทำไมคุณถึงข้ามสิ่งนี้ไม่ได้:

• LLM ได้รับการฝึกบนอินเทอร์เน็ตสาธารณะจนถึงวันที่ถูกตัด
• พวกเขารู้มากเกี่ยวกับโลก พวกเขาไม่รู้อะไรเฉพาะเกี่ยวกับผลิตภัณฑ์ ราคา นโยบาย ลูกค้าของคุณ
• หากไม่มี RAG เอเจนท์ที่ถูกถามว่า "มีอะไรในแผนองค์กร?" จะสร้างภาพหลอนอย่างมั่นใจ
• เมื่อมี RAG มันจะดึงคำตอบจริงจากเอกสารประกอบของคุณก่อนตอบ

กลไกพื้นฐาน:

• ผู้ใช้ถามคำถาม
• ระบบทำการฝังข้อความค้นหา
• ฐานข้อมูลเวกเตอร์คืนส่วนเอกสารที่เกี่ยวข้องมากที่สุด
• ส่วนต่างๆ จะถูกฉีดเข้าไปในบริบทของ LLM
• LLM ได้รับคำสั่งให้ตอบจากบริบทนั้นเท่านั้น

ความท้าทายเฉพาะของเสียง:

• การค้นหาฐานข้อมูลเวกเตอร์ทั่วไปเพิ่ม 50 ถึง 300ms ให้กับ pipeline
• เมื่อรวมกับ STT, LLM, และ TTS จะทำให้งบประมาณ latency ของคุณหมด
• วิธีแก้ไขคือรูปแบบ dual-agent cache ทั้งหัวข้อด้านล่างนี้

ปาก (TTS)

TTS แปลงข้อความเป็นเสียงพูด ฟังดูง่าย แต่จริงๆ แล้วเป็นปัจจัยที่สร้างความแตกต่างอย่างมากในการรับรู้คุณภาพ

สิ่งที่สำคัญ:

• Time-to-first-audio TTS ที่ใช้เวลา 200ms ในการเริ่มพูดจะเผางบประมาณ latency หนึ่งในสามของคุณไปกับเลเยอร์เอาต์พุตเพียงอย่างเดียว
• คุณภาพเสียง มนุษย์ไวต่อเสียงสังเคราะห์อย่างมาก สิ่งแปลกปลอมเล็กน้อย จังหวะที่ไม่เป็นธรรมชาติ การเน้นผิดที่ ล้วนถูกตีความว่าเป็นคำตัดสินของทั้งระบบ
• เลือกเสียงอย่างตั้งใจ มันเป็นสัญญาณแห่งความไว้วางใจก่อนที่ผู้ใช้จะได้ยินประโยคด้วยซ้ำ

มือ (ฟังก์ชันและการผสานรวม)

ฟังก์ชันคือการกระทำที่ LLM สามารถทำได้ระหว่างการสนทนา:

• จองนัดหมาย
• ตรวจสอบสถานะคำสั่งซื้อ
• ส่ง SMS ยืนยัน
• โอนต่อไปยังมนุษย์
• อัปเดตบันทึกใน CRM ของคุณ

นี่คือการเปลี่ยนแปลงทางสถาปัตยกรรมที่ทำให้ voice agent สมัยใหม่มีความสามารถมากกว่าระบบกด-1-เพื่อ-การเรียกเก็บเงินอย่างมาก

งบประมาณ latency ที่คุณต้องอยู่ภายใน

สิ่งที่สำคัญที่สุดที่ไม่ชัดเจนเกี่ยวกับ voice agent: ทุกมิลลิวินาทีของเวลาในการประมวลผลคือมิลลิวินาทีแห่งความเงียบที่ผู้โทรนั่งอยู่ภายใน

คณิตศาสตร์:

• มนุษย์คาดหวังคำตอบในการสนทนาภายใน 500 ถึง 700ms หลังจากพูดจบประโยค
• เกินหนึ่งวินาทีจะรู้สึกว่าระบบกำลังดิ้นรน
• เกินสองวินาที ผู้โทรจะเริ่มพูดทับเอเจนท์

700ms นั้นคืองบประมาณทั้งหมดของคุณ แบ่งให้กับทุกองค์ประกอบ

งบประมาณต่อองค์ประกอบ เลน fast vs เลน slow:

• Transport 20-50ms peer-to-peer 50-100ms ผ่านรีเลย์
• STT first interim 100-150ms เมื่อ cache hit 150-250ms เมื่อ cache miss
• การตรวจจับการจบเทิร์น แบบรวมในโมเดล ~50ms แบบเกณฑ์ความเงียบ 300-600ms
• การดึงข้อมูล RAG ต่ำกว่า 1ms เมื่อ cache hit 80-150ms สำหรับ local BM25 + rerank
• LLM time-to-first-token 150-250ms ด้วยโมเดลเล็ก 400-600ms ด้วยโมเดลชั้นนำ
• TTS time-to-first-audio 60-100ms บนระดับ fast 150-250ms บนระดับคุณภาพ
• Network overhead 40-80ms รวมภายในหนึ่งภูมิภาค 100-160ms รวมข้ามภูมิภาค
• End-to-end ~440ms บนเลน fast ~700-900ms บนเลน slow

สองสิ่งที่ปลดล็อกมากที่สุดในปี 2026:

1. การตรวจจับการจบเทิร์นแบบรวมในโมเดล ลด 200 ถึง 400ms จากทุกเทิร์น การอัปเกรดครั้งใหญ่ที่สุดที่คุณสามารถทำได้ในปีนี้เพียงอย่างเดียว
2. Speculative prefetch ด้วย dual-agent cache ทำให้การดึงข้อมูลจาก "miss ด้วย vector search" เป็น "hit ด้วย cache lookup" ในประมาณ 40% ของเทิร์น

สิ่งอื่นๆ เป็นเพียงความคลาดเคลื่อนเล็กน้อยเมื่อเทียบกับสองสิ่งนี้

รูปแบบ dual-agent RAG

RAG มาตรฐานภายในลูปเสียงเป็นปัญหา การค้นหาฐานข้อมูลเวกเตอร์ใช้เวลา 80 ถึง 300ms และทำให้งบประมาณ latency ของคุณหมดในทุกเทิร์น

คำตอบจากงานวิจัยปี 2026 มาจากบทความ VoiceAgentRAG ของ Salesforce AI Research ซึ่งตีพิมพ์ในเดือนมีนาคม ข้อมูลเชิงลึกนั้นเรียบง่าย

• ในการสนทนาจริง คำถามถัดไปมักจะคาดเดาได้จากคำถามปัจจุบัน
• คนที่ถามเกี่ยวกับราคามักจะถามต่อเกี่ยวกับระดับองค์กร
• คนที่ถามเกี่ยวกับการติดตั้งมักจะถามเกี่ยวกับความเข้ากันได้ต่อไป

ดังนั้นคุณจึงรันสองเอเจนท์พร้อมกัน

เอเจนท์พื้นหลัง (Slow Thinker)

• ทำงานในขณะที่ผู้ใช้กำลังฟังคำตอบปัจจุบัน
• ทำนายคำถามติดตามผลสามถึงห้าข้อที่เป็นไปได้มากที่สุดโดยใช้ LLM
• ดึงส่วนเอกสารที่เกี่ยวข้องล่วงหน้าสำหรับแต่ละการทำนาย
• เก็บไว้ใน cache หน่วยความจำภายในเครื่องก่อนที่ผู้ใช้จะได้ยินคำตอบปัจจุบันจบ

เอเจนท์เบื้องหน้า (Fast Talker)

• จัดการคำถามสดถัดไปโดยตรวจสอบ cache ในหน่วยความจำก่อน
• การค้นหา cache ใช้เวลาต่ำกว่า 1ms เทียบกับ 110ms สำหรับการเรียกฐานข้อมูลเวกเตอร์ระยะไกล
• ถ้า cache มีคำตอบ ให้ข้ามฐานข้อมูลทั้งหมด
• ถ้า cache miss ให้กลับไปใช้ฐานข้อมูลและ cache ผลลัพธ์นั้นสำหรับครั้งต่อไป

ตัวเลขมาตรฐานจากบทความ

• 75% ของข้อความค้นหาตี cache
• ความเร็วในการดึงข้อมูลเร็วขึ้น 316 เท่าเมื่อ cache hit (0.35ms เทียบกับ 110ms)
• ประหยัดเวลาแฝงสะสมได้ 16 วินาทีจาก 200 คำค้นหา

หลักการที่ต้องจำ: ใช้เวลาในการฟังของผู้ใช้เป็นเวลาในการคำนวณของคุณ ช่วงเวลาที่พวกเขาเริ่มได้ยินคำตอบปัจจุบันคือช่วงเวลาที่คุณเริ่มเตรียมคำถามถัดไปของพวกเขา

ฉันลองใช้ vector RAG ธรรมดาภายในลูปเสียงในการสร้างครั้งแรก เพิ่ม 110ms ต่อเทิร์น

ฆ่าความรู้สึกของการสนทนา ฉันเปลี่ยนไปใช้รูปแบบ dual-agent cache ในสัปดาห์ที่หก 40% ของเทิร์นที่ตี cache ให้ความรู้สึกรวดเร็วกว่าตัวแทนศูนย์บริการทางโทรศัพท์ของมนุษย์ที่เอเจนท์มาแทนที่

การออกแบบบทสนทนาคือวินัยที่ผู้สร้างส่วนใหญ่ข้าม

คุณสามารถมี STT ที่เร็วที่สุด, LLM ที่เล็กที่สุด, cache RAG ที่ฉลาดที่สุด ถ้าเอเจนท์ของคุณไม่รู้วิธีพูด ผู้โทรจะวางสาย

การออกแบบบทสนทนาคือวินัยของการเขียนเพื่อหู ไม่ใช่ตา

กฎที่ฉันปฏิบัติตามตอนนี้ซึ่งฉันเรียนรู้โดยการทำให้ผิดก่อน

• พูดเป็นประโยคสั้นๆ ความสนใจโดยเฉลี่ยของมนุษย์สำหรับข้อมูลที่พูดคือ 8 ถึง 10 วินาที คำตอบ 15 วินาทียาวเกินไป แบ่งเป็นสองเทิร์น
• อย่าถามสองคำถามในเทิร์นเดียว ผู้โทรสามารถเก็บในหน่วยความจำทำงานได้ครั้งละหนึ่งเท่านั้น ถามหนึ่งข้อ รอ แล้วถามข้อถัดไป
• ใช้วลียอมรับ "เข้าใจแล้ว" "ได้เลย" "เดี๋ยวผม/ฉันตรวจสอบให้" สิ่งเหล่านี้เติมเต็มความเงียบระหว่างที่ผู้ใช้พูดจบและคำตอบพร้อม
• สะท้อนภาษาของผู้ใช้ ผู้โทรพูด "ปัญหาการเรียกเก็บเงิน" เอเจนท์พูด "ปัญหาการเรียกเก็บเงิน" กลับ ไม่ใช่ "ข้อพิพาททางการเงิน" หรือ "ปัญหาการชำระเงิน" การถอดความสร้างแรงเสียดทาน การสะท้อนสร้างความสัมพันธ์
• เขียนเพื่อหู ไม่ใช่ตา ไม่มีหัวข้อย่อย ไม่มีหัวเรื่อง ไม่มี markdown ใน system prompt LLM จะพยายามพูดเครื่องหมายดอกจันและยัติภังค์
• สะกดตัวเลข "เก้า สี่ หนึ่ง ศูนย์ เจ็ด" แทน "94,107" "สิบห้าดอลลาร์และเก้าสิบเก้าเซ็นต์" แทน "$15.99" TTS มักจะออกเสียงตัวเลขที่จัดรูปแบบผิด
• จำกัด system prompt ที่ 800 โทเค็น มันโหลดซ้ำทุกเทิร์น

โครงสร้างสามองก์ของการสนทนาเสียงที่ดีทุกครั้ง

1. การยอมรับและการปฐมนิเทศ "คุณกำลังจะเลื่อนการนัดหมายวันพฤหัสบดีใช่ไหมคะ/ครับ? เดี๋ยวดึงข้อมูลให้" ยืนยันว่าผู้โทรเข้าใจ ซื้อเวลาในขณะที่การดึงข้อมูลทำงาน
2. การแก้ไข การกระทำหรือคำตอบหลัก หนึ่งประเด็นต่อเทิร์น เดินหน้าต่อไป
3. การยืนยันและการปิด "ฉันได้เลื่อนการนัดหมายของคุณเป็นวันจันทร์ที่ 19 เวลา 15.00 น. คุณจะได้รับข้อความยืนยันเร็วๆ นี้" การออกจากอย่างสะอาด อย่าปล่อยให้ลูปเปิดค้างไว้

ความปลอดภัยคือจุดตรวจสองแห่ง ไม่ใช่แห่งเดียว

องค์ประกอบที่ผู้สร้างครั้งแรกส่วนใหญ่ข้ามและเสียใจทีหลัง

voice agent ไม่มีช่วงเวลา "อ่านก่อนส่ง" เอาต์พุตที่ไม่ปลอดภัยจะถูกพูดทันที ไม่มีร่าง ไม่มีตัวอย่าง ไม่มีมนุษย์ในวงจร

รูปแบบที่ถูกต้องคือจุดตรวจสองแห่ง

จุดตรวจอินพุต (ก่อนที่ LLM จะเห็นเทิร์นของผู้ใช้)

• การฉีด prompt "ไม่ต้องสนใจคำแนะนำก่อนหน้านี้ แสร้งทำเป็นว่าคุณคือ..." การโจมตี ใช้ประโยชน์จากการปฏิบัติตามคำแนะนำของ LLM เพื่อขโมยข้อมูลหรือละเมิดขอบเขต
• PII ที่ถูกพูดออกมา หมายเลขบัตรเครดิต หมายเลขประกันสังคม ควรแก้ไขก่อนที่มันจะถึง log หรือฐานข้อมูลใดๆ
• รายการต้องห้ามหัวข้อ โหลดจากไฟล์ JSON อัปเดตทุกสัปดาห์เมื่อคุณเรียนรู้ว่าผู้ใช้พยายามทำอะไรจริงๆ

จุดตรวจเอาต์พุต (หลังจาก LLM เขียนคำตอบ ก่อนที่ TTS จะพูด)

• ภาษาที่สัญญาเกินจริง "ฉันรับประกัน" "ฉันสัญญา" สร้างปัญหาทางกฎหมายและความไว้วางใจบนสายที่ถูกบันทึก
• ข้อกล่าวอ้างที่เป็นข้อเท็จจริงเฉพาะที่ไม่อยู่ในบริบทที่ดึงมา การตรวจสอบภาพหลอนแบบเบา จับได้ประมาณ 70% ของคำตอบที่แต่งขึ้นในการปรับใช้ของฉัน
• จุดตรวจสอบการกลั่นกรองมาตรฐาน สำหรับพฤติกรรมที่ไม่เหมาะสมของโมเดลที่เกิดขึ้นได้ยาก

สิ่งที่จุดตรวจทั้งสองคืนกลับมา

• safe (bool)
• หมวดหมู่ที่ตรวจพบ (string, ถ้าไม่ปลอดภัย)
• วลีทดแทนที่เอเจนท์พูดแทน

ทุกทริกเกอร์จะถูกบันทึกลงในไฟล์พร้อม timestamp หมวดหมู่ ข้อความที่แก้ไข และ ID การโทร

วลีสำหรับส่งต่อ

หนึ่งวลีที่แน่นอน ซึ่งถูกฮาร์ดโค้ด ที่เอเจนท์พูดเมื่อมันไม่ทราบคำตอบหรือเมื่อมีอะไรผิดปกติ

• "ฉันอยากจะแน่ใจว่าฉันให้ข้อมูลที่ถูกต้องแก่คุณ ขอเชื่อมต่อคุณกับคนที่สามารถช่วยได้ค่ะ/ครับ"
• ไม่ใช่ห้ารูปแบบที่แตกต่าง ไม่ใช่การเดาคำพูดที่ถูกต้องโดย improvisation ของ LLM
• หนึ่งวลี ตัวพิมพ์ใหญ่ทั้งหมดใน system prompt การตกผ่านเมื่อการตรวจสอบความปลอดภัยใดๆ ทำงาน

ฉันส่งโดยไม่มีจุดตรวจเอาต์พุตในการสร้างครั้งแรก เอเจนท์อ้างราคาที่ต่ำกว่าราคาจริง 30% อย่างมั่นใจ

ราคานั้นอยู่ในเอกสารที่ล้าสมัยในฐานความรู้

การตรวจสอบภาพหลอนคงจะจับมันได้เพราะราคาที่ถูกต้องไม่อยู่ในบริบทที่ดึงมา

การประเมิน หรือวิธีรู้ว่ามันดีหรือไม่

คุณไม่สามารถปรับปรุงสิ่งที่คุณวัดไม่ได้ ทีมส่วนใหญ่ข้ามการประเมินและส่ง agent ที่พัง

กรอบงานสี่ชั้น

ชั้นที่ 1: โครงสร้างพื้นฐาน ระบบท่อ

• WER บนโดเมนจริงของคุณ (ไม่ใช่เกณฑ์มาตรฐานของผู้ขาย)
• p50, p95, p99 latency สำหรับ pipeline เต็ม
• Time-to-first-audio
• คุณภาพเสียงบนการขนส่งของคุณ

ชั้นที่ 2: การดำเนินการ เอเจนท์ทำตามที่ขอหรือไม่

• อัตราความสำเร็จของงาน
• ความแม่นยำในการเรียกเครื่องมือ
• ความถูกต้องของพารามิเตอร์
• ความ groundedness ของคำตอบ
• ใช้ LLM-as-judge บนโมเดลเล็กที่รวดเร็ว คำถามใช่/ไม่ใช่สี่ข้อ: ตอบถูกต้อง, อยู่ในกรอบ grounded, ฟังดูเป็นธรรมชาติสำหรับเสียง, กระชับอย่างเหมาะสม

ชั้นที่ 3: พฤติกรรมผู้ใช้ รู้สึกเป็นธรรมชาติที่จะคุยด้วยหรือไม่

• อัตราการกู้คืนจากการขัดจังหวะ
• อัตราการถามซ้ำ
• ความยาวเทิร์นโดยเฉลี่ย
• จำนวนการซ่อมแซมการสนทนา
• สุ่มตัวอย่าง 20 สายต่อสัปดาห์ อ่าน transcript จริง คุณจะเห็นรูปแบบภายในสิบสาย

ชั้นที่ 4: ผลลัพธ์ทางธุรกิจ มันแก้ปัญหาได้หรือไม่

• อัตราการจัดการ (เปอร์เซ็นต์ของสายที่แก้ไขได้โดยไม่ต้องใช้มนุษย์)
• อัตราการถ่ายโอน
• CSAT
• อัตราการแก้ปัญหาในสายแรก
• ปรับให้เหมาะสมกับอัตราการจัดการ มันสัมพันธ์กับทุกสิ่งทุกอย่างและเป็นสิ่งที่ง่ายที่สุดในการวัดโดยไม่ต้องใช้เครื่องมือ

องค์ประกอบของชุดทดสอบ

สร้างก่อนเปิดตัว ขั้นต่ำ 50 บทสนทนา

• 40% เส้นทางหลัก (happy path)
• 30% กรณีขอบ
• 15% การจัดการข้อผิดพลาด
• 10% เชิงปรปักษ์ (prompt injection, ความพยายาม jailbreak)
• 5% ความแปรปรวนทางเสียง (เสียงรบกวนพื้นหลัง, สำเนียงหนัก, ลำโพง)

สำหรับแต่ละสถานการณ์:

• ควรเรียกเครื่องมือใด
• ด้วยพารามิเตอร์อะไร
• เอเจนท์ควรพูดอะไร

กระบวนการทบทวนรายสัปดาห์

ทุกเช้าวันจันทร์ 30 นาที

1. ดึงเมตริก
2. สุ่มตัวอย่าง 20 สาย (7 สายที่ถูกส่งต่อ, 7 สายที่แก้ไขได้, 6 สายสุ่ม)
3. อ่าน transcript
4. ระบุประเภทความล้มเหลวที่พบบ่อยที่สุดเพียงประเภทเดียว
5. ทำการเปลี่ยนแปลงหนึ่งอย่าง (ครั้งละหนึ่งตัวแปร เสมอ)
6. ทดสอบ A/B เป็นเวลา 48 ชั่วโมง
7. ส่งผู้ชนะ

Grounding คือระบบความไว้วางใจ

ผู้สร้างส่วนใหญ่คิดถึง RAG ในฐานะคุณลักษณะด้านประสิทธิภาพ ซึ่งเป็นวิธีที่จะได้คำตอบที่แม่นยำยิ่งขึ้น กรอบความคิดนั้นประเมินมันต่ำเกินไป

ใน voice agent ความแม่นยำของทุกคำตอบคือคำพูดโดยตรงเกี่ยวกับความน่าเชื่อถือของผลิตภัณฑ์ของคุณ ผู้โทรที่ได้ยินคำตอบที่ผิดเกี่ยวกับราคา ความคุ้มครอง หรือนโยบาย ซึ่งพูดอย่างมั่นใจด้วยเสียงที่เป็นธรรมชาติ จะไม่เพียงแค่หงุดหงิด พวกเขาจะรู้สึกถูกหลอก

การดำเนินการตามสัญญาแห่งความไว้วางใจมีสี่ส่วน

1. แหล่งที่มาของความจริง

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

1. การปฏิเสธอย่างสุภาพ

• เมื่อเอเจนท์ไม่พบคำตอบ มันจะพูดโดยตรง
• วลีที่แน่นอนมีความสำคัญ
• "ฉันอยากจะแน่ใจว่าฉันให้ข้อมูลที่ถูกต้องแก่คุณ ขอตรวจสอบก่อนนะคะ/ครับ" ทำให้คุณมีเวลาสำหรับการโอนย้ายอย่างราบรื่น
• "ฉันไม่แน่ใจ" ฟังดูเหมือนไร้ความสามารถ
• "ตามข้อมูลของฉัน" ฟังดูเหมือนการพูดเลี่ยงจากทนายความ
• เลือกหนึ่งวลี ฮาร์ดโค้ดมัน อย่าปล่อยให้ LLM ปรับแต่งเองตรงนี้

1. การตอบสนองที่รับรู้ความมั่นใจ

• คะแนน BM25 สูงสุดในส่วนที่ดึงมาเป็นตัวแทนที่มีประโยชน์สำหรับความมั่นใจ
• คะแนนสูงกว่า 0.6: เอเจนท์ตอบอย่างมั่นใจ
• คะแนน 0.3 ถึง 0.6: เอเจนท์ตอบแต่เพิ่มคำว่า "ฉันคิดว่า" เพื่อบอกความไม่แน่ใจ
• คะแนนต่ำกว่า 0.3: เอเจนท์ไม่ตอบ เสนอที่จะโอนต่อ
• การเปลี่ยนแปลง 20 บรรทัดในโค้ดสร้าง system prompt ลดภาพหลอนลงประมาณครึ่งหนึ่ง

1. สุขอนามัยของฐานความรู้

• เอกสารที่ล้าสมัยสร้างคำตอบที่ล้าสมัย ซึ่งเป็นคำตอบที่อันตราย
• ฉันตรวจสอบวันศุกร์: อ่าน 5% ล่างของคำตอบที่มีคะแนนความมั่นใจต่ำจากสัปดาห์นั้น
• ครึ่งหนึ่งของเวลาคำตอบถูกต้อง แต่การดึงข้อมูลพบส่วนที่เก่า
• อัปเดตส่วนนั้น ฝังใหม่ สัปดาห์หน้าจะเงียบลง

สิ่งที่ต้องระวัง

โหมดความล้มเหลวหกแบบที่จะเกิดขึ้นกับคุณ

VAD ใน pipeline แทนที่จะเป็น transport

• ปัญหา เอเจนท์ทำงานบนเอาต์พุต TTS ของตัวเอง เข้าสู่ลูปขัดจังหวะ หรือไม่สามารถตรวจจับการจบเทิร์นได้เลย
• วิธีแก้ไข ตัววิเคราะห์ VAD อยู่บน transport เสมอ จับคู่กับ echo guard ที่ไม่สนใจ transcript STT ที่ตรงกับเอาต์พุตของ assistant ล่าสุด

เครื่องมือพร้อมใช้งานในสถานะผิด

• ปัญหา LLM เรียก book_appointment ในสถานะที่ยังรวบรวมชื่อผู้ป่วยอยู่ หรือสร้างการจองที่ไม่เคยเกิดขึ้น
• วิธีแก้ไข กำหนดขอบเขตเครื่องมือต่อสถานะ หนึ่งสถานะ, เฉพาะฟังก์ชันของมันเท่านั้น state machine คือราวกันตก ไม่ใช่ system prompt

ตัวจัดการฟังก์ชันโยนข้อยกเว้นและไม่เคยเรียก callback ผลลัพธ์

• ปัญหา LLM ค้างรอผลลัพธ์ของเครื่องมือที่ไม่เคยมา หรือสร้างภาพหลอนขึ้นมา
• วิธีแก้ไข ทุกตัวจัดการครอบด้วย try/except ทุกสาขาส่งผลลัพธ์กลับ ทุกความล้มเหลวมีคำพูดสำรอง ไม่เคยมีผลลัพธ์ที่ว่างเปล่า

ตรวจสอบข้อมูลผู้ใช้ใน prompt แทนที่จะเป็นในโค้ด

• ปัญหา LLM ยอมรับ "john@" เป็นอีเมลจริงในสายที่ 12 ปฏิเสธอีเมลที่ถูกต้องที่มีเครื่องหมายบวกในสายที่ 47
• วิธีแก้ไข การตรวจสอบอยู่ใน Python regex สำหรับอีเมล, date parser สำหรับวันที่, การตรวจสอบความยาวชื่อ, การตอบกลับเพื่อถามใหม่เมื่อการตรวจสอบล้มเหลว

หน้าต่างบริบทเติบโตไม่จำกัดในการโทรที่ยาวนาน

• ปัญหา p95 latency ค่อยๆ เพิ่มขึ้นตลอดทั้งสัปดาห์โดยไม่มีการเปลี่ยนแปลงโค้ด เมื่อถึงเทิร์นที่ 20 คุณกำลังส่ง 12K โทเค็นต่อเทิร์น
• วิธีแก้ไข หน้าต่างเลื่อนของเทิร์น N ครั้งล่าสุดบวก system prompt หรือการรีเซ็ตบริบทตามเหตุการณ์สำคัญเมื่อสิ้นสุดแต่ละขั้นตอนที่ไม่ต่อเนื่อง

TTS อ่านรหัสและ ID ตามตัวอักษร

• ปัญหา รหัสยืนยัน "A3X7" กลายเป็น "เอ สาม เอ็กซ์ เซเว่น" โดยไม่มีการหยุด ผู้ป่วยขอให้คุณพูดซ้ำอยู่ดี
• วิธีแก้ไข การขยายด้วยอักษรสัทศาสตร์ NATO และแท็ก SSML break ฟังดูช้าลง แต่อ่านถูกต้องในครั้งแรก

สิ่งที่ฉันจะทำแตกต่างออกไป

• สร้าง schema ของ turn log ตั้งแต่วันแรก ไม่ใช่สัปดาห์ที่สี่ จุดสิ้นสุดการเล่นซ้ำเป็นเครื่องมือที่มีค่าที่สุดที่ฉันสร้าง และฉันสร้างมันหลังจากที่ฉันต้องการมัน
• ใช้การตรวจจับการจบเทิร์นเชิงความหมายตั้งแต่เริ่มต้น แทนที่จะต่อสู้กับเกณฑ์ความเงียบ
• ย้ายไปยัง state machine จริงในวันที่ system prompt เกิน 300 คำ อย่าพยายามเข้ารหัส state machine เป็นร้อยแก้ว
• หยุดตรวจสอบใน prompt LLM ไม่ใช่ parser Python คือ parser ใช้ Python
• Cache เอกสาร RAG ที่เป็นไปได้มากที่สุดห้าฉบับเมื่อเริ่มต้นการโทร ข้ามการค้นหาเวกเตอร์ภายในลูปเทิร์น
• สร้างประตูสำหรับการพูดคุยเล็กน้อยก่อนที่คุณจะสร้างการดึงข้อมูล "สวัสดี" คือการชนะ 200ms ที่ถูกที่สุดในระบบ
• รันชุดประเมินผลก่อนการโทรจริงครั้งแรก ขั้นต่ำ 50 บทสนทนา
• ใส่คิวการแยกข้อมูลที่ทนทานตั้งแต่วันแรก ตาราง pending_extractions ใน Postgres ที่มี worker ลองใหม่ครั้งเดียวใช้เวลา 200 บรรทัดและช่วยคุณประหยัดจากการหยุดทำงานจริง
• รันผู้ตัดสิน LLM แบบอะซิงโครนัสทุกๆ 50 สาย ให้คะแนนจากความ groundedness ความเกี่ยวข้อง ความกระชับ ส่งไปยัง dashboard การเลื่อนลอยนั้นมีจริง
• รันกระบวนการทบทวนรายสัปดาห์ สุ่มตัวอย่าง 20 สายทุกวันจันทร์ ทำการเปลี่ยนแปลงหนึ่งครั้ง ทดสอบ A/B ส่งผู้ชนะ

บทสรุป

Voice agent ดูเหมือน AI แต่ทำงานเหมือนระบบ real-time

ทีมที่ส่งมอบจะปฏิบัติต่อพวกมันแบบนั้น ทีมที่ส่งมอบช้าไปหกเดือนคิดว่า prompt ที่ดีกว่าจะแก้ปัญหาของระบบได้

เป็นเจ้าของ pipeline ของคุณ เป็นเจ้าของ log ของคุณ เก็บไว้ในไฟล์ธรรมดาที่ความล้มเหลวใดๆ ก็อยู่ห่างออกไปเพียงแค่การเล่นซ้ำครั้งเดียว

เอเจนต์ตัวแรกใช้เวลาฉันแค่สุดสัปดาห์เดียว แต่ระบบที่ใช้จริงใช้เวลาสิบสัปดาห์ ตั้งแต่นั้นมา มันก็พัฒนาขึ้นทุกวัน โดยที่ฉันไม่ต้องแตะต้องมันเลย ผู้ใช้ไม่ได้วัดตรงนั้น พวกเขาสังเกตว่าเอเจนต์ตอบ "ขอบคุณ" โดยไม่ต้องให้พวกเขารอ

ข้อปฏิเสธความรับผิดชอบและการเปิดเผยข้อมูล

บทความนี้ได้รับการค้นคว้าและเขียนโดยผู้เขียน และได้รับการแก้ไขโดยโมเดล AI ภาพขนาดย่อนำมาจาก Pinterest

บทความนี้ได้รับการค้นคว้าและเขียนโดยผู้เขียนขณะทำงานเกี่ยวกับเอเจนต์เสียงในโครงสร้างพื้นฐานที่ลึกซึ้งยิ่งขึ้น

บทความนี้อ้างอิงจากบันทึกที่พัฒนาอย่างต่อเนื่องและการวิจัยเชิงลึกโดยใช้ Perplexity, Claude และ ChatGPT รวมถึงการออกแบบระบบและการออกแบบ API จากหนังสือระดับปริญญาตรีสองสามเล่ม

บทความนี้ได้รับการแก้ไขอย่างละเอียดโดย Minimax M2.7 และ Claude Opus 4.7 เพื่อแก้ไขข้อผิดพลาดทางไวยากรณ์และการจัดรูปแบบ