ความรู้พื้นฐาน LLM API: บทบาทคำขอ การตอบกลับ และข้อความ

กำไร:

• สามารถอธิบายโครงสร้างพื้นฐานของคำขอ LLM API (จุดสิ้นสุด, โมเดล, ข้อความ, max_tokens)
• เข้าใจความแตกต่างระหว่างบทบาทของระบบ ผู้ใช้ และผู้ช่วย และประวัติการสนทนาแบบไร้สถานะ
• สามารถอ่านและตีความฟิลด์ (บล็อกเนื้อหา, stop_reason, การใช้งาน) ของการตอบกลับที่ส่งคืนได้

ในโมดูลก่อนหน้านี้ เราใช้ปัญญาประดิษฐ์จากหน้าต่างแชท แต่ถ้าคุณต้องการฝัง AI ลงในผลิตภัณฑ์ ระบบอัตโนมัติ หรือเวิร์กโฟลว์ของคุณเอง อินเทอร์เฟซการแชทจะไม่ตัดการทำงานดังกล่าว คุณต้องเชื่อมต่อกับโมเดลโดยทางโปรแกรม กล่าวคือ ด้วยโค้ดหรือเครื่องมืออัตโนมัติ ชื่อของบริดจ์นี้คือ API (Application Programming Interface ซึ่งเป็นสัญญาที่อนุญาตให้ซอฟต์แวร์สองตัวพูดคุยกับกฎบางอย่าง) เมื่อคุณจบหน่วยนี้ คุณจะรู้ว่าคำขอ API LLM (Large Language Model) คืออะไร บทบาทของข้อความทำหน้าที่อะไร และจะอ่านคำตอบได้อย่างไร นี่คือรากฐานที่จะสร้างส่วนที่เหลือของโมดูล

API ทำงานอย่างไร?

ขั้นตอนพื้นฐานใน API คือ: คุณส่งคำขอในรูปแบบใดรูปแบบหนึ่ง เซิร์ฟเวอร์ส่งคืนการตอบกลับในรูปแบบเฉพาะ ใน LLM โดยปกติจะเป็นการเรียก HTTP (HTTP: โปรโตคอลมาตรฐานสำหรับการดำเนินการตอบสนองคำขอบนเว็บ) ไปยังที่อยู่เดียว (จุดสิ้นสุด ที่อยู่คงที่บนเซิร์ฟเวอร์ที่จัดการคำขอของคุณ) ตัวอย่างเช่น ใน API การส่งข้อความ คำขอทั้งหมดจะส่งไปยังที่อยู่เดียวและดำเนินการในส่วนเนื้อหาเป็น JSON (JavaScript Object Notation — รูปแบบข้อความที่ประกอบด้วยคู่คีย์/ค่าที่ทั้งมนุษย์และเครื่องจักรสามารถอ่านได้)

ในคำขอ คุณระบุอย่างน้อยสามสิ่งนี้:

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

ทีละขั้นตอน: วิธีการตั้งค่าคำขอ

1. เตรียมจุดสิ้นสุดและข้อมูลรับรอง คุณเพิ่มคีย์ API ของคุณ (สตริงลับที่พิสูจน์ตัวตนของคุณ) ไปยังคำขอในส่วนหัว คุณไม่เคยฝังคีย์ไว้ในโค้ด เราจะครอบคลุมพื้นที่จัดเก็บที่ปลอดภัยในหน่วยที่ 9
2. เลือกรุ่นและขีดจำกัดเอาท์พุต รุ่นน้ำหนักเบา + max_tokens ขนาดเล็กสำหรับงานง่ายๆ โมเดลที่ทรงพลัง + ขีดจำกัดที่มากขึ้นสำหรับงานที่ซับซ้อน
3. ตั้งค่ารายการข้อความ List the system instruction, user message, and past rounds (if any).
4. ส่งคำขอและแยกวิเคราะห์การตอบกลับ อ่านเนื้อหาข้อความ เหตุผลในการหยุด และการใช้โทเค็นจาก JSON ที่ส่งคืน

บทบาทข้อความ: ระบบ ผู้ใช้ ผู้ช่วย

การสนทนาประกอบด้วยข้อความที่จัดเรียงตามลำดับ และแต่ละข้อความมีบทบาท บทบาทจะกำหนดวิธีที่โมเดลปฏิบัติต่อข้อความนั้น

บทบาท

ใครเขียน

วัตถุประสงค์

ระบบ

นักพัฒนา/ผู้ดำเนินการ

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

ผู้ใช้

ผู้ใช้ปลายทาง

คำถามหรือข้อมูลปัจจุบันของผู้ใช้

ผู้ช่วย

รุ่น

การตอบสนองที่สร้างโดยแบบจำลอง (และการตอบกลับก่อนหน้า)

