บทเรียนที่ได้หลังประมวลผล GPT ไป 500 ล้านโทเค็น

 (kenkantzer.com)
4 คะแนน โดย GN⁺ 2024-04-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Truss ได้ดำเนินงาน ฟีเจอร์ที่มี LLM เป็นศูนย์กลาง ในช่วง 6 เดือนที่ผ่านมา โดยประมวลผลมากกว่า 500 ล้านโทเค็นด้วยโมเดลของ OpenAI และสรุปข้อจำกัดที่พบจริงในงานสรุป วิเคราะห์ และสกัดข้อความสำหรับ B2B
  • พรอมป์ไม่ได้เสถียรขึ้นเมื่อใส่คำสั่งละเอียดจำนวนมาก และในบางกรณีคำสั่งที่ สั้นและเจาะจงน้อยกว่า ให้ผลลัพธ์ดีกว่าสำหรับความรู้ทั่วไปที่ GPT รู้อยู่แล้ว
  • แม้ไม่ใช้ Langchain, JSON mode, function calling หรือ assistants ก็สามารถดำเนินงานหลายฟีเจอร์ด้วย chat API และฟังก์ชันสกัด JSON เพียงตัวเดียว โดยโค้ดหลักมีเพียง ฟังก์ชัน 40 บรรทัด พร้อมการจัดการข้อผิดพลาดและการตัดข้อความอัตโนมัติเล็กน้อย
  • GPT อ่อนในด้านการจัดการ สมมติฐานว่าง (null hypothesis) เช่น “ถ้าไม่มีให้คืนค่าว่าง” และการสร้างเอาต์พุตยาว ๆ แม้ GPT-4 จะมีหน้าต่างอินพุต 128k แต่เอาต์พุตยังอยู่ระดับประมาณ 4k
  • RAG และ vector DB ไม่เหมาะนักกับงานสกัดข้อความที่มีขอบเขตจำกัดของ Truss การใส่บริบททั้งหมดเพื่อวิเคราะห์ สรุป และสกัดมีความน่าเชื่อถือสูง แต่ปัญหาจะรุนแรงขึ้นเมื่ออินพุตว่างหรือไม่มีข้อมูลที่เกี่ยวข้อง

ขอบเขตการใช้งานและสมมติฐาน

  • ในช่วง 6 เดือนที่ผ่านมา Truss ได้เปิดตัว ฟีเจอร์ที่มี LLM เป็นศูนย์กลาง หลายรายการ และปริมาณการใช้งานประเมินว่าเกิน 500 ล้านโทเค็นเล็กน้อย
  • โมเดลที่ใช้เป็นตระกูล OpenAI โดยปริมาณโทเค็นแบ่งเป็น GPT-4 85% และ GPT-3.5 15%
  • ข้อมูลที่จัดการมีเฉพาะข้อความเท่านั้น ไม่รวมฟีเจอร์ที่ไม่ใช่ข้อความ เช่น gpt-4-vision, Sora, Whisper
  • บริบทของผลิตภัณฑ์เป็น B2B และงานหลักคือ การสรุป·การวิเคราะห์·การสกัด
  • 500 ล้านโทเค็นเทียบได้กับข้อความประมาณ 750,000 หน้า

พรอมป์อาจดีขึ้นเมื่อเจาะจงน้อยลง

  • เมื่อใส่รายการและคำสั่งที่แม่นยำมากเกินไปเกี่ยวกับความรู้ทั่วไปที่ GPT รู้อยู่แล้ว ผลลัพธ์อาจแย่ลงได้
  • Pipeline หนึ่งต้องจัดหมวดหมู่ว่าบล็อกข้อความเกี่ยวข้องกับรัฐใดใน 50 รัฐของสหรัฐฯ หรือรัฐบาลกลาง
    • พรอมป์แรกใส่รายการ ID ของ 50 รัฐและ federal ในรูปแบบ JSON ลงในฟิลด์ locality_id แล้วให้เลือก
    • วิธีนี้ทำงานได้ประมาณ มากกว่า 98% แต่มีความล้มเหลวมากพอที่จะต้องตรวจสอบเพิ่มเติม
  • ฟิลด์อีกตัวคือ name แม้ไม่ได้ร้องขออย่างชัดเจน แต่ก็คืนชื่อเต็มของรัฐที่ถูกต้องได้อย่างเสถียร
    • ต่อมาจึงเปลี่ยนเป็นวิธีค้นหารัฐจากสตริงที่ปรากฏใน name และทำงานได้ดี
  • วิธีที่ดีกว่าคือ พรอมป์ที่ปล่อยให้ใช้สามัญสำนึก เช่น “คุณรู้จัก 50 รัฐอยู่แล้ว ให้คืนชื่อเต็มของรัฐนั้นหรือ Federal”
  • มีข้อสังเกตเพิ่มเติมด้วย
    • ความล้มเหลวเกิดบ่อยกว่าใน รัฐที่ขึ้นต้นด้วย M เช่น Maryland, Maine, Massachusetts, Michigan
    • เมื่อให้เลือก ID จากรายการ JSON ที่อ่านง่ายโดยวางแต่ละรัฐแยกบรรทัด ทำให้สับสนน้อยกว่ารายการที่คั่นด้วยจุลภาคต่อกัน

