กำไร:
- กำหนดว่าการประมวลผลแบบแบตช์ปริมาณงานใดเหมาะสำหรับ
- เข้าใจถึงการแลกเปลี่ยนต้นทุน/เวลาแฝงระหว่างการประมวลผลแบบซิงโครนัส อะซิงโครนัส และแบบแบตช์
- ออกแบบเวิร์กโฟลว์แบบแบตช์ที่มีประสิทธิภาพซึ่งจับคู่ custom_id กับผลลัพธ์
การบูรณาการ LLM ส่วนใหญ่มุ่งเน้นไปที่สถานการณ์ "สด" ที่ผู้ใช้กำลังรอการตอบกลับอยู่หน้าจอ แต่ปริมาณงานระดับมืออาชีพส่วนใหญ่ไม่ได้เกิดขึ้นจริง เช่น การแท็กเอกสารหลายพันรายการในชั่วข้ามคืน การสรุปชุดข้อมูลทั้งหมด การจัดประเภทบันทึกการโทรทั้งหมดในไฟล์เก็บถาวร ในเรื่องเหล่านี้ ไม่มีใครคาดหวังคำตอบทันที สิ่งสำคัญคือการจบงานอย่างถูกและเชื่อถือได้ แบทช์นี้เหมาะกับปริมาณงานเหล่านี้ทุกประการ ในหน่วยนี้ คุณจะได้เรียนรู้ความแตกต่างระหว่างการประมวลผลแบบซิงโครนัส อะซิงโครนัส และแบบแบตช์ เมื่อแบทช์เป็นตัวเลือกที่เหมาะสม และโฟลว์ที่มีประสิทธิภาพซึ่งตรงกับ custom_id และผลลัพธ์อย่างมั่นใจ
สามโหมดการทำงาน
โหมด
มันทำงานอย่างไร
ล่าช้า
ค่าใช้จ่ายทั่วไป
งานที่เหมาะสม
ซิงโครนัส
คุณทำการร้องขอและรอการตอบกลับ
วินาที
มาตรฐาน
แชทสด ผู้ช่วยด่วน
แบบอะซิงโครนัส
คุณจัดคิวงานและรับการแจ้งเตือนเมื่องานเสร็จสิ้น
วินาที-นาที
มาตรฐาน
งานเบื้องหลัง ขั้นตอนการทำงานอัตโนมัติ
แบทช์
ส่งคำขอหลายพันรายการในแพ็คเกจเดียว จากนั้นจึงรับผลลัพธ์
นาที-ชั่วโมง
ปกติจะลดราคา.
งานปริมาณมากและทนทานต่อความล่าช้า
การประมวลผลเป็นชุดคือ: คุณส่งคำขอหลายร้อย/พันคำขอเป็น "งาน" เดียวไปยังผู้ให้บริการ ผู้ให้บริการจะดำเนินการตามขั้นตอนของตนเองและส่งคืนผลลัพธ์ทั้งหมดเป็นกลุ่มเมื่อดำเนินการเสร็จสิ้น ในทางกลับกัน คุณจะได้รับสองสิ่ง: (1) โดยทั่วไปต้นทุนต่อหน่วยลดลง (2) ความสามารถในการเคลื่อนย้ายในปริมาณมากโดยไม่ต้องจัดการกับขีดจำกัดความเร็ว ราคาอยู่ที่ผลลัพธ์ไม่ได้มาทันทีแต่หลังจากผ่านไประยะหนึ่ง
เมื่อใดที่จะแบทช์ เมื่อไม่?
การตัดสินใจมีคำถามเดียว: ผู้ใช้กำลังรอผลลัพธ์อยู่หรือไม่?
- ไม่ ฉันสามารถถือไว้ได้ → ผู้สมัครเป็นกลุ่ม การแท็กกลางคืน การสรุปแบทช์ การจำแนกประเภทไฟล์เก็บถาวร การเพิ่มคุณค่าของข้อมูล การดำเนินการประเมิน (ประเมิน)
- ใช่ กำลังรออยู่ที่หน้าจอ → ซิงค์ แชทสด คำแนะนำทันที ความช่วยเหลือในการกรอกแบบฟอร์ม
เคล็ดลับ: สองโหมดสามารถอยู่ร่วมกันในผลิตภัณฑ์เดียวกันได้ ผู้ใช้ทำงานพร้อมกันในการแชทสด ในตอนกลางคืน คุณจะมอบบทสนทนาทั้งหมดของวันนั้นให้กับกลุ่มเพื่อการวิเคราะห์คุณภาพ การแยก "ความต้องการในการดำรงชีวิต" ออกจาก "ความต้องการส่วนรวม" คือการตัดสินใจครั้งแรกของสถาปัตยกรรม
กายวิภาคของการไหลของแบทช์ที่แข็งแกร่ง
กฎทางเทคนิคที่สำคัญที่สุดของการประมวลผลเป็นชุดคือการจับคู่ผลลัพธ์
- กำหนด `custom_id` ที่ไม่ซ้ำกันให้กับคำขอแต่ละรายการ นี่คือรหัสที่คุณสร้างขึ้นซึ่งระบุคำขอ (เช่น ใบแจ้งหนี้-2026-07-18-000431)
- ส่งงาน. คำขอทั้งหมดรวมอยู่ในแพ็คเกจเดียว แต่ละอันมี custom_id ของตัวเอง
- สำรวจสถานการณ์ คุณขอสถานะเป็นช่วง ๆ จนกว่างานจะ "เสร็จสิ้น"
- จับคู่ผลลัพธ์กับ `custom_id` ผลลัพธ์อาจถูกส่งคืนในลำดับที่แตกต่างจากคำสั่งการส่ง ดังนั้นอย่าจับคู่ตามตำแหน่ง แต่โดย custom_id แต่ละผลลัพธ์จะมีอยู่
- ตรวจสอบประเภทของผลลัพธ์แต่ละรายการ คำขอหนึ่งอาจสำเร็จ คำขอหนึ่งอาจล้มเหลว คำขอหนึ่งอาจหมดอายุ กระบวนการขึ้นอยู่กับความสำเร็จ/ความล้มเหลว
{ "คำขอ": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "จำแนกใบแจ้งหนี้ ส่งคืน JSON เท่านั้น", "ข้อความ": [{ "role": "user", "content": "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "จัดประเภทใบแจ้งหนี้ ส่งคืน JSON เท่านั้น", "ข้อความ": [{ "role": "user", "content": "{{invoice_text_2}}" }] } } ]}
ข้อควรระวัง: การจับคู่ผลลัพธ์ตามลำดับการส่งถือเป็นข้อผิดพลาดอันดับหนึ่งในการจัดชุด คิวไม่รอด หากไม่มี custom_id คุณจะไม่สามารถรู้ได้อย่างมั่นใจว่าผลลัพธ์ใดเป็นของเอกสารใด การจับคู่ที่ไม่ถูกต้องจะนำไปสู่ข้อมูลที่ไม่ถูกต้อง
เทมเพลตที่คัดลอกได้
# กฎการสร้าง custom_id (ไม่ซ้ำกันและติดตามได้) รูปแบบ: <isture>-<date>-<sequence> ตัวอย่าง: request-20260718-000431กฎ: ห้ามทำซ้ำในการทำงาน ฝังรหัสบันทึกทรัพยากรไว้ในนั้น
# การ์ดงานแบทช์ (เทมเพลตการกำหนดเวลา)ชื่องาน: .............จำนวนบันทึก: .............รุ่น: ............. (งานแบบง่าย → โมเดลที่รวดเร็ว)Max_tokens ต่อการร้องขอ: .............ความอดทนต่อเวลาการส่งมอบที่คาดหวัง: ......... ชั่วโมง คีย์การจับคู่ผลลัพธ์: custom_idในกรณีที่เกิดข้อผิดพลาด: ลองใหม่ / คิว / รายงาน
# Single request prompt เป็นกลุ่ม (แบบสั้นและแบบแผนผัง) จำแนกเอกสารนี้ เพียงส่งคืน JSON นี้ โดยแสดงความคิดเห็น:{"category Collab..."urgency///low|medium|high"}เอกสาร: """{{document}}"""
# การประมวลผลผลลัพธ์รหัสหลอกสำหรับแต่ละผลลัพธ์: if result.status == "success": record = find(custom_id) save(record, result.output) มิฉะนั้น: add_to_fail(custom_id, result.error) # จากนั้นลองอีกครั้ง
พรอมต์ที่อ่อนแอ / พรอมต์ที่รัดกุม (การออกแบบงานเป็นกลุ่ม)
# WEAK (fragile design)ส่งเอกสาร 10,000 ตามลำดับพร้อมรุ่นที่แข็งแกร่ง บันทึกผลลัพธ์ที่ส่งคืนตามลำดับที่มาถึง
# แข็งแกร่ง (ดีไซน์ทนทาน) ส่งเอกสารได้ 10,000 ฉบับในชุดเดียวด้วยโมเดลที่รวดเร็ว กำหนด custom_id ที่ไม่ซ้ำกันให้กับแต่ละเอกสารซึ่งมี ID แหล่งบันทึก จับคู่ผลลัพธ์กับ custom_id; จัดคิวสิ่งที่ล้มเหลวแล้วลองอีกครั้ง เรียกใช้ในหน้าต่างกลางคืน ความอดทนในการจัดส่ง 6 ชั่วโมง
รุ่นทรงพลัง; โดยจะกำหนดการเลือกรุ่น คีย์ที่ตรงกัน การจัดการข้อผิดพลาด และเวลาไว้ล่วงหน้า นี่คือความแตกต่างในการประมวลผลบันทึกนับหมื่นรายการอย่างปลอดภัย
มินิเคสสามอัน
กรณีที่ 1 — การแท็กตอนกลางคืน ทีมอีคอมเมิร์ซจะจัดเรียงบทวิจารณ์ผลิตภัณฑ์ 200,000 รายการลงในแท็กความคิดเห็น การสตรีมแบบซิงโครนัสสดอยู่ภายใต้การจำกัดความเร็วและมีค่าใช้จ่ายสูง พวกเขาขนงานไปในเวลากลางคืนเป็นชุดด้วยแบบจำลองที่รวดเร็ว ต้นทุนต่อหน่วยลดลง ทั้งชุดพร้อมใช้งานในตอนเช้า และไม่มีปัญหาจำกัดความเร็ว
กรณีที่ 2 — ความสับสนในการสั่งซื้อ ทีมวิจัยชุดหนึ่งสรุปบทความได้ 5,000 บทความ แต่เขียนผลลัพธ์ลงในไฟล์ตามลำดับที่มาถึง เนื่องจากผลลัพธ์ถูกส่งกลับในลำดับที่แตกต่างกัน บทคัดย่อประมาณ 900 รายการจากทั้งหมด 5,000 รายการจึงเชื่อมโยงกับบทความที่ไม่ถูกต้อง พวกเขาทำการแมปใหม่เป็น custom_id; แก้ไขปัญหาได้แล้วและประสบการณ์นี้ก็กลายเป็นกฎถาวร: "เสมอ custom_id ในชุด"
กรณีที่ 3 — สแตนด์บายสดในโหมดที่ไม่ถูกต้อง ทีมสนับสนุนพยายามที่จะให้การตอบกลับสดตามที่ผู้ใช้คาดหวังบนหน้าจอเป็นชุด ผู้ใช้ละทิ้งเพราะผลลัพธ์มาถึงไม่กี่นาทีต่อมา พวกเขาย้ายงานสดกลับไปเป็นการซิงโครไนซ์ โดยเหลือเพียงการวิเคราะห์คุณภาพทุกคืนในชุดงาน บทเรียน: แบตช์ไม่ได้มีไว้สำหรับการสแตนด์บายแบบสด
ข้อผิดพลาดทั่วไป
- ผลลัพธ์ที่ตรงกันตามตำแหน่ง: ลำดับจะไม่ถูกรักษาไว้ ใช้ custom_id
- การโอนงานที่ใช้งานจริงไปเป็นแบตช์: ผู้ใช้ไม่สามารถรอเป็นเวลาหลายนาทีได้ ชุดงานสำหรับงานที่ทนทานต่อความล่าช้า
- ไม่จัดการกรณีข้อผิดพลาด: คำขอบางรายการอาจส่งคืนล้มเหลว/หมดอายุ วางไว้ในคิวแยกต่างหากแล้วลองอีกครั้ง
- การสะท้อนการใช้งานโมเดลที่แข็งแกร่งในแบทช์: โมเดลด่วน + แบทช์เป็นชุดค่าผสมที่ถูกที่สุดในงานง่ายๆ
- ไม่ทำให้ติดตาม custom_id ได้: หากไม่มีบันทึกต้นฉบับฝังอยู่ใน ID จะทำให้ลิงก์ผลลัพธ์กลับได้ยาก
- ลืมตรวจสอบสถานการณ์: คาดหวังผลลัพธ์ก่อนงานเสร็จ; ตรวจสอบสถานะการเสร็จสิ้น
เจาะลึกยิ่งขึ้น: การตรวจสอบแบทช์และการจัดการความล้มเหลวบางส่วน
แง่มุมที่สมบูรณ์ที่สุดของการประมวลผลแบบแบตช์คือต้องใช้ความคิดที่แตกต่างจากการโทรแต่ละครั้ง งานแบบแบตช์คือ "กระบวนการ" ไม่ใช่ "เหตุการณ์" สมมติว่าคำขอนับหมื่นคำขอทั้งหมดจะประสบความสำเร็จถือเป็นเรื่องเปราะบาง การออกแบบที่สมจริงยอมรับความล้มเหลวบางส่วนตั้งแต่เริ่มต้น สถานะของผลลัพธ์แต่ละรายการอาจแตกต่างกัน: สำเร็จ ล้มเหลว (เช่น ข้อมูลไม่ถูกต้อง) ยกเลิก หรือหมดอายุ โฟลว์ที่มีประสิทธิภาพจะประมวลผลสถานะของผลลัพธ์แต่ละรายการแยกกันขณะเดินทางผ่าน วางความล้มเหลวไว้ใน "คิวการลองใหม่" ที่แยกต่างหาก และรันคิวนั้นแยกกัน
แนวปฏิบัติที่สองคือการออกแบบเพื่อความเหมือนเดิม (การรันงานเดิมสองครั้งไม่ก่อให้เกิดอันตรายใดๆ) หากแบทช์ถูกขัดจังหวะและคุณรีสตาร์ท คุณไม่ควรประมวลผลซ้ำและเขียนบันทึกที่ประมวลผลแล้วเป็นสองเท่า การเชื่อมโยง custom_id กับบันทึกต้นทางของคุณก็ใช้ได้ที่นี่เช่นกัน: "บันทึกนี้ได้รับการประมวลผลแล้วหรือไม่" ก่อนที่จะบันทึกผลลัพธ์ การตรวจสอบป้องกันการพิมพ์ซ้ำ
ประเด็นที่สามคือการสลับสตรีมสดเป็นชุด งานบางงานมีทั้งขนาดที่ใช้งานจริงและแบบแบตช์: เมื่อผู้ใช้โหลดเอกสาร คุณจะให้ข้อมูลสรุปเบื้องต้นอย่างรวดเร็ว (ซิงโครนัส) และประมวลผลเอกสารเดิมซ้ำเพื่อการวิเคราะห์เชิงลึกในเวลากลางคืน (แบทช์) การแยกทั้งสองโหมดอย่างมีสติจะช่วยเพิ่มประสิทธิภาพทั้งประสบการณ์ผู้ใช้และต้นทุน
สุดท้ายนี้ การแบ่งกลุ่มเป็นวิธีจัดการกับการจำกัดความเร็วด้วย (หน่วยที่ 8) การส่งปริมาณมากในโฟลว์ซิงโครนัสแบบสดจะสร้างค่าคงที่ 429 ในขณะที่การส่งปริมาณเดียวกันไปยังการถ่ายโอนแบบกลุ่มจะจำกัดความกดดันให้กับกำหนดเวลาของผู้ให้บริการเอง และทำให้งานสามารถคาดเดาได้มากขึ้น
โดยสรุป
โดยทั่วไปการประมวลผลแบบกลุ่มจะมีราคาถูกกว่าและมีประสิทธิภาพมากกว่าสำหรับปริมาณงานที่ทนต่อเวลาแฝงและมีปริมาณมาก การตัดสินใจของเขาคือ "ผู้ใช้กำลังรอผลลัพธ์อยู่หรือไม่" กำหนดคำถาม กฎทางเทคนิคที่สำคัญที่สุดคือการกำหนดให้แต่ละคำขอมี custom_id ที่ไม่ซ้ำกัน จับคู่ผลลัพธ์ตาม ID แทนที่จะเป็นตำแหน่ง และถือว่าความสำเร็จ/ความล้มเหลวของผลลัพธ์แต่ละรายการแยกกัน
งานสมัคร
เลือกงานที่มีปริมาณมาก (เช่น การจัดหมวดหมู่เอกสารสำคัญ) (1) ตัดสินใจว่างานนี้จะเป็นงานสดหรืองานรวมและให้เหตุผล (2) ออกแบบรูปแบบ custom_id (รวมบันทึกทรัพยากร) (3) กรอกบัตรงานแบทช์ (รุ่น, max_tokens, ค่าเผื่อ, นโยบายข้อผิดพลาด) (4) เขียนรหัสจำลองการประมวลผลผลลัพธ์เพื่อรวมคำขอที่ล้มเหลว
รายการตรวจสอบ
- [ ] ฉันสามารถแยกแยะโหมดซิงโครนัส อะซิงโครนัส และแบทช์บนแกนต้นทุน/ดีเลย์ได้
- [ ] ฉันสามารถตัดสินใจได้ว่างานนั้นเหมาะสมกับงานกลุ่มหรือไม่โดยการถามคำถามที่ถูกต้อง
- [ ] ฉันให้ custom_id ที่ไม่ซ้ำกันแก่คำขอแต่ละคำขอ และจับคู่ผลลัพธ์ตาม ID
- [ ] ฉันสามารถจัดการผลลัพธ์ที่ล้มเหลว/หมดอายุแยกกันได้
- [ ] ฉันรู้ถึงประโยชน์ของการเลือกแบบจำลองที่รวดเร็วในงานแบบแบตช์ธรรมดา