บทบาทของระบบมีให้ใช้งานเป็นฟิลด์ระบบแยกต่างหากในเนื้อหาคำขอของผู้ให้บริการส่วนใหญ่ ผู้ใช้และผู้ช่วยจะแสดงรายการตามลำดับในรายการข้อความ Critical point: the system instruction is the high-level instruction, the user message is the request to be answered at that moment.

{ "model": "claude-opus-4-8", "max_tokens": 1024, "system": "คุณเป็นผู้ช่วยสนับสนุนองค์กร ให้คำตอบสั้นๆ เป็นทางการและตรวจสอบได้ อย่าสร้างข้อมูลที่คุณไม่แน่ใจ", "messages": [ { "role": "user", "content": "ฉันจะเริ่มกระบวนการคืนสินค้าได้อย่างไร" } ]}

คำพูดไม่มีสถานะ

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

{ "model": "claude-opus-4-8", "max_tokens": 512, "messages": [ { "role": "user", "content": "สวัสดี ฉันชื่อเดนิซ" }, { "role": "assistant", "content": "สวัสดีเดนิซ ฉันจะช่วยคุณได้อย่างไร" }, { "role": "user", "content": "ฉันเพิ่งพูดชื่อของฉัน คุณจำได้ไหม" } ]}

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

เคล็ดลับ: ในการสนทนาที่ยาวนาน การสรุปและการย้ายรอบเก่า (สรุป + สองสามรอบล่าสุด) แทนที่จะส่งประวัติทั้งหมดจะช่วยลดต้นทุนและรักษาหน้าต่างบริบทไว้ เราจะเจาะลึกเรื่องนี้ในหน่วยที่ 6 และ 11

อ่านคำตอบ

เมื่อโมเดลตอบกลับ คุณจะได้รับออบเจ็กต์ที่มีโครงสร้าง ไม่ใช่ข้อความธรรมดา พื้นที่ทั่วไป:

{ "id": "msg_01ABC...", "model": "claude-opus-4-8", "role": "assistant", "content": [ { "type": "text", "text": "หากต้องการเริ่มการคืนสินค้า ให้ไปที่หน้า 'คำสั่งซื้อของฉัน' ในบัญชีของคุณ..." } ], "stop_reason": "end_turn", "usage": { "input_tokens": 47, "output_tokens": 88 }}

• เนื้อหา: การตอบสนอง; เป็นรายการบล็อกเนื้อหา ช่องข้อความของบล็อกข้อความคือคำตอบที่แท้จริง
• stop_reason: เหตุใดโมเดลจึงหยุดทำงาน end_turn = จุดสิ้นสุดตามธรรมชาติ; max_tokens = ติดอยู่ที่ขีดจำกัดเอาต์พุต (การตอบสนองอาจไม่สมบูรณ์); refusal = ถูกปฏิเสธด้วยเหตุผลด้านความปลอดภัย รหัสของคุณควรดูที่ stop_reason ก่อนเสมอ
• การใช้งาน: หมายเลขโทเค็นอินพุตและเอาต์พุต เป็นพื้นฐานของการติดตามต้นทุนและขีดจำกัด

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

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

งานเดียวกันกับพร้อมท์ระบบที่แตกต่างกันสองระบบ:

#อ่อนแอคุณคือผู้ช่วย ตอบคำถาม

# STRONGคุณเป็นผู้ช่วยสนับสนุนองค์กร กฎเกณฑ์:- อาศัยข้อมูลในเอกสารกรมธรรม์ที่ให้ไว้เท่านั้น หากไม่มีอยู่ในเอกสาร ให้พูดว่า "ฉันไม่มีข้อมูลนี้ ฉันกำลังส่งไปยังหน่วยงานที่เกี่ยวข้อง" - คำตอบไม่ควรเกิน 3 ประโยค เป็นทางการและชัดเจน - ห้ามถามข้อมูลส่วนบุคคล (หมายเลข TC ID, หมายเลขบัตร) และอย่าทำซ้ำ - อย่าเดาเมื่อคุณไม่แน่ใจ

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

มินิเคสสามอัน

กรณีที่ 1 — บอทสนับสนุน (กับดักการไร้สัญชาติ) ทีมอีคอมเมิร์ซนำบอทไปใช้จริง เมื่อผู้ใช้แจ้งว่า "ยกเลิกคำสั่งซื้อก่อนหน้า" บอทจะ "ลืม" หมายเลขคำสั่งซื้อ เหตุผล: พวกเขาส่งคำขอแต่ละรายการโดยมีเพียงข้อความสุดท้ายเท่านั้น วิธีแก้ไข: พวกเขาเพิ่ม 6 รอบล่าสุดในรายการข้อความ ผลลัพธ์: บริบทถูกรักษาไว้ แต่อินพุตต่อคำขอเพิ่มขึ้นจาก 40 โทเค็นเป็น ~ 600 โทเค็น เราจะครอบคลุมบทเรียนต้นทุนในหน่วยที่ 2

