Function Calling ใน OpenAI API: ทำงานอย่างไรจริงๆ และใช้อย่างไรให้ถูกต้อง

คุณส่งข้อความของผู้ใช้ไปยัง GPT API แล้วแทนที่จะได้คำตอบเป็นภาษาธรรมชาติ โมเดลกลับส่งวัตถุ JSON ที่มีโครงสร้างกลับมาบอกคุณอย่างละเอียดว่าควรเรียกฟังก์ชันใดและส่งอาร์กิวเมนต์อะไร นั่นคือการเรียกใช้ฟังก์ชัน — และมันเปลี่ยนประเภทของแอปพลิเคชันที่คุณสามารถสร้างด้วย LLM ได้

นักพัฒนาส่วนใหญ่ได้ยินคำว่า "function calling" แล้วคิดว่าโมเดลกำลังรันโค้ดแทนพวกเขา ความจริงไม่ใช่

เมื่อใช้การเรียกใช้ฟังก์ชัน ตัว LLM เองจะไม่รันฟังก์ชัน แต่จะระบุฟังก์ชันที่เหมาะสม รวบรวมพารามิเตอร์ที่ต้องใช้ทั้งหมด แล้วส่งข้อมูลในรูปแบบ JSON ที่มีโครงสร้าง

แอปพลิเคชันของคุณยังคงต้องรับผิดชอบในการรันลอจิกจริง โมเดลเพียงบอกว่าต้องรันอะไรและด้วยอินพุตใด

ความแตกต่างนั้นสำคัญกว่าที่คิด และส่งผลต่อทุกอย่างตั้งแต่วิธีออกแบบสถาปัตยกรรมการผสานระบบไปจนถึงวิธีคิดเรื่องความปลอดภัย

อะไรคือการเรียกใช้ฟังก์ชันจริงๆ — และสิ่งที่ผู้คนมักเข้าใจผิด

การเรียกใช้ฟังก์ชัน (หรือที่เรียกว่าการเรียกใช้เครื่องมือ) เป็นวิธีที่ทรงพลังและยืดหยุ่นสำหรับโมเดลของ OpenAI ในการเชื่อมต่อกับระบบภายนอกและเข้าถึงข้อมูลนอกเหนือจากข้อมูลที่ใช้ฝึกโมเดล

ชื่อเรียกนี่แหละคือความสับสนแรก หลายคนคิดว่าโมเดลกำลังรันบางอย่างอยู่ ซึ่งไม่ใช่

มีชื่อเรียกและคำอธิบายมากมายสำหรับการเรียกใช้ฟังก์ชัน แต่สุดท้ายสรุปได้ว่า: "การเรียกใช้ฟังก์ชันคือความสามารถด้านเอาต์พุตแบบมีโครงสร้างประเภทหนึ่งของโมเดลภาษาขนาดใหญ่" LLM ไม่ได้เรียกฟังก์ชันเอง; มันจะเสนอว่าคุณควรเรียกฟังก์ชันใดจากชุดฟังก์ชันที่คุณกำหนดและให้ไว้ในพรอมป์ต

ความสับสนที่สองเกี่ยวกับ API รูปแบบเก่า

พารามิเตอร์ functions และ function_call ถูกเลิกใช้แล้วพร้อมกับการออกเวอร์ชัน API 2023-12-01-preview ตัวแทนของ functions คือพารามิเตอร์ tools

ถ้าคุณทำตามบทเรียนที่ใช้พารามิเตอร์ functions แสดงว่าคุณกำลังใช้ไวยากรณ์ที่เลิกใช้แล้ว ให้ใช้ tools และ tool_choice แทน

ฟังก์ชันเป็นเครื่องมือชนิดหนึ่ง กำหนดด้วย JSON schema คำจำกัดความของฟังก์ชันช่วยให้โมเดลส่งข้อมูลไปยังแอปของคุณ ซึ่งโค้ดของคุณสามารถเข้าถึงข้อมูลหรือดำเนินการตามที่โมเดลเสนอได้

