การผลิตแบบครบวงจร: การทวนสอบ การติดตาม และจริยธรรม

กำไร:

• สามารถออกแบบสถาปัตยกรรมแบบ end-to-end ที่นำคุณลักษณะ LLM จากแนวคิดไปสู่การผลิต
• สร้างเลเยอร์ของการบังคับใช้การตรวจสอบ การอนุมัติโดยมนุษย์ และการติดตาม (การบันทึก/ตัวชี้วัด)
• ขอบเขตแปลหลักจริยธรรมและความเป็นส่วนตัวเป็นการตัดสินใจด้านการผลิต

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

เลเยอร์ของสถาปัตยกรรมการผลิต

คุณสมบัติ LLM ที่มั่นคงประกอบด้วยประมาณห้าชั้น:

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

เลเยอร์เหล่านี้เป็นไปป์ไลน์ แต่ละคนจะตรวจสอบผลลัพธ์ของอันก่อนหน้า

เหตุใดจึงต้องมีการยืนยัน?

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

ชั้นการตรวจสอบ (เพิ่มขึ้นตามผลกระทบ):

• การตรวจสอบความถูกต้องของรูปแบบ/สคีมา: ผลลัพธ์สอดคล้องกับสคีมา JSON ที่คาดไว้หรือไม่ (ผลลัพธ์ที่มีโครงสร้างรับประกันสิ่งนี้เป็นส่วนใหญ่)
• การตรวจสอบกฎ/ตรรกะ: ค่าต่างๆ สมเหตุสมผลหรือไม่ (จำนวนเงินเป็นลบ, เป็นวันที่ในอนาคต, หมวดหมู่ถูกต้องหรือไม่)
• การตรวจสอบแหล่งที่มา: การอ้างสิทธิ์อิงตามเอกสารที่ให้มาหรือไม่ โมเดลพูดอะไรบางอย่างที่ไม่ได้อยู่ในเอกสารหรือไม่?
• การอนุมัติจากมนุษย์: ผู้เชี่ยวชาญจะตรวจสอบการตัดสินใจที่มีผลกระทบสูงหรือคลุมเครือ

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

มนุษย์ในวง

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

ผลกระทบของการตัดสินใจ

แนวทาง

ต่ำ (ข้อเสนอแนะฉลาก ฉบับร่าง)

ระบบอัตโนมัติเต็มรูปแบบ ข้อผิดพลาดมีราคาถูกและสามารถย้อนกลับได้

ปานกลาง (การกำหนดเส้นทาง การจัดลำดับความสำคัญ)

ระบบอัตโนมัติ + การควบคุมการสุ่มตัวอย่าง

สูง (เงิน สัญญา สุขภาพ การลบล้าง)

ต้องได้รับความยินยอมจากมนุษย์ โมเดลแนะนำเท่านั้น

การตรวจสอบ: คุณไม่สามารถจัดการสิ่งที่คุณไม่เห็นได้

ในการผลิต คุณต้องตรวจสอบทุกการโทร หากไม่มีการตรวจสอบ คุณจะไม่สามารถปรับปรุงต้นทุน คุณภาพ หรือตรวจพบปัญหาได้ตั้งแต่เนิ่นๆ ตัวชี้วัดหลักที่จะบันทึก:

• การใช้งาน/ต้นทุน: ต่อคำขอและโทเค็นทั้งหมด การกระจายโมเดล การใช้จ่ายรายวัน
• เวลาแฝง: เวลาตอบสนองโดยเฉลี่ยและกรณีที่แย่ที่สุด
• อัตราข้อผิดพลาด: อัตรา 429/500 การลองใหม่ การละทิ้ง
• คุณภาพ: อัตราเอาต์พุตที่ถูกปฏิเสธที่ชั้นการตรวจสอบ อัตราการแก้ไขเมื่อได้รับการอนุมัติจากมนุษย์ ความคิดเห็นของผู้ใช้

เคล็ดลับ: อย่าเขียนข้อมูลที่ละเอียดอ่อน (ข้อมูลส่วนบุคคล คีย์) ลงในบันทึกการตรวจสอบ พิจารณาบันทึกภายในขอบเขตการรักษาความลับ บันทึกโดยการปิดบังหากจำเป็น (หน่วยที่ 9)