API และ abstraction ถูกคงไว้อย่างเรียบง่าย

  • ในกรณีนี้ Langchain ใกล้เคียงกับ การทำ abstraction ก่อนเวลาอันควร และแม้หลังจากใช้งานหลายล้านโทเค็นกับฟีเจอร์ production ที่หลากหลาย 3–4 รายการแล้ว ในไฟล์ openai_service ก็ยังเหลือเพียงฟังก์ชัน 40 บรรทัดหนึ่งตัว
  • API ที่ใช้จริงมีแค่ chat
    • สกัด JSON เสมอ
    • ไม่จำเป็นต้องใช้ JSON mode, function calling หรือ assistants
    • ไม่ใช้ system prompt ด้วย
    • เมื่อ gpt-4-turbo เปิดตัว ก็เปลี่ยนเพียงสตริงเดียวใน codebase
  • ฟังก์ชันส่วนใหญ่รับผิดชอบการจัดการข้อผิดพลาด เช่น ข้อผิดพลาด 500 ของ OpenAI API หรือ socket ปิด
    • ข้อผิดพลาดเหล่านี้ดีขึ้นแล้ว และมองว่าไม่น่าแปลกใจเมื่อคำนึงถึงโหลดของ OpenAI
  • ข้อจำกัดความยาว context จัดการด้วยการตัดข้อความอัตโนมัติของตัวเอง
    • หากความยาวสตริงมากกว่า model_context_size * 3 จะตัดออก
    • เมื่อมีเครื่องหมายจุดหรือตัวเลขจำนวนมาก อัตราส่วนโทเค็นอาจต่ำกว่า 1 โทเค็นต่อ 3 ตัวอักษรจนทำให้ล้มเหลวได้
    • หากเกิด context_length_exceeded จะตัดใหม่ตามเกณฑ์ model_context_size * 3 / 1.3 แล้วลองอีกครั้ง

UX แบบสตรีมมิงประเมินค่าต่ำได้ยาก

  • การใช้ streaming API เพื่อลด latency และแสดง ตัวอักษรที่ปรากฏด้วยความเร็วแปรผัน ให้ผู้ใช้เห็น ตอนแรกดูเหมือนเป็นลูกเล่น
  • ผู้ใช้จริงตอบรับการแสดงผลแบบ “พิมพ์” ด้วยความเร็วแปรผันในเชิงบวกอย่างมาก
  • ประสบการณ์นี้ให้ความรู้สึกเหมือนช่วงเวลาที่เมาส์และเคอร์เซอร์กลายเป็น UX สำคัญในโลก AI

ผลลัพธ์ว่างและเอาต์พุตยาวเป็นจุดอ่อน

  • “ถ้าหาไม่พบให้คืนเอาต์พุตว่าง” ใกล้เคียงกับข้อความพรอมป์ที่ก่อข้อผิดพลาดมากที่สุด
    • ความหมายไม่ได้ให้ไม่ต้องพิมพ์อะไรเลยจริง ๆ แต่ให้คืนตัวแทนค่าว่าง เช่น {value: ""}
    • ปัญหาไม่ใช่ความล้มเหลวของข้อจำกัดเอาต์พุต แต่ใกล้เคียงกับความยากในการตัดสิน สมมติฐานว่าง เอง
  • เมื่อควรคืนค่าว่าง GPT บางครั้งเลือก hallucinate และในทางกลับกัน บางครั้งก็มั่นใจน้อยลงจนคืนค่าว่างบ่อยเกินไป
  • เมื่อมีบั๊กที่ทำให้บล็อกข้อความอาจว่างเปล่า hallucination เกิดขึ้นอย่างรุนแรง
    • ตัวอย่างเช่น มีชื่อร้านเบเกอรีปลอมอย่าง Sunshine Bakery, Golden Grain Bakery, Bliss Bakery ปรากฏขึ้น
    • วิธีแก้คือถ้าไม่มีข้อความ ก็ไม่ส่งพรอมป์ไปเลย
  • GPT-4 อาจมี หน้าต่าง 128k โทเค็น สำหรับอินพุต แต่หน้าต่างเอาต์พุตยังอยู่ระดับประมาณ 4k
    • คำว่า “context window” ทำให้สับสนระหว่างอินพุตกับเอาต์พุต
  • เมื่อให้คืนรายการออบเจ็กต์ JSON แม้เป็นออบเจ็กต์ง่าย ๆ ก็ยากที่จะเกิน 10 รายการ
    • หากขอ 15 รายการ ประเมินว่าสำเร็จเพียงประมาณ 15%
    • แม้หยุดที่ระดับ 10 รายการ เอาต์พุตก็มีเพียงประมาณ 700–800 โทเค็นเท่านั้น
  • แม้จะเลี่ยงข้อจำกัดเอาต์พุตได้ด้วยการขอทีละรายการและใส่ผลลัพธ์ก่อนหน้ากลับเข้าไป แต่จะกลายเป็นการเล่น เกมโทรศัพท์ กับ GPT และต้องจัดการเครื่องมืออย่าง Langchain

