Chatbot ไม่ได้มีประเภทเดียว และคำว่า “AI Chatbot” ไม่ได้บอกทุกอย่างเกี่ยวกับระบบหลังบ้าน ในทางปฏิบัติ เราอาจแบ่งระบบตอบแชตตาม วิธีที่ใช้ตัดสินใจว่าจะตอบอะไร เป็นสามแนวทางหลัก ได้แก่ กฎที่เขียนไว้ การตีความเจตนาของข้อความ และการใช้โมเดลภาษาสร้างคำตอบ แต่ระบบหนึ่งอาจใช้ทั้งสามแนวทางร่วมกัน
บทความนี้เน้นช่วยเลือกเครื่องมือและออกแบบระบบ หากยังไม่คุ้นกับคำว่า Bot อ่าน Chatbot คืออะไร ก่อน ส่วนบทความ AI Chatbot คืออะไร จะลงลึกเรื่อง LLM โดยไม่ทับกับการเลือกประเภทในหน้านี้
Rule-based Chatbot: เส้นทางชัด ต้นทางตรวจง่าย
Rule-based Chatbot ใช้เงื่อนไขที่ผู้พัฒนากำหนด เช่น ถ้าผู้ใช้กด “เวลาทำการ” ให้ส่งเวลาของสาขาที่เลือก หรือถ้าพิมพ์คำสำคัญแล้วจับคู่ได้ให้ตอบข้อมูลที่เตรียมไว้
จุดแข็ง คือคาดเดาพฤติกรรมได้ง่าย และเหมาะกับข้อมูลที่มีเจ้าของชัดเจน เช่น คู่มือบริการ ขั้นตอนแจ้งปัญหา หรือการคัดกรองคำถาม 4–5 ข้อ โดยไม่ต้องให้โมเดลแต่งประโยคอิสระ
จุดอ่อน คือเมื่อผู้ใช้พิมพ์นอกเมนูหรือคำที่ระบบไม่รู้จัก ระบบอาจวนถามหรือให้คำตอบผิดหมวด จำเป็นต้องมีข้อความ “ไม่เข้าใจคำถาม” และช่องทางไปต่อที่ไม่ทำให้ผู้ใช้ติดอยู่ในวงจรเดิม
ตัวอย่างสมมติ: ร้านเปิดให้เลือก “ราคาเริ่มต้น / การจัดส่ง / คืนสินค้า” แล้วส่ง URL นโยบายที่ทีมร้านดูแลไว้ ความถูกต้องขึ้นอยู่กับการอัปเดตนโยบายต้นทาง ไม่ใช่จำนวนเมนูของ Bot
NLP / Intent-based Chatbot: รู้จักความหมายที่ผู้ใช้ต้องการ
ผู้ใช้อาจพิมพ์ว่า “เปิดเสาร์ไหม”, “เสาร์ร้านเปิดหรือเปล่า” หรือ “วันหยุดยังรับลูกค้าอยู่ไหม” ทั้งหมดอาจหมายถึง Intent เดียวคือ สอบถามเวลาให้บริการ ระบบที่แยกเจตนาจากข้อความช่วยลดความจำเป็นที่ต้องเขียนทุกประโยคแบบตรงตัว
รูปแบบทั่วไปประกอบด้วย Intent (เจตนา), Training Phrases (ตัวอย่างประโยค), Entity/Parameter (ค่าที่ต้องดึง เช่น วันหรือสาขา) และ Flow การตอบ หากระบบไม่แน่ใจอาจถามย้ำ เช่น “หมายถึงสาขาไหน” ก่อนเลือกคำตอบ
ข้อควรระวังคือความแม่นยำขึ้นอยู่กับชุดตัวอย่าง คำที่ซ้ำความหมาย และวิธีประเมินผล หากมี Intent “สอบถามการคืนสินค้า” กับ “ร้องเรียนสินค้าชำรุด” อยู่ใกล้กันมาก ควรออกแบบเส้นทางแยกและส่งต่อเจ้าหน้าที่เมื่อความหมายไม่ชัด
แนวคิดนี้ปรากฏในผลิตภัณฑ์ด้าน Conversational AI ที่จัดการ Flow กับความหมายของข้อความ เช่น Dialogflow CX แต่ชื่อและความสามารถของฟีเจอร์ขึ้นอยู่กับผลิตภัณฑ์/เวอร์ชันที่ใช้งานจริง
Generative AI Chatbot: ตอบได้ยืดหยุ่นขึ้น แต่ต้องมีหลักฐาน
ระบบที่ใช้ Large Language Model (LLM) สามารถเรียบเรียงคำตอบตามคำถามและบริบทที่ได้รับ เช่น ช่วยสรุปคู่มือยาวให้สั้นลง เปรียบเทียบขั้นตอน หรือถามเพิ่มเติมเมื่อข้อมูลไม่ครบ
ข้อได้เปรียบคือไม่จำเป็นต้องเขียนข้อความตอบทุกรูปประโยค แต่ต้องระวัง ข้อมูลที่โมเดลไม่ได้รับ โมเดลอาจตอบได้คล่องแต่ไม่รู้ว่าเงื่อนไขคืนสินค้าของบริษัทเปลี่ยนไปเมื่อวาน และคำตอบที่ดูเหมือนมั่นใจก็อาจผิด
การออกแบบที่เหมาะสมจึงต้องเลือกว่าจะให้โมเดลอ่านข้อมูลจากเอกสาร (retrieval) เรียก API ที่กำหนดไว้ หรือปฏิเสธเมื่อไม่พบหลักฐาน การต่อโมเดลเข้ากับเครื่องมือไม่ใช่การเปิดสิทธิ์ทั้งหมดให้โมเดลตัดสินใจเอง; โปรแกรมต้องตรวจพารามิเตอร์และสิทธิ์ในชั้น Backend
อ่านต่อเรื่ององค์ประกอบ LLM ได้ใน AI Chatbot กับ Context และกลไกเรียกเครื่องมือจาก OpenAI Function Calling
ตารางเทียบประเภท Chatbot ก่อนเลือก
| ประเด็น | Rule-based | NLP / Intent | Generative AI |
|---|---|---|---|
| เหมาะกับ | เมนู/ขั้นตอนแน่นอน | คำถามคล้ายกันแต่ใช้ภาษาหลากหลาย | อธิบาย/สรุปข้อมูลหลายรูปแบบ |
| แหล่งคำตอบ | ข้อความ/เงื่อนไขที่เตรียมไว้ | Flow ที่ผูกกับ Intent | Prompt + Context + แหล่งข้อมูลที่เชื่อม |
| ปรับปรุงเมื่อผิด | แก้เงื่อนไข/ข้อความ | เพิ่มตัวอย่างและปรับ Intent | ตรวจ Prompt/แหล่งข้อมูล/Evaluation |
| ความเสี่ยงหลัก | บอทไม่รู้ทางไปต่อ | จับ Intent ผิด | สร้างคำตอบไร้หลักฐานหรือใช้ Tool ผิด |
| ต้นทุนที่ควรคิด | ดูแลเมนูและข้อมูล | ดูแลชุดตัวอย่าง/โมเดล | ค่าประมวลผล กำกับข้อมูลและตรวจคุณภาพ |
นี่ไม่ใช่การจัดอันดับคุณภาพหรือตารางราคาของผู้ให้บริการรายใด เพราะต้นทุนจริงขึ้นกับจำนวนผู้ใช้ รูปแบบการโฮสต์ ข้อมูล และการบำรุงรักษา
ถ้าต้องการหลายความสามารถในระบบเดียว
ตัวอย่างโครงแบบผสมสำหรับบริษัทบริการ:
- กฎ คุมเงื่อนไขที่ต้องถูกต้องแน่นอน เช่น ยืนยันตัวตนก่อนเปิดข้อมูลลูกค้า
- Intent ช่วยแยกว่าผู้ใช้จะนัดหมาย ติดต่อฝ่ายขาย หรือสอบถามเอกสาร
- LLM ใช้อธิบายข้อมูลสาธารณะจากเอกสารที่อนุมัติแล้ว โดยแนบแหล่งอ้างอิง
- คน รับช่วงเมื่อเป็นคำถามซับซ้อน การร้องเรียน หรือกรณีขออนุมัติพิเศษ
สิ่งสำคัญคือกำหนดเส้นแบ่งหน้าที่ หาก Bot ไม่พบข้อมูล ต้องกลับไปถามหรือส่งต่อ ไม่ให้การสรุปของ LLM กลายเป็นการออกคำสั่งธุรกิจโดยไม่มีการตรวจ
เลือกประเภทจากความเสี่ยง ไม่ใช่ตามกระแส
ลองตอบคำถามต่อไปนี้ก่อนลงมือ: คำถามที่เข้ามาคล้ายกันมากน้อยแค่ไหน? มีข้อมูลฉบับเดียวที่ทีมรับรองหรือไม่? ต้องเข้าถึงข้อมูลส่วนบุคคลหรือเปล่า? ถ้าคำตอบผิดใครได้รับผลกระทบ? มีคนดูแลระบบและอัปเดตคำตอบได้หรือไม่?
สำหรับกิจการที่เพิ่งเริ่ม คำถามพื้นฐานและขั้นตอนติดต่ออาจทำด้วยเมนูและ FAQ ก่อน หากเริ่มเห็นว่าคำถามมีรูปแบบภาษาหลากหลายจึงทดลองเพิ่ม Intent หรือ AI เฉพาะส่วน โดยเก็บตัวอย่างคำถามที่ตอบไม่ได้ไว้ใช้ประเมินคุณภาพ
ตัวอย่างการเลือกที่ไม่ใช่กฎตายตัว: หน้าเว็บอบรมที่ผู้ใช้ถามวันเปิดคอร์สเหมาะกับข้อมูลปฏิทินที่ตรวจได้; ร้านค้าที่มีคำถามเปรียบเทียบสินค้าหลายรายการอาจได้ประโยชน์จากการค้น Catalog และสรุปด้วย LLM แต่สต็อกจริงยังต้องมาจากระบบต้นทาง
คำถามที่พบบ่อย
Rule-based Bot ถือเป็น AI ไหม
ไม่จำเป็น หากเป็นเพียงเงื่อนไขที่คนเขียนไว้ก็เป็น Automation ตามกฎ ส่วนระบบ Intent อาจมี Machine Learning และ Generative AI เป็นอีกวิธีหนึ่งของการประมวลผล
ใช้ NLP กับ Generative AI พร้อมกันได้หรือไม่
ได้ เช่น แยก Intent เพื่อเลือก Flow แล้วใช้ LLM ช่วยอธิบายเอกสารใน Flow นั้น แต่ต้องกำกับสิทธิ์และตรวจความถูกต้องของคำตอบเสมอ
ทำไมไม่ใช้ AI ทั้งหมดตั้งแต่ต้น
บางงานต้องการผลลัพธ์คงที่ ตรวจย้อนหลังง่าย และค่าใช้จ่ายคาดการณ์ได้ การเพิ่ม AI ทั้งที่ข้อมูลไม่พร้อมอาจเพิ่มภาระตรวจมากกว่าประโยชน์
แหล่งอ้างอิง
- Google Cloud — Dialogflow CX documentation — Flow, conversational interaction และตัวอย่างวิธีออกแบบ
- OpenAI Developers — Using tools — การเชื่อมโมเดลกับเครื่องมือภายนอก
- OpenAI Developers — Function calling — วิธีให้แอปรับและตรวจคำขอเรียกฟังก์ชัน
ตรวจเอกสารต้นทาง: 2 พฤศจิกายน 2026; ตัวอย่างและตารางเป็นการวิเคราะห์เชิงออกแบบ ไม่ใช่ผลทดสอบผลิตภัณฑ์
เลือกหัวข้อที่เกี่ยวข้องเพื่อทำความเข้าใจแนวคิดและข้อจำกัดก่อนนำไปใช้จริง
ดูบทความหมวดเทคโนโลยี ↗