จริยธรรมและขอบเขต

ความรับผิดชอบด้านจริยธรรมเป็นส่วนหนึ่งของการตัดสินใจในการผลิตพอๆ กับความถูกต้องทางเทคนิค:

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

เทมเพลตที่คัดลอกได้

# รายการตรวจสอบการตรวจสอบ (หลังการสร้างเอาต์พุต)1) สคีมาถูกต้องหรือไม่ (การตรวจสอบความถูกต้องของเอาต์พุตที่มีโครงสร้าง)2) ค่าต่างๆ สมเหตุสมผลหรือไม่? (ตรวจสอบกฎ: ช่วง, วันที่, แจงนับ)3) การอ้างสิทธิ์ขึ้นอยู่กับแหล่งที่มาหรือไม่ (ปฏิเสธหากไม่ได้อยู่ในเอกสาร)4) ผลกระทบสูงหรือไม่? → ส่งเพื่อขออนุมัติจากมนุษย์5) หากผ่านทั้งหมด → อนุญาต ให้ดำเนินการบันทึก

# ระบบแจ้งว่ากองกำลังอาศัยแหล่งที่มาอาศัยข้อมูลในเอกสารที่ให้มาเท่านั้น อย่าเพิ่มสิ่งใดที่ไม่ได้อยู่ในเอกสาร หากไม่มีข้อมูลในเอกสาร ให้เขียนว่า "ไม่พบในเอกสาร" อย่าเดาหรือสร้างสิ่งต่าง ๆ

# เกณฑ์การอนุมัติของมนุษย์ (กฎการตัดสินใจ) หากประเภทการตัดสินใจใน [เงิน สัญญา ลบ สุขภาพ] → การอนุมัติของมนุษย์บังคับ IF model_trust < เกณฑ์หรือการตรวจสอบ "ไม่แน่นอน" → ส่งไปยังการอนุมัติของมนุษย์ OTHER → ใช้อัตโนมัติ + การควบคุมการสุ่มตัวอย่าง

# เทมเพลตบันทึกการติดตาม (การเขียนข้อมูลที่ละเอียดอ่อน){ "time": "...", "model": ", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":...", "การรับรองความถูกต้อง": "ผ่าน | ถูกปฏิเสธ | มนุษย์", "cost_usd":... } // ข้อมูลส่วนบุคคลและคีย์ไม่เคยถูกเขียน

พร้อมท์อ่อนแอ / พร้อมท์แข็งแกร่ง (ความน่าเชื่อถือในการผลิต)

# อ่อนแอ (ไม่มีการตรวจสอบ ไม่มีแหล่งที่มา ใช้โดยอัตโนมัติ) ประเมินคำขอนี้ ตัดสินใจคืนเงิน และนำไปใช้

# แข็งแกร่ง (ตามแหล่งที่มา สร้างคำแนะนำ ปล่อยให้มนุษย์อนุมัติ) ประเมินคำขอคืนสินค้านี้ตามเอกสารนโยบายการคืนสินค้าเท่านั้น แนะนำการตัดสินใจโดยมีเหตุผลแต่อย่านำไปใช้: {"recommendation": "อนุมัติ|ปฏิเสธ" "เหตุผล"... "policy_clause" "..."} หากไม่มีพื้นฐานที่ชัดเจนในเอกสารนโยบาย ให้ระบุ "ไม่ชัดเจน" ตัวแทนจะอนุมัติการตัดสินใจขั้นสุดท้าย

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

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

กรณีที่ 1 — วันที่บันทึกเลเยอร์การยืนยัน Fintech กำลังใช้โมเดลในการจำแนกคำอธิบายธุรกรรมและสร้างบันทึกทางบัญชีอัตโนมัติ พวกเขาเพิ่มการตรวจสอบกฎ: เมื่อแบบจำลองส่งออกจำนวนเงินไม่ถูกต้อง (12,500 แทนที่จะเป็น 1,250 ในเอกสาร) กฎ "จำนวนเงินไม่ตรงกับเอกสาร" จะปฏิเสธเอาต์พุตและบันทึกตกอยู่กับมนุษย์ หากไม่มีการตรวจสอบ บันทึกที่ไม่ถูกต้องจะเข้าสู่ระบบอย่างเงียบๆ

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

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

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

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