กรณีที่ 2 — สรุปสัญญาไม่สมบูรณ์ ทีมกฎหมายกำลังจัดทำสัญญา 10 หน้า; max_tokens: 300 ยังคงต่ำ ข้อมูลสรุปถูกตัดออกจากประโยคกลาง stop_reason คือ max_tokens ทุกครั้ง แต่ไม่มีใครมองหา เพิ่ม max_tokens เป็น 1,500 และเพิ่มการตรวจสอบ stop_reason อัตราสรุปที่ถูกตัดทอนลดลงจาก 18% เป็น 0%

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

ข้อผิดพลาดทั่วไป

• ลืมส่งอดีต นึกว่าโมเดล "จำไม่ได้"; ในขณะที่มันไร้สัญชาติ คุณดำเนินบริบท
• ไม่ได้ดูที่ `stop_reason`: การตอบสนองที่หยุดด้วย max_tokens ถือว่าเสร็จสมบูรณ์
• การฝังคำสั่งใน `user`: กฎถาวรเข้าสู่ระบบ อินพุตทันทีไปที่ผู้ใช้ การผสมทำให้เกิดช่องโหว่ด้านความปลอดภัย
• การเข้าใจผิดว่า `เนื้อหา` เป็นสตริงธรรมดา: คำตอบคือรายการบล็อก อ่านฟิลด์ข้อความของบล็อกข้อความแรก ตรวจสอบประเภทของบล็อกก่อนที่จะรับเนื้อหา [0] ด้วยดัชนีตาบอด
• การฝังคีย์ในโค้ด: ใช้ตัวแปรสภาพแวดล้อม (หน่วย 9)

เจาะลึก: บล็อกเนื้อหาและคำตอบแบบหลายส่วน

การทำความเข้าใจว่าเหตุใดฟิลด์เนื้อหาในการตอบกลับจึงเป็นรายการถือเป็นพื้นฐานของคุณลักษณะขั้นสูงที่คุณจะพบในภายหลัง บางครั้งโมเดลจะส่งกลับไม่ใช่บล็อกข้อความเดียว แต่ส่งกลับหลายบล็อก: บล็อกการคิด ตามด้วยบล็อกข้อความ หรือบล็อกข้อความตามด้วยบล็อกการใช้เครื่องมือ ด้วยเหตุนี้การนับเนื้อหา[0]แบบสุ่มสี่สุ่มห้าว่าเป็น "คำตอบ" จึงเปราะบาง วิธีที่ถูกต้องคือการดูรายการและจัดเรียงตามประเภท: คุณรวบรวมเนื้อหาข้อความของบล็อกที่มีฟิลด์ประเภทเป็นข้อความ และแยกประเภทอื่น ๆ (การคิด เครื่องมือ) ออกจากกัน

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

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

โดยสรุป

คำขอ LLM API ประกอบด้วยโมเดล ขีดจำกัดเอาต์พุต และรายการข้อความ บทบาท (ระบบ ผู้ใช้ ผู้ช่วย) กำหนดพฤติกรรมของแบบจำลอง การโทรไม่มีสถานะ: คุณนำบริบทไปพร้อมกับคำขอแต่ละรายการ การตอบสนองเป็นวัตถุที่มีโครงสร้าง การอ่านและการตีความเนื้อหา, stop_reason และช่องการใช้งานเป็นพื้นฐานของความคงทนในการใช้งานจริง

งานสมัคร

เลือกงานจากอาชีพของคุณเอง (เช่น การจัดเรียงอีเมลที่เข้ามา การสร้างบทสรุปโดยย่อ) บนกระดาษ: (1) เขียนพรอมต์ของระบบด้วยกฎ 4-5 ข้อ (2) ตั้งค่าข้อความผู้ใช้ตัวอย่างและประวัติ 2 รอบ ถ้ามี (3) กำหนดค่าที่เหมาะสมสำหรับ max_tokens และเขียนเหตุผล (4) แสดงรายการค่า stop_reason ที่คุณจะจัดการในการตอบสนองที่ส่งคืนและอย่างไร

รายการตรวจสอบ

• [ ] ฉันสามารถนับสามส่วนที่บังคับของคำขอได้ (model, max_tokens, Messages)
• [ ] ฉันสามารถอธิบายความแตกต่างระหว่างบทบาทของระบบ ผู้ใช้ และผู้ช่วยได้
• [ ] ฉันรู้ว่าการโทรนั้นไร้สัญชาติ และฉันต้องจมอยู่กับอดีต
• ฉันสามารถอ่านและแสดงความคิดเห็นเกี่ยวกับเนื้อหา [ ], stop_reason และช่องการใช้งานได้
• [ ] ด้วย max_tokens ฉันสามารถสังเกตเห็นและจัดการกับการตอบสนองที่ถูกตัดทอน