สคีมานี่เองที่ทำให้การเรียกใช้ฟังก์ชันมีความน่าเชื่อถือเหนือกว่าการพรอมป์ตล้วนๆ — คุณไม่ได้หวังให้โมเดลจัดรูปแบบเอาต์พุตให้ถูกต้อง แต่คุณบังคับใช้โครงสร้างได้ในระดับ API

การทำงานของการเรียกใช้ฟังก์ชันใน OpenAI API — ทีละขั้นตอน

การเรียกใช้เครื่องมือเป็นการสนทนาหลายขั้นตอนระหว่างแอปของคุณและโมเดลผ่าน OpenAI API โฟลว์การเรียกใช้เครื่องมือมี 5 ขั้นตอนหลัก: ส่งคำขอไปยังโมเดลพร้อมรายการเครื่องมือที่มันสามารถเรียกใช้ได้...

นี่คือรายละเอียดของแต่ละขั้นตอนในทางปฏิบัติ

ขั้นที่ 1: กำหนดสคีมาของฟังก์ชันของคุณ คุณอธิบายแต่ละฟังก์ชันที่ใช้ได้เป็นวัตถุ JSON ภายในพารามิเตอร์ tools สคีมาประกอบด้วยชื่อฟังก์ชัน คำอธิบายเป็นภาษาธรรมชาติที่โมเดลใช้ตัดสินใจว่าจะเรียกใช้เมื่อใด และบล็อก parameters ที่ยึดตามมาตรฐาน JSON Schema

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

ขั้นที่ 2: ส่งคำขอ คุณเรียกใช้ Chat Completions API ด้วยข้อความของผู้ใช้และรายการ tools ของคุณ โมเดลจะเห็นทั้งคู่

ขั้นที่ 3: โมเดลตัดสินใจว่าจะเรียกฟังก์ชันหรือไม่

การเรียกฟังก์ชันหมายถึงการตอบสนองแบบพิเศษที่คุณจะได้รับจากโมเดล เมื่อมันตรวจสอบพรอมป์ตและตัดสินว่าต้องเรียกหนึ่งในเครื่องมือที่มีอยู่เพื่อทำตามคำสั่ง ตัวอย่างเช่น หากโมเดลได้รับพรอมป์ตว่า "สภาพอากาศที่ปารีสเป็นอย่างไร?" มันอาจตอบกลับด้วยการเรียกเครื่องมือ get_weather โดยระบุ Paris เป็นอาร์กิวเมนต์ตำแหน่ง

ขั้นที่ 4: โค้ดของคุณรันฟังก์ชัน คุณแยกวิเคราะห์การตอบสนองของโมเดล ดึงชื่อฟังก์ชันและอาร์กิวเมนต์ แล้วรันโค้ดจริงในรันไทม์ของคุณ API ส่งกลับมาเป็น JSON ที่มีโครงสร้าง — คุณตัดสินใจว่าจะทำอย่างไรกับมัน

ขั้นที่ 5: ส่งผลลัพธ์กลับไป

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

— เช่น "สภาพอากาศในปารีสวันนี้คือ 25°C"

รายละเอียดหนึ่งที่บทเรียนส่วนใหญ่มักข้าม:

เมื่อคุณตั้งค่า strict: true ในคำจำกัดความของฟังก์ชัน Structured Outputs จะรับประกันว่าอาร์กิวเมนต์ที่โมเดลสร้างขึ้นสำหรับการเรียกฟังก์ชันจะตรงกับ JSON Schema ที่คุณให้ไว้ทุกประการ

การตั้งค่า strict เป็น true จะทำให้การเรียกฟังก์ชันยึดตามสคีมาอย่างเชื่อถือได้ แทนที่จะเป็นแบบพยายามให้ดีที่สุด OpenAI แนะนำให้เปิดโหมด strict เสมอ