เจาะลึกยิ่งขึ้น: การจัดการรีลีส การย้อนกลับ และการปรับใช้ส่วนเพิ่ม

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

การกำหนดเวอร์ชัน ข้อความแจ้งของระบบ การเลือกรุ่น และกฎการตรวจสอบเปลี่ยนแปลงไปตามกาลเวลา จัดทำการเปลี่ยนแปลงที่สำคัญแต่ละเวอร์ชันและบันทึกเวอร์ชันที่ใช้งานจริง หากวันหนึ่งคุณภาพลดลง “เราเปลี่ยนแปลงอะไรไปบ้าง?” คุณควรจะสามารถตอบคำถามได้ภายในไม่กี่นาที ในระบบที่ไม่มีเวอร์ชัน การค้นหาสาเหตุของการถดถอยต้องใช้เวลาหลายวัน

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

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

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

โดยสรุป

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

งานสมัคร

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

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

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

การสอบโมดูล

1. บทบาทของ 'ระบบ' ทำหน้าที่อะไรใน LLM chat API

• A) ให้คำแนะนำอย่างถาวรแก่โมเดลและกฎเกณฑ์พฤติกรรมที่ใช้ตลอดการสนทนาทั้งหมด ✔
• B) เก็บคำถามสุดท้ายที่เขียนโดยผู้ใช้
• C) เก็บการตอบสนองที่สร้างโดยแบบจำลอง
• D) เข้ารหัสคีย์ API

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

2. เหตุใดประวัติการสนทนา (ข้อความก่อนหน้า) จึงถูกส่งอีกครั้งในคำขอ API

• A) จำเป็นต้องสำรองข้อมูลเนื่องจากเซิร์ฟเวอร์ลบประวัติ
• B) การเรียก API นั้นไร้สัญชาติ ✔ บริบทจะถูกส่งใหม่ในทุกคำขอเนื่องจากโมเดลไม่จำประวัติ
• C) จำเป็นสำหรับการออกใบแจ้งหนี้เท่านั้น ไม่มีผลกระทบต่อแบบจำลอง
• D) จำเป็นต้องส่งประวัติเพื่อหลีกเลี่ยงการตอบกลับช้าลง

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

3. 'โทเค็น' ในราคา LLM คืออะไร

• A) รหัสผ่านแบบใช้ครั้งเดียวที่ใช้ในการเข้าสู่ระบบ API
• B) ค่าธรรมเนียมคงที่ที่ชำระในแต่ละคำขอ
• C) หน่วยที่เล็กที่สุดที่โมเดลประมวลผลข้อความ มักจะตรงกับส่วนของคำ ✔
• D) หน่วยที่วัดเฉพาะความยาวของเอาต์พุต

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

4. เหตุใดโทเค็นเอาท์พุตจึงมีราคาแพงกว่าโทเค็นอินพุตที่ผู้ให้บริการ LLM ส่วนใหญ่

• A) โทเค็นเอาต์พุตจะยาวกว่าอินพุตเสมอ
• B) โทเค็นอินพุตฟรี
• C) โทเค็นเอาท์พุตจะถูกส่งสองครั้งทางอินเทอร์เน็ต
• D) ต้นทุนต่อหน่วยสูงขึ้นเนื่องจากการสร้างเอาต์พุตต้องมีการคำนวณเพิ่มเติมสำหรับแต่ละโทเค็น ✔

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

5. การใช้สตรีมมิ่งมีประโยชน์มากที่สุดในสถานการณ์ใด?

• ก) ในคำตอบยาว ๆ ลดความล่าช้าในการรับรู้และป้องกันการหมดเวลา ✔
• B) คำตอบสั้น ๆ เพียงคำเดียวเท่านั้น
• C) เพื่อลดต้นทุนให้เป็นศูนย์
• D) เพื่อซ่อนคีย์ API

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