RAG และ vector DB ไม่เหมาะกับกรณีใช้งานนี้

  • ในกรณีของ Truss นั้น vector DB และ RAG/embedding แทบไม่มีประโยชน์
  • มองว่า vector DB และ RAG เหมาะกับการค้นหา และโดยเฉพาะการค้นหาแบบ ค้นหาจริง อย่าง Google หรือ Bing มากกว่า
  • ปัญหาหลักคือเกณฑ์ความเกี่ยวข้อง
    • ไม่มี cutoff ที่ชัดเจนสำหรับความเกี่ยวข้อง
    • อาจมีวิธีอย่าง rerank ของ Cohere หรือ heuristic ของตัวเอง แต่ไม่เสถียร
    • มีความเสี่ยงที่ผลการค้นหาจะปนเปื้อนด้วยผลลัพธ์ที่ไม่เกี่ยวข้อง หรือจับแบบอนุรักษนิยมเกินไปจนพลาดผลลัพธ์สำคัญ
  • การเก็บเวกเตอร์ไว้ใน DB เฉพาะทางหรือ proprietary ที่แยกจากข้อมูลทั่วไปก็มีการสูญเสียมาก
    • หากไม่ได้อยู่ในระดับ Google หรือ Bing ก็มองว่าการสูญเสียบริบทไม่คุ้มกับ trade-off
  • ในการค้นหาภายในแอปธุรกิจ ผู้ใช้มักเป็นผู้เชี่ยวชาญในโดเมน
    • มองว่าผู้ใช้ไม่ชอบ semantic search ที่คาดเดาความหมายซึ่งผู้ใช้ไม่ได้ป้อนเองแล้วนำมาคืนผล
  • ในกรณีค้นหาส่วนใหญ่ การใช้ LLM เป็น completion prompt ทั่วไปเพื่อแปลงคำค้นของผู้ใช้เป็น faceted search, query ซับซ้อน หรือ SQL อาจดีกว่า
    • วิธีนี้ไม่ใช่ RAG

Hallucination ลดลงมากเมื่อมีบริบทเพียงพอ

  • กรณีใช้งานส่วนใหญ่ของ Truss อยู่ในรูปแบบ “ให้บล็อกข้อความ แล้วสกัดบางอย่างจากบล็อกนั้น”
  • หากขอชื่อบริษัทที่กล่าวถึงในข้อความ GPT มักไม่คืนชื่อบริษัทแบบสุ่ม
    • แต่เมื่อไม่มีบริษัทในข้อความ ปัญหาสมมติฐานว่างก็กลับมาอีกครั้ง
  • ในโค้ด GPT ก็ไม่ค่อย hallucinate ในความหมายของการสร้างชื่อตัวแปรขึ้นมาเองหรือแทรก typo แบบสุ่มระหว่างเขียนบล็อกโค้ดที่ส่งให้ใหม่
    • อย่างไรก็ตาม หากขอให้สร้างบางอย่าง อาจแต่งว่ามีฟังก์ชันใน standard library อยู่จริง
    • มองว่านี่ก็ใกล้เคียงกับปัญหาที่ไม่สามารถพูดว่า “ไม่รู้” ได้
  • ในงานที่ให้บริบททั้งหมดแล้วให้ วิเคราะห์·สรุป·สกัด ถือว่าน่าเชื่อถือมาก
  • โครงสร้างใกล้เคียงกับว่า หากใส่ข้อมูลที่ดี ก็จะได้คำตอบ GPT token ที่ดี