เสมอ ไม่มีเหตุผลดีๆ ที่จะไม่เปิด

นอกจากนี้ยังมีการเรียกฟังก์ชันแบบขนานให้รู้จักด้วย

ขึ้นกับคำถามของผู้ใช้ โมเดลจะเรียกใช้การเรียกฟังก์ชันแบบขนานหากใช้โมเดลรุ่นล่าสุดที่ออกเมื่อวันที่ 6 พฤศจิกายน 2023 หรือหลังจากนั้น

นั่นหมายความว่าคำขอเดียวอย่าง "สภาพอากาศที่ลอนดอนและโตเกียวเป็นอย่างไร?" สามารถกระตุ้นให้เกิดการเรียกเครื่องมือสองครั้งพร้อมกัน แทนที่จะเชื่อมต่อแบบลำดับ

กรณีใช้งานจริงของการเรียกใช้ฟังก์ชัน

ตัวอย่างสภาพอากาศมีอยู่ทั่วไปเพราะมันสะอาด เข้าใจง่าย กรณีใช้งานจริงในโปรดักชันจะเลอะเทอะและน่าสนใจกว่านั้น

เวิร์กโฟลว์สนับสนุนลูกค้าพร้อมข้อมูลเรียลไทม์

การเรียกใช้ฟังก์ชันมีประโยชน์กับกรณีใช้งานมากมาย — เช่น ผู้ช่วย AI ที่ต้องดึงข้อมูลลูกค้าล่าสุดจากระบบภายในเมื่อผู้ใช้ถามว่า "คำสั่งซื้อล่าสุดของฉันคืออะไร?" ก่อนจะสร้างคำตอบ

โมเดลจะจับเจตนา สกัดหมายเลขลูกค้าจากบริบท แล้วเรียก API ภายในของ CRM ของคุณ ไม่ต้องใช้ regex เปราะๆ ไม่ต้องมีเทมเพลตพรอมป์ตที่พังเพราะเครื่องหมายจุลภาคหายไป

การแยกข้อมูลเชิงโครงสร้างในสเกลใหญ่

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

แปลงภาษาธรรมชาติเป็นการเรียก API

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

เวิร์กโฟลว์แบบเอเจนต์ที่มีหลายเครื่องมือ

สำหรับนักพัฒนา การเรียกใช้ฟังก์ชันช่วยให้เข้าถึงข้อมูลเรียลไทม์เพื่อข้ามขีดจำกัดวันตัดข้อมูลฝึกได้ โดยดึงราคาหุ้น สภาพอากาศ หรือรายการฐานข้อมูลล่าสุด และยังช่วยให้ดำเนินการได้จริง — เปลี่ยน LLM จากผู้สังเกตเฉยๆ เป็นผู้ลงมือที่เปลี่ยนสถานะ เช่น ส่งอีเมล อัปเดต CRM หรือดีพลอยโค้ด

ความแตกต่างสำคัญจากแชตบ็อตธรรมดา: โมเดลไม่ได้แค่สร้างข้อความ แต่มันกำลังจัดการปฏิบัติการจริงในระบบของคุณ

แนวทางปฏิบัติที่ดีในการเรียกใช้ฟังก์ชัน — สิ่งที่นักพัฒนามักทำพลาด

ส่วนนี้แหละที่บทเรียนส่วนใหญ่ไม่พูดถึง ทำให้ทีมต้องมานั่งดีบักความล้มเหลวประหลาดๆ ตอนตีสอง

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

เปิดเผยฟังก์ชันมากเกินไปในคราวเดียว

คำอธิบายฟังก์ชันกินจำนวนโทเคนในพรอมป์ตอินพุต

การโหลดคำจำกัดความเครื่องมือมากกว่า 50 รายการใน system prompt สร้าง 2 ปัญหา: ต้นทุนและความหน่วง เพราะคำจำกัดความเครื่องมือกินโทเคนอินพุต; และความแม่นยำลดลง เพราะเมื่อจำนวนตัวเลือกเพิ่มขึ้น ความสามารถของโมเดลในการเลือกเครื่องมือที่ถูกต้องจะลดลง