6. โดยทั่วไปการเพิ่มพารามิเตอร์ 'ความพยายาม' ในโมเดลสมัยใหม่จะส่งผลต่ออะไร?

• ก) ย่อคำตอบให้สั้นลงเสมอ
• B) หมุนคีย์ API โดยอัตโนมัติ
• C) ลดราคาโทเค็นอินพุตเท่านั้น
• D) เพิ่มความลึกของการคิดและการใช้จ่ายโทเค็น อาจปรับปรุงคุณภาพ แต่ยังเพิ่มเวลาแฝงและต้นทุนด้วย ✔

คำอธิบาย: พารามิเตอร์ความพยายามจะปรับความลึกที่แบบจำลองจะคิดเกี่ยวกับงานและจำนวนโทเค็นที่จะใช้ การอัปเกรดอาจปรับปรุงคุณภาพ แต่ยังเพิ่มเวลาแฝงและต้นทุนด้วย สำหรับงานง่ายๆ ความพยายามต่ำก็เพียงพอแล้ว

7. โดยทั่วไปแล้วแนวทางใดที่คุ้มค่าที่สุดสำหรับงานจำแนกประเภทที่เรียบง่ายและมีปริมาณมาก?

• A) ใช้รุ่นที่แพงที่สุดและทรงพลังที่สุดเสมอ
• B) การเรียกทุกรุ่นพร้อมกันสำหรับแต่ละคำขอ
• C) การเลือกรุ่นที่เบาที่สุด/ถูกที่สุดที่ทำให้งานสำเร็จโดยการตรวจสอบด้วยการประเมินเล็กน้อย ✔
• D) รักษาค่า max_tokens สูงเกินไปโดยไม่จำเป็น

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

8. ในสถานการณ์ใดที่การแคชพร้อมท์ช่วยลดต้นทุนได้มากที่สุด

• A) เมื่อมีการใช้บริบทขนาดใหญ่และคงที่ซ้ำๆ กับคำขอจำนวนมาก ✔
• B) เมื่อมีการส่งข้อความที่แตกต่างไปจากเดิมอย่างสิ้นเชิงพร้อมกับคำขอแต่ละรายการ
• C) เมื่อมีการร้องขอเพียงครั้งเดียว
• D) เพื่อลดโทเค็นเอาต์พุต

คำอธิบาย: การแคชเป็นการจับคู่คำนำหน้า ในกรณีที่บริบทขนาดใหญ่ที่ไม่สามารถเปลี่ยนแปลงได้ (พรอมต์ของระบบ เอกสาร) ถูกนำมาใช้ซ้ำกับคำขอจำนวนมาก การอ่านจากแคชจะมีค่าเพียงเล็กน้อย (~0.1x) ของราคาเต็ม

9. ฉันจะแก้ไขพรอมต์เพื่อให้แคชของพรอมต์เข้าถึงได้อย่างไร

• A) การใส่เนื้อหาตัวแปรไว้ที่จุดเริ่มต้นและกำหนดเนื้อหาไว้ที่ตอนท้าย
• B) ฝังวันที่และเวลาปัจจุบันในระบบพร้อมท์สำหรับแต่ละคำขอ
• C) ใส่เนื้อหาคงที่ (พรอมต์ของระบบ เอกสาร) ที่จุดเริ่มต้นและเนื้อหาตัวแปรที่ส่วนท้าย ✔
• D) การเปลี่ยนลำดับของรายการเครื่องมือตามคำขอแต่ละครั้ง

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

10. การประมวลผลแบบเป็นชุดเหมาะสมที่สุดสำหรับปริมาณงานประเภทใด

• A) แชทสดที่ผู้ใช้คาดหวังการตอบกลับทันทีบนหน้าจอ
• B) คำถามสั้นๆ เพียงข้อเดียว
• C) การสร้างคีย์ API
• D) งานที่ทนต่อความล่าช้า ปริมาณมาก และไม่ต้องการผลลัพธ์ทันที ✔

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

11. สิ่งใดที่ใช้เพื่อจับคู่คำขอผลลัพธ์ที่อยู่ในชุดอย่างมั่นใจ?