การประเมินแนวโน้มในอนาคต

  • มองว่าเพียง transformer ปัจจุบัน ข้อมูลอินเทอร์เน็ต และการเข้าถึง infrastructure ระดับหลายพันล้านดอลลาร์ ยังไม่พอไปถึง AGI
  • GPT-4 ไม่ใช่การตลาด แต่เป็น เทคโนโลยีที่มีประโยชน์ 100% และยังอยู่ในช่วงคล้ายยุคต้นของอินเทอร์เน็ต
    • ไม่ใช่เทคโนโลยีที่จะเลิกจ้างทุกคน
    • มีผลอย่างมากในการลดกำแพงการเข้าสู่ ML/AI ที่ก่อนหน้านี้มีเพียง Google เท่านั้นที่เข้าถึงได้
  • Claude, Gemini ฯลฯ ไม่ได้ทดสอบ A/B อย่างเข้มงวด
    • เมื่อทดสอบในการเขียนโค้ดประจำวัน รู้สึกว่ายังไม่ใกล้ GPT-4 ในส่วนละเอียดอ่อนของการเดาเจตนาอย่างเป็นธรรมชาติ
  • มองว่าไม่จำเป็นต้องติดตามกระแส LLM/AI ทั้งหมด
    • เมื่อพิจารณาตาม The Bitter Lesson หากการเพิ่มประสิทธิภาพของโมเดลทั่วไปสำคัญกว่าการปรับปรุงเฉพาะทาง ก็เพียงต้องสนใจว่า GPT-5 จะเปิดตัวหรือไม่
    • หากไม่นับสาขาแยกอย่าง Sora รุ่นย่อยระหว่างทางของ OpenAI ส่วนใหญ่ถือว่าใกล้เคียงกับสัญญาณรบกวน
  • GPT-5 มีแนวโน้มเป็น การปรับปรุงแบบค่อยเป็นค่อยไป มากกว่าจะเปลี่ยนทุกอย่าง
    • ตอนเปลี่ยนจาก GPT-3 ไป GPT-3.5 เคยคาดหวังการปรับปรุงแบบ superlinear ว่าหากเพิ่มความเข้มข้นการฝึก 2 เท่า ประสิทธิภาพจะดีขึ้น 2.2 เท่า
    • ในความเป็นจริงดูเหมือนการปรับปรุงแบบ logarithmic และมองว่าเป็นสถานการณ์ที่ความเร็วโทเค็นกับต้นทุนต่อโทเค็นเพิ่มขึ้นแบบทวีคูณเพื่อให้ได้การปรับปรุงทีละน้อย
  • GPT-4 อาจเป็นจุดเหมาะสมที่สุดสำหรับชุดงานในปัจจุบัน
    • แม้ยินดีจ่ายแพงกว่า GPT-3.5 ถึง 20 เท่าเพื่อใช้ GPT-4 แต่ดูเหมือนจะไม่จ่ายต่อโทเค็นแพงขึ้น 20 เท่าเพื่อขยับจาก GPT-4 ไป GPT-5
    • GPT-5 อาจทำลายสมมติฐานนี้ได้ หรืออาจเป็นเพียงระดับการเปลี่ยนจาก iPhone 4 ไป iPhone 5

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-04-14
ความคิดเห็นจาก Hacker News

  • ทีมที่ผมดูแลประมวลผล 5 พันล้าน+ โทเค็น ต่อเดือนและยังเพิ่มขึ้นเรื่อย ๆ มีบทเรียนอยู่ไม่กี่ข้อ
    อย่างแรกคือมีการทำ abstraction เร็วเกินไปมากเกินจำเป็น เครื่องมืออย่าง Langchain อาจมีประโยชน์ในสักวันหนึ่ง แต่สุดท้ายแล้วพรอมป์ตก็เป็นแค่การเรียก API และการจัดการการเรียก LLM ด้วยโค้ดมาตรฐานแบบเดียวกับ การเรียก API ที่ไม่เสถียร นั้นง่ายกว่าการปฏิบัติต่อมันเหมือนเป็นสิ่งพิเศษ
    อย่างที่สอง ภาพหลอนเป็นปัญหาใหญ่จริง ๆ งานสรุปผลค่อนข้างแข็งแรงในการทดสอบ แต่การให้เหตุผลนั้นยากมาก และ โมเดลการกระทำ ที่รับอินพุตจากผู้ใช้แล้วให้ LLM ตัดสินใจว่าจะทำอะไรต่อ ยิ่งยากเป็นพิเศษทั้งในแง่การเข้าใจบริบทและการทำให้มันพูดว่า “ไม่แน่ใจ” ถึงอย่างนั้น แค่การทำสิ่งนี้ได้ก็นับว่าเปลี่ยนเกมแล้ว
    อย่างที่สาม ผมเห็นด้วยกับฝั่งที่บอกว่า “เปลี่ยนเกม” มากกว่าผู้เขียนนิดหน่อย แต่ก็ไม่คิดว่าโลกจะถึงกาลอวสาน บางอาชีพจะได้รับผลกระทบหนัก และเราอาจมีช่วงหลายปีที่ลำบากจากบอตที่ปั่นกระแสสาธารณะบนแพลตฟอร์มต่าง ๆ โดยรวมแล้วมันดูเหมือน ตัวขยายความสามารถ มากกว่าจะเป็นนวัตกรรมพลิกโลกแบบอินเทอร์เน็ต
    สำหรับผม มันคล้ายกับการเปลี่ยนแปลงของ DevOps ในยุค 2000 ตอนนี้ไม่จำเป็นต้องมีทีมเฉพาะทางขนาดใหญ่คอยช่วย deploy อีกแล้ว แค่จ้างผู้เชี่ยวชาญไม่กี่คน แล้วที่เหลือซื้อโซลูชันสำเร็จรูปมาใช้ เช่นเดียวกัน งานแมชชีนเลิร์นนิงบางอย่างตอนนี้นักพัฒนาเว็บอย่างผมก็ทำได้ง่ายขึ้น

    • อุปมานี้มีประโยชน์มากเวลาอธิบายว่าควรคาดหวัง LLM อย่างไรในกระบวนการพัฒนาสมัยใหม่ เพราะมันแสดงให้เห็นว่านี่ไม่ใช่ ยาวิเศษแก้ได้ทุกอย่าง แต่เป็นการแลกเปลี่ยน
      แม้แต่พัฒนาการของ DevOps ก็มีการแลกเปลี่ยนเหมือนกัน ตัวอย่างเช่น ผลลัพธ์ตรง ๆ ของแนวคิด “ก็ใช้ AWS RDS ไปสิ” คือความสามารถหลักอย่างการดูแลฐานข้อมูลค่อย ๆ หายไป และค่าใช้จ่ายบิลคลาวด์ก็พุ่งสูง โดยเฉพาะสตาร์ตอัปที่ขนาดข้อมูลหรือความซับซ้อนด้านภูมิภาคไม่ได้มากนักก็ยังมีต้นทุนการดำเนินงานสูงขึ้น และผมคิดว่ากระแสนี้ยังนำไปสู่อุบัติเหตุอย่างเหตุล่มใหญ่ของ GitLab และเหตุคล้ายกันด้วย
    • การทำให้มันพูดว่า “ไม่แน่ใจ” เป็นสิ่งที่ใกล้เคียงกับ ฟังก์ชันของตัวภาษาโมเดลเอง มากกว่า เมื่อมันไปถึงเอาต์พุต ความไม่แน่นอนที่มีอยู่ในกระบวนการคำนวณก็หายไปในระหว่างการทำนาย
      คล้ายกับเวลาบอกให้ทายหัวก้อยแล้วตอบว่า “หัว” ก่อนตอบคุณอาจพูดถึงความไม่แน่นอนอย่าง Pr[หัว] = .5 ได้ แต่ในตัวคำทำนายจริงและผลการโยนเหรียญ ความไม่แน่นอนนั้นหายไป LLM ก็เช่นกัน ความไม่แน่นอนระหว่างคำนวณจะหายไปในการทำนายโทเค็นสุดท้าย ดังนั้น เว้นแต่ว่าการทำนายนั้นเองจะเป็นการแสดงความไม่แน่นอน มันแทบจะไม่ส่งเอาต์พุตว่า “ฉันไม่เข้าใจ” ออกมา อย่างไรก็ดี เหตุผลก็คือมันตั้งต้นจากการทำนายโดยไม่ได้เข้าใจอยู่แล้ว
    • ผมไม่เคยนึกถึงอุปมาเรื่อง DevOps มาก่อน แต่พอฟังแล้วมันเข้าทีมาก เลยเพิ่งเขียนบทความจากไอเดียนี้ไว้: https://kenkantzer.com/gpt-is-the-heroku-of-ai
      โดยพื้นฐานแล้ว ผมคิดว่าเรากำลังใช้ GPT เป็นสิ่งเทียบเท่า PaaS/Heroku/Render ในโลกปฏิบัติการ AI
    • เห็นด้วยกับประโยคที่ว่า “มันเป็นตัวขยายความสามารถมากกว่านวัตกรรมแบบอินเทอร์เน็ต” ลูกค้าก็เริ่มรู้สึก ช็อกราคา จากผลลัพธ์เมื่อเทียบกับต้นทุนของโมเดลขนาดใหญ่เหมือนกัน เมื่อเวลาผ่านไป ค่าใช้จ่ายน่าจะลดลง
    • เห็นด้วยว่างานสรุปค่อนข้างแข็งแรง แต่การให้เหตุผลยังยาก วิธี ขอให้ใช้อุปมา น่าสนใจและมีประโยชน์กว่าที่คิด

  • ผมสงสัยตรงที่บอกว่า “เราดึง JSON ตลอด ไม่จำเป็นต้องมีโหมด JSON” เพราะสำหรับผมมันทำงานได้ค่อนข้างดี
    และประโยค “บทเรียนที่ 4: GPT อ่อนมากในการสร้างสมมติฐานศูนย์” ก็โดนใจมาก เมื่อวานผมยังทดสอบพรอมป์ตกฎการแก้ไขข้อความ โดยเขียนไว้ท้ายสุดว่า “ถ้าไม่มีกฎข้อไหนใช้กับข้อความนี้ ให้คืนข้อความต้นฉบับโดยไม่เปลี่ยนแปลง”
    เดาว่า ChatGPT ตอบอะไรกับข้อความที่ไม่เข้ากฎเลย? มันตอบเป็นสตริงว่า “The original text without any changes” แบบตรงตัวเลย

    • มีเรื่องเล่าประเภทจินนี่เจ้าอารมณ์ที่ตีความคำขอแบบตามตัวอักษรแล้วทำให้พรที่ได้กลายเป็นคำสาป และนั่นแหละคือสิ่งที่เรามีอยู่ตอนนี้ คนที่พรอมป์ตโมเดลสร้างภาพมานานอาจพอจับทางได้บ้าง แต่สำหรับคนที่เข้ามาเพราะ LLM เรื่องนี้อาจน่าตกใจพอสมควร
      ครั้งหนึ่งผมกำลังสร้างภาพผู้หญิงสามคนดื่มไวน์ในสวนสวยสำหรับใช้กับไพ่ทาโรต์ แล้วเติมคำว่า “lush vegetation” ไว้ท้ายพรอมป์ต ผลคือเพราะความกำกวมของคำว่า lush บรรยากาศที่ควรหรูหรากลับกลายเป็นแนวสาวมหาวิทยาลัยปาร์ตี้จมูกแดงแทน
    • ผมตีความว่าเขาหมายถึง “วิธีของเราทำงานดีอยู่แล้ว เลยไม่จำเป็นต้องใช้โหมด JSON” บริษัทเราก็เป็นแบบเดียวกัน ใช้งานจริงมา 1 ปีแล้วและไม่เคยต้องเปลี่ยน พรอมป์ตของเราทำให้ GPT-3.5 ส่ง JSON ออกมาได้อย่างสม่ำเสมอค่อนข้างดี
    • ถ้าดูเว็บรวมงานแต่งหน้าเค้กพัง ๆ จะเห็นว่ามนุษย์เองก็ทำพลาดแบบนี้กันตลอด

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

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

  • ฉันสมัครใช้บริการท็อป 3 ในสาย LLM ครบทั้งหมด แล้วชอบโยนพรอมป์ต์เดียวกันใส่บ่อย ๆ ซึ่งผลคือเอนไปทาง GPT-4 อย่างชัดเจนมาก แม้จะน่าประหลาดใจเมื่อคิดว่า GPT-4 ออกมาได้ 1 ปีแล้วและระหว่างนั้นก็มีอัปเดตหลายครั้ง
    อย่างน้อยในรูปแบบการใช้งานของฉัน อาการหลอนก็เกิดไม่บ่อยนัก ตรงกันข้าม Claude มักแต่ง API ที่ดูน่าเชื่อถือแต่ไม่มีอยู่จริงได้ค่อนข้างง่ายเวลาเขียนโค้ด ส่วน GPT-4 เวลามันรู้ว่าตัวเองถูกต้องจะดื้อกว่าและไม่ค่อยเออออตาม ความต่างแบบนี้แทบไม่สะท้อนในตัวชี้วัด ต้องลองใช้เองถึงจะเห็น

    • สำหรับฉัน Claude 3 Opus ดีกว่า GPT-4 โดยเฉพาะอธิบายได้ดีกว่า และที่สำคัญกว่าคือทำได้ละเอียดรอบคอบกว่า
      แม้ในงานเขียนโค้ด ฉันก็มักขอให้ช่วยอธิบายหัวข้อหรือโค้ดมากกว่าจะให้เขียนโค้ด และมันมีแนวโน้มจะให้คำตอบที่ละเอียดอ่อนกว่าอย่างมาก ถ้าให้ข้อความยาว ๆ แล้วคุยต่อ ฉันรู้สึกว่า Claude Opus เข้าใจเนื้อหาได้ลึกกว่า ขณะที่ GPT-4 มักหยุดอยู่ที่การสรุปข้อความที่ให้ไป ส่วน Claude ขยายความและให้เหตุผลต่อได้ดีกว่า
    • สงสัยว่าคุณเทียบกับ Claude Opus หรือเทียบกับรุ่นย่อยกันแน่ เพราะ Opus นี่ฉันชอบมากสำหรับการเขียนข้อความภาษาอังกฤษ
    • GPT-4 รับมือกับพรอมป์ต์ที่รูปแบบไม่ดี ข้อมูลไม่พอ หรือโครงสร้างเละเทะได้ดีกว่า ถ้าไม่จัดโครงสร้างพรอมป์ต์ขนาดใหญ่ให้ฉลาดพอ Claude อาจสับสนได้ว่ากำลังขออะไร
      แต่ถ้าเป็นพรอมป์ต์ที่ประกอบมาดี Claude Opus มักมีแนวโน้มให้ผลลัพธ์ดีกว่า GPT-4 Claude ยืดหยุ่นกว่าและให้คำตอบที่ยาวกว่า ขณะที่ ChatGPT/GPT-4 มักฟังดูเป็นคำตอบสั้น ๆ แบบ “สำเร็จรูป” ในสไตล์ของตัวเองเสมอ
    • ประสบการณ์ของฉันตรงกันข้าม ฉันสมัครหลายบริการแล้วคัดลอกคำถามเดียวกันไปวาง และในคำถามเกี่ยวกับการพัฒนาซอฟต์แวร์ Claude Opus นำห่างมากจนตอนนี้เริ่มคิดว่าอาจไม่จำเป็นต้องใช้ GPT-4 แล้ว
      ในตัวอย่างโค้ดที่ขอไป โค้ดที่ GPT-4 สร้างมาหลายครั้งถึงขั้นคอมไพล์ไม่ผ่าน แต่กับ Claude แทบไม่เคยเจอแบบนั้น
    • ฉันก็สมัครครบทั้งสามบริการและเทียบแบบเดียวกัน โดยเฉพาะเวลามีเวอร์ชันใหม่ออกมา
      ช่วงนี้ลิตมัสเทสต์ที่ใช้คือ “ช่วยบอกบาร์แปลก ๆ 10 แห่งในรัศมี 200 ไมล์จาก Austin” ซึ่งยากมากสำหรับทุกตัว GPT-4 ใกล้เคียงที่สุดพอสมควร แต่ Claude แต่งขึ้นล้วน ๆ ส่วน Gemini พังไม่เป็นท่า

  • GPT เจ๋งมากก็จริง แต่ฉันไม่เห็นด้วยอย่างแรงกับการตีความในสองย่อหน้าของบทความ
    จะสรุปได้ว่าแนวทางที่ดีกว่าคือพูดประมาณว่า “GPT เธอรู้จักทั้ง 50 รัฐแน่ ๆ ดังนั้นให้คืนชื่อเต็มของรัฐที่เข้าข่าย หรือถ้าเป็นรัฐบาลสหรัฐก็ให้ตอบว่า Federal”
    แต่การตีความว่าเมื่อพูดกำกวมขึ้นแล้วคุณภาพและการสรุปทั่วไปของ GPT ดีขึ้น นั่นเป็นสัญญาณแบบฉบับของการมอบหมาย/การคิดระดับสูง ฉันว่ามันเกินไป ภาษาธรรมชาติคือผลลัพธ์ที่ GPT มีความน่าจะเป็นสูงสุดอยู่แล้ว เพราะมันคล้ายกับข้อความที่ใช้ฝึก ในกรณีนี้นักพัฒนาแค่เอนเข้าหาสิ่งที่ GPT ทำได้ดี แทนที่จะให้มันทำงานมากขึ้น
    มีงานง่าย ๆ มากมายที่ทำให้ GPT พลาดได้ งานอย่างการแทนที่ตัวอักษร การสะกดผิดโดยตั้งใจ เป็นงานที่ยากมากสำหรับ GPT เช่นเดียวกับการแมป ID โดยเฉพาะเมื่อเป็นการแมปที่ต่างจากที่มันเห็นตอนฝึกมาก ๆ เช่นรหัสประเทศสามตัวอักษรที่คล้ายกันแต่ไม่ใช่ ISO
    สิ่งที่น่าสนใจคือการที่ GPT “เข้าใจ” การแมปได้ต่างหาก ฉันมองว่านั่นเป็นร่องรอยที่แท้จริงของ การจับคู่รูปแบบระดับสูง

    • หรือไม่ก็อาจเป็นแค่การ ท่องจำ การแมปก็ได้ ไม่ได้หมายความว่ามันทำซ้ำแบบเดิมเป๊ะ ๆ แต่หมายถึงมีเวกเตอร์ที่คล้ายกับการแมปที่เคยเห็นมาก่อน

  • ทิปเกี่ยวกับปัญหา null: LLM ถูกสร้างมาให้พ่นโทเคนออกมา ไม่ได้ถูกสร้างมาเพื่อไม่พ่นโทเคน
    เพราะงั้นแทนที่จะบอกว่า “อย่าคืนอะไรเลย” ก็ให้บอกว่าเมื่อไม่มีผลลัพธ์ให้ “คืนค่าเริ่มต้นของ XYZ” แล้วค่อยค้นหาข้อความนั้นในผลลัพธ์ เหมือนค้นหาชื่อสถานะ เช่น XYZ
    อีกอย่าง system prompt ก็มีประโยชน์มาก โดยพื้นฐานแล้วมันคือโอกาสที่จะให้ LLM สวมบทบาทเป็น X ถ้าเปิดให้ส่ง system prompt โดยตรงได้จะดีมาก แต่ถึงอย่างนั้นมีไว้ก็ยังดีกว่าไม่มี

  • ที่บอกว่า GPT คืนรายการออบเจ็กต์ JSON ให้ถูกต้องเกิน 10 รายการไม่ได้ นั่นเป็น ปัญหาที่พรอมป์ต์ ฉันเคยทำให้มันคืนได้อย่างเสถียรถึง 200 รายการในลำดับที่ถูกต้อง
    เคล็ดลับคืออย่าใช้รายการเลยในเอาต์พุต แต่ใช้คีย์ JSON อย่าง "item1": {...} แทน สำหรับอินพุตที่อาจมีเอาต์พุต 0~n รายการ ก็ยังใช้รายการเป็นค่าได้

    • เขากำลังบอกว่าผู้ใช้มาจากวัฒนธรรมที่มองว่าการตอบด้วย รายการที่ไม่ครบ เป็นเรื่องหยาบคายและดูหมิ่น
    • อยากให้ช่วยอธิบายเพิ่มหน่อย ตอนนี้ฉันปวดหัวกับปัญหานี้อยู่
      ถ้าให้ GPT-4 รายการของรายการที่มีอยู่พร้อมโครงสร้างที่กำหนดไว้ แล้วให้แปลงเป็น JSON แบบแปลงสคีมา มันทำได้ทั้งวันไม่มีปัญหา แต่ถ้าต้องใช้การให้เหตุผลไม่ว่าชนิดใดก็ตาม และต้องสร้างรายการขึ้นมาเองเป็นหลัก มันจะให้มาแค่บางส่วนที่จำกัดมาก
      ฉันเจอปัญหาคล้ายกันใน LLM อื่น ๆ ด้วย เลยอยากรู้มากว่าคุณใช้วิธีเข้าหาอย่างไร

  • งานอย่าง “ดึงชื่อบริษัทจากบล็อกข้อความ” แบ่งเป็น สองขั้น ได้
    ก่อนอื่นถามว่า “ในบล็อกข้อความนี้มีการกล่าวถึงบริษัทหรือไม่?” ถ้าไม่มีก็คือได้ผลลัพธ์แบบ null แล้ว ถ้ามี ค่อยถามต่อว่า “จงลิสต์ชื่อบริษัทในบล็อกข้อความนี้”

  • ฉันใช้โมเดล OpenAI ในแอปเขียนส่วนตัว และบทความนี้แม่นมาก มีสิ่งหนึ่งที่เรียนรู้ซึ่งเกี่ยวกับ Lesson 1 ที่ว่า “ยิ่งพรอมป์ต์น้อยยิ่งดี”
    ตอนสร้างฟีเจอร์ค้นหาอัจฉริยะสำหรับโน้ต ฉันพยายามให้ ChatGPT คืนข้อมูล JSON ที่มีโครงสร้าง ตัวอย่างเช่น ถามว่า “ขอโน้ตทั้งหมดของฉันที่พูดถึง Haskell ภายใน 2 ปีที่ผ่านมาและถูกทำเครื่องหมายเป็นฉบับร่าง” แล้วปล่อยให้ ChatGPT ตัดสินใจเองว่าควรคืนอะไรบ้าง วิธีนี้ใช้ได้แค่บางครั้ง
    แต่พอเอาข้อมูลใส่ฐานข้อมูล SQLite แล้วส่งสคีมาให้ ChatGPT จากนั้นให้มันเขียนคิวรีเพื่อคืนผลลัพธ์ที่ต้องการ กลับทำงานได้ดีกว่ามาก

    • ฟังดูเหมือนกรณีนี้ฐานข้อมูลกับตัวกรองค้นหาที่ดีเหมาะกว่า LLM
    • สงสัยว่าเคยลอง response_format=json_object หรือยัง
      สำหรับการได้คำตอบแบบมีโครงสร้าง การเรียกใช้ฟังก์ชันเหมาะกว่า แต่ก็มีข้อจำกัดมากกว่าการรับ JSON ตรง ๆ

  • ตัวอย่างที่ว่าพอสั่งละเอียดเกินไปแล้วความแม่นยำลดลงนั้น จากความเข้าใจแบบหยาบ ๆ ของฉันเกี่ยวกับวิธีทำงานของระบบพวกนี้ มันก็พอฟังขึ้น
    ถ้าใส่รายชื่อรัฐทั้งหมดลงไป เท่ากับไปกระตุ้นเวกเตอร์ของทุกรัฐในระดับหนึ่ง แต่ถ้าพูดแค่ว่า “state” แล้วมีชื่อรัฐที่ชัดเจนอยู่ในข้อความที่ส่งเข้าไป เวกเตอร์ที่เกี่ยวกับสิ่งที่กำลังค้นหาจะถูกกระตุ้นน้อยกว่า ดังนั้นตอนทำ softmax โอกาสที่รัฐที่ถูกต้องจะถูกเลือกก็สูงขึ้น
    ในทำนองเดียวกัน การเปรียบเทียบ /n กับลูกน้ำก็น่าจะเป็นเพราะ ความต่างของการทำโทเคนไนซ์