เริ่มจากชุดฟังก์ชันที่เล็กที่สุดเท่าที่กรณีใช้งานของคุณต้องการจริงๆ

คิดว่าโมเดลจะไม่สร้างพารามิเตอร์ขึ้นมาเอง แต่จะทำ

โมเดลอาจสร้างพารามิเตอร์ขึ้นมาเอง

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

ไม่รองรับลูปหลายเทิร์น นักพัฒนามักสร้างแต่เส้นทางสวยหรู — ผู้ถาม โมเดลเรียกฟังก์ชัน เสร็จ

โมเดลอาจสร้างการเรียกฟังก์ชันที่ไม่ตรงสคีมาที่คุณนิยามไว้ หรือพยายามเรียกฟังก์ชันที่คุณไม่ได้รวมไว้ ถ้าโมเดลสร้างการเรียกฟังก์ชันที่ไม่คาดคิด ให้ลองใส่ประโยคใน system message ว่า "ใช้เฉพาะฟังก์ชันที่คุณได้รับเท่านั้น"

เตรียมรับมือกรณีขอบต่างๆ ไว้เสมอ

ข้ามขั้นตอนยืนยันก่อนการเขียนข้อมูล

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

หากการเรียกฟังก์ชันสามารถลบข้อมูล โอนเงิน หรือแก้ไขสถานะภายนอก ควรมีมนุษย์อนุมัติก่อน

ข้อพิจารณาด้านความปลอดภัยและความน่าเชื่อถือ

การเรียกใช้ฟังก์ชันขยายสิ่งที่ LLM ทำได้ และยังขยายสิ่งที่ผู้โจมตีทำให้มันทำได้ด้วย

ภัยคุกคามหลักคือ prompt injection

เป้าหมายสุดท้ายของการฉีดคำสั่งต่างกันไป แต่อาจรวมถึงการดึงข้อมูลส่วนตัวออกไปผ่านการเรียกเครื่องมือต่อเนื่อง การกระทำที่ไม่สอดคล้องกับเจตนา หรือเปลี่ยนพฤติกรรมของโมเดลโดยไม่ตั้งใจ

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

เมื่อระบบ AI ก้าวไกลกว่าแชตและเริ่มเรียกเครื่องมือและลงมือทำ การฉีดคำสั่งกลายเป็นปัญหาร้ายแรงกว่ามาก คำสั่งที่เป็นอันตรายซ่อนอยู่ในเว็บเพจ เอกสาร หรือเครื่องมือภายนอกสามารถพยายามลบล้างพฤติกรรมระบบ เปิดเผยข้อมูลอ่อนไหว หรือทริกเกอร์การกระทำที่โมเดลไม่ควรทำ

กลยุทธ์ลดความเสี่ยงมีหลายชั้นที่เป็นรูปธรรม

ออกแบบเวิร์กโฟลว์เพื่อไม่ให้ข้อมูลที่ไม่น่าเชื่อถือขับเคลื่อนพฤติกรรมเอเจนต์โดยตรง สกัดเฉพาะฟิลด์เชิงโครงสร้างที่เจาะจง — เช่น enum หรือ JSON ที่ผ่านการตรวจสอบ — จากอินพุตภายนอกเพื่อลดความเสี่ยงจากการฉีดคำสั่งที่ไหลข้ามโมดูล

นอกจากนั้น

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

ความจริงที่ไม่น่าพอใจอย่างหนึ่ง:

"Prompt injection เช่นเดียวกับกลโกงและวิศวกรรมสังคมบนเว็บ ไม่น่าจะถูก 'แก้ได้' อย่างสมบูรณ์"