• A) การส่งคำสั่ง (ตำแหน่ง) ของคำขอ
• B) ความยาวของคำตอบ
• C) ตัวเลข 4 หลักสุดท้ายของคีย์ API
• D) custom_id ที่ไม่ซ้ำกันซึ่งมอบให้กับคำขอแต่ละรายการ✔

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

12. ลักษณะการทำงานที่แนะนำเมื่อคุณได้รับข้อผิดพลาด 429 (ขีดจำกัดอัตรา) จาก API คืออะไร

• ก) การบังคับโดยส่งคำขอหลายรายการพร้อมกัน
• B) ลองอีกครั้งโดยใช้ Exponential Backoff ตามหัวข้อ Retry-After ✔
• C) ยกเลิกคำขอทั้งหมดและแสดงข้อผิดพลาดว่าเป็นข้อขัดข้องต่อผู้ใช้
• D) การเปลี่ยนคีย์ API

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

13. รหัสข้อผิดพลาด HTTP ใดต่อไปนี้โดยทั่วไปถือว่าสามารถลองใหม่ได้

• A) 400 (คำขอไม่ถูกต้อง)
• B) 401 (ข้อผิดพลาดในการตรวจสอบสิทธิ์)
• C) 529 (เซิร์ฟเวอร์โอเวอร์โหลด) ✔
• D) 404 (ไม่พบ)

คำอธิบาย: 429 (จำกัดความเร็ว), 500 (ข้อผิดพลาดของเซิร์ฟเวอร์) และ 529 (โอเวอร์โหลด) เป็นข้อผิดพลาดชั่วคราวและสามารถลองใหม่ได้โดยการสำรองข้อมูล ข้อผิดพลาดเช่น 400 และ 401 เป็นปัญหาเกี่ยวกับคำขอ/ข้อมูลระบุตัวตน ลองใหม่อีกครั้งก็แก้ไม่ได้

14. ข้อใดต่อไปนี้คือวิธีที่ปลอดภัยในการจัดการคีย์ API

• A) การจัดเก็บตัวแปรสภาพแวดล้อม/ตัวจัดการที่ซ่อนอยู่ โดยไม่ได้ฝังไว้ในโค้ดและหมุนเวียนเป็นประจำ ✔
• B) เขียนคีย์ลงในซอร์สโค้ดโดยตรงและส่งไปยังที่เก็บ
• C) การใส่คีย์ใน JavaScript ฝั่งไคลเอ็นต์ (เบราว์เซอร์)
• D) การแชร์คีย์เดียวกับทั้งทีมผ่านทางอีเมล

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

15. อะไรคือวิธีที่ดีที่สุดในการรวม LLM กับเครื่องมืออัตโนมัติ (n8n, Zapier, Make) ในแง่ของความเป็นส่วนตัว?

• A) การส่งข้อมูลดิบทั้งหมดไปยังโมเดล แม้ว่าจะไม่จำเป็นก็ตาม
• B) การเขียนคีย์ API เป็นข้อความธรรมดาภายในขั้นตอนโฟลว์
• C) การลดขนาดและปกปิดข้อมูลที่ละเอียดอ่อนและจัดเก็บคีย์ไว้เป็นความลับ ✔
• D) การรักษาข้อมูลส่วนบุคคลอย่างถาวรในประวัติโฟลว์

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

16. เหตุใดจึงต้องมีการตรวจสอบความถูกต้องของเอาต์พุตในคุณลักษณะการผลิตที่ใช้ LLM

• A) ต้องมีการจัดรูปแบบเท่านั้นเนื่องจากโมเดลไม่เคยทำผิดพลาด
• B) เนื่องจากแบบจำลองสามารถผลิตได้อย่างลื่นไหลแต่บางครั้งก็ไม่ถูกต้อง สคีมา/กฎต้องได้รับการตรวจสอบโดยทรัพยากรและการอนุมัติจากมนุษย์ ✔
• C) ควรหลีกเลี่ยงการตรวจสอบความถูกต้องเนื่องจากจะทำให้ต้นทุนเพิ่มขึ้นเท่านั้น
• D) การตรวจสอบเป็นเพียงการลดจำนวนโทเค็นเท่านั้น

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