นั่นคือการประเมินของ OpenAI ผลในทางปฏิบัติคือคุณไม่ควรออกแบบระบบเอเจนต์ที่เรียกใช้ฟังก์ชันโดยสมมติว่าโมเดลจะประพฤติตัวตามที่ตั้งใจไว้เสมอ การป้องกันหลายชั้น — การตรวจสอบความถูกต้อง การจำกัดสิทธิ์ และมีมนุษย์อยู่ในลูปสำหรับการกระทำที่ทำลายล้าง — คือแนวทางที่สมเหตุสมผลเท่านั้น

Function Calling vs. Prompt Engineering — ควรใช้เมื่อไรแบบไหน

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

การทำ Prompt engineering คือการร่างอินพุตข้อความเพื่อชี้นำกระบวนการให้เหตุผลภายในของโมเดล — เช่น ขอให้ "คิดทีละขั้นตอน"

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

การเรียกใช้เครื่องมือคือความสามารถที่ทำให้ LLM โต้ตอบกับระบบภายนอก ในขณะที่คุณใช้ prompt engineering เพื่อช่วยให้โมเดลตัดสินใจว่าใช้เครื่องมือใด การเรียกใช้เครื่องมือคือกลไกที่ทำให้การกระทำนั้นเกิดขึ้นจริง คุณมักต้องใช้ทั้งสองอย่าง แต่ทำหน้าที่ต่างกัน

ความได้เปรียบทางเทคนิคสำคัญของการเรียกใช้ฟังก์ชันเหนือการบังคับรูปแบบด้วยพรอมป์ต:

การเรียกใช้เครื่องมือเป็นแนวคิดที่ฝังอยู่ในโมเดลอยู่แล้ว ไม่ต้องเสียโทเคนและแรงอธิบายให้โมเดลคืนผลในรูปแบบเฉพาะ

เมื่อคุณร่างพรอมป์ตว่า "ส่งคำตอบเป็น JSON ที่มีฟิลด์ X, Y และ Z" คุณกำลังใช้โทเคนไปกับคำสั่งที่โมเดลอาจทำตามอย่างไม่สม่ำเสมอ ด้วยการเรียกใช้ฟังก์ชัน การบังคับใช้สคีมาเกิดขึ้นในระดับ API

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

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

หลักคิดเชิงปฏิบัติ: ถ้าเอาต์พุตต้องไปขับเคลื่อนระบบปลายทาง — เขียนฐานข้อมูล เรียก API แตกกิ่งตัดสินใจในโค้ดของคุณ — ใช้การเรียกใช้ฟังก์ชัน ถ้าเอาต์พุตไว้ให้มนุษย์อ่าน Prompt engineering มักเพียงพอและถูกกว่า

สาระสำคัญที่ควรจำ

หากคุณอยากทดลองการเรียกใช้ฟังก์ชันข้ามโมเดลต่างๆ — GPT-5.4, claude opus 4.7, gemini 3.1 pro — โดยไม่ต้องดูแลคีย์ API แยกต่อโมเดล CometAPI ให้คุณเข้าถึงทั้งหมดผ่านเอนด์พอยต์และคีย์เดียว ช่วยให้การทดสอบข้ามโมเดลลื่นไหลขึ้นอย่างมาก

CometAPI แก้ภาระงานโครงสร้างพื้นฐานให้:

✅ ไวยากรณ์การเรียกใช้ฟังก์ชันแบบเดียวกัน ครอบคลุมกว่า 15+ โมเดล

✅ API key เดียว — ไม่ต้องมีบัญชีแยกสำหรับ OpenAI/Anthropic/Google

✅ แปลสคีมาอัตโนมัติ — เขียนครั้งเดียว ทดสอบได้ทุกที่

✅ ติดตามต้นทุนในตัว — เปรียบเทียบการใช้โทเคนต่อโมเดลแบบเรียลไทม์

เริ่มทดสอบด้วยเครดิตฟรี → รับสิทธิ์เข้าถึง