โมเดลไฟน์จูนของผมเหนือกว่า OpenAI GPT-4

• จากการทดสอบ 724 รายการที่ทำ การสกัดข้อมูลแบบมีโครงสร้าง จากข่าวประชาสัมพันธ์ของ ISAF โมเดลไฟน์จูนหลายตัวให้ความแม่นยำสูงกว่าตระกูล GPT-4
• การเปรียบเทียบครอบคลุม GPT-4o, GPT-4 Turbo, GPT-3.5 Turbo รวมถึงโมเดลไฟน์จูนที่อิง TinyLlama, Mistral, Llama3, Solar และ GPT-3.5
• โมเดลของ OpenAI ให้ JSON ที่ถูกต้องเสมอ และ Mistral·Llama3 ที่ไฟน์จูนแล้วก็เสถียรเช่นกัน แต่ TinyLlama มีความแตกต่างมากในด้าน ค่าที่หายไปและคุณภาพ JSON ตามเทมเพลตที่ใช้
• ในการสรุปผลสุดท้าย Mistral-7B ที่ไฟน์จูนด้วย OpenPipe ได้อันดับ 1 โดย Solar LLM และ Llama3-7B ตามมาติด ๆ
• การไฟน์จูนให้ประโยชน์ด้านความเป็นส่วนตัว การควบคุม และโอกาสลดต้นทุน แต่ก็มาพร้อม ความซับซ้อนด้าน MLOps ที่เพิ่มขึ้นในการจัดการการอนุมาน การประเมิน และการทำซ้ำผลของโมเดลที่กระจายอยู่ในหลายสภาพแวดล้อม

---

เป้าหมายการทดลองและชุดข้อมูล

• เป้าหมายคือการประเมินความแม่นยำของ LLM ที่ไฟน์จูนแล้ว ในงานสกัดข้อมูลเหตุการณ์จากข่าวประชาสัมพันธ์ของ ISAF
• ข้อมูลอยู่ในรีโพสาธารณะบน Hugging Face Hub และการประเมินทำกับ test split ที่โมเดลไม่เคยเห็น
  • ข้อมูลทดสอบประกอบด้วย 724 แถว
  • ฟิลด์ประกอบด้วย name, eventrefnumber, text, StartDate, eventtype, province, targetgroup, minkilled, mincaptured, killq, captureq, killcaptureraid, airstrike, noshotsfired, minleaderskilled, minleaderscaptured เป็นต้น
• แต่ละแถวถูกแปลงเป็นออบเจ็กต์ Pydantic เพื่อให้ตรวจสอบและประมวลผลได้ง่าย
• เอาต์พุตของโมเดลคาดหวังโครงสร้าง JSON ดังนี้
  • name
  • start_date
  • event_type
  • province
  • target_group
  • min_killed
  • min_captured
  • killq
  • captureq
  • killcaptureraid
  • airstrike
  • noshotsfired
  • min_leaders_killed
  • min_leaders_captured

วิธีประเมินโมเดลอ้างอิงของ OpenAI

• ใช้ GPT-4o, GPT-4 Turbo, GPT-3.5 Turbo เป็นตัวเปรียบเทียบอ้างอิง
• โมเดล GPT ไม่สามารถใช้พรอมป์เดียวกับโมเดลไฟน์จูนได้ตรง ๆ จึงต้องใช้พรอมป์ที่ยาวกว่า
  • ระบุรายการฟิลด์ที่ต้องสกัด
  • ให้ค่าที่อนุญาตของประเภทเหตุการณ์ จังหวัด และกลุ่มเป้าหมาย
  • รวมกฎการตีความตัวเลข
  • ใส่ตัวอย่างข่าวประชาสัมพันธ์และเอาต์พุต JSON ที่คาดหวังไว้ด้วย
• กฎการตีความตัวเลขใช้เกณฑ์ดังนี้
  • a couple ตีความเป็น 2
  • several ตีความเป็นอย่างน้อย 3
  • a few, some, a group, a small group, multiple ตีความเป็นอย่างน้อย 3
  • numerous, a handful ตีความเป็นอย่างน้อย 4
  • a large number ตีความเป็นอย่างน้อย 5
  • facilitator ไม่ใช่ leader
• การทำนายจำนวนมากรันแบบอะซิงโครนัส และเพิ่มลอจิก retry เพราะ rate limit ของ GPT-3.5 Turbo
• ผลการทำนายถูกบันทึกไว้ในฟิลด์ predictions ของแต่ละเหตุการณ์ตามชื่อโมเดล

การจัดชุดโมเดลไฟน์จูน

• หลังจากได้ผลทำนายของโมเดลอ้างอิง OpenAI แล้ว จึงเพิ่มผลทำนายจากโมเดลโลคัลที่เคยไฟน์จูนไว้และโมเดลจากบริการไฟน์จูนแบบ one-click ลงในชุดข้อมูลเดียวกัน
• โมเดลไฟน์จูนที่รวมอยู่มีดังนี้
  • tinyllama-templatefree
  • tinyllama-sharegpt
  • mistral-lora-templatefree
  • finetuned-openai-gpt-3.5-turbo-1106
  • finetuned-mistral-7b-optimised-openpipe
  • ft-solar-1-mini-chat-240612-predibase
  • finetuned-llama3-7b-32k-openpipe
• โมเดล Mistral ที่ไฟน์จูนแบบโลคัลรันในเครื่องได้ยาก จึงทำ inference บนสภาพแวดล้อม A100 ของ Modal
  • ในการประเมินภายหลัง ล้มเหลวในแทบทุกรายการ
  • ในชาร์ตแสดงเป็น mistral-lora-templatefree
• ไฟน์จูนโมเดล gpt-3.5-turbo-1106 ด้วยบริการไฟน์จูนแบบ one-click ของ OpenAI
• สร้างผลทำนายของโมเดล Mistral 7B, Mistral 8x7B และ Llama3 ด้วย OpenPipe
• ที่ Predibase มีการประเมินโมเดลที่อิง Solar LLM ของ Upstage
  • Solar LLM ถูกแนะนำว่าเป็นโมเดลที่ฝึกมาให้แข็งแกร่งในงานที่มักใช้การไฟน์จูน เช่น การสกัดข้อมูลแบบมีโครงสร้าง
  • คาดว่าโมเดลฐานคือ upstage/SOLAR-10.7B-v1.0 บน Hugging Face Hub
• การอนุมานของ Qwen2 บน Predibase ใช้งานไม่ได้ จึงถูกตัดออกจากการประเมินครั้งนี้
• ชุดข้อมูลผลทำนายสุดท้ายเผยแพร่เป็น ชุดข้อมูลสาธารณะบน Hugging Face Hub

ความถูกต้องของ JSON และค่าที่หายไป

• การประเมินแรกทำโดยตรวจสอบว่าเอาต์พุตของแต่ละโมเดลเป็น JSON ที่ถูกต้อง หรือไม่
• โมเดล OpenAI สร้าง JSON ที่ถูกต้องทุกครั้ง
• โมเดล Mistral และ Llama3 ที่ไฟน์จูนแล้วก็ให้ JSON ที่ถูกต้องอย่างเสถียร
• TinyLlama ให้ผลแตกต่างกันมากตามเทมเพลตที่เลือก
  • tinyllama-sharegpt มีค่าที่หายไป 38 รายการ
  • หากไม่มีค่าที่หายไป คาดว่าจะมีทั้งผลทำนายครบ 724 รายการและ JSON ที่ถูกต้องครบทั้งหมด
• การนับค่าที่หายไปมีดังนี้
  • gpt-4o: 0
  • gpt-4-turbo: 0
  • gpt-3.5-turbo: 0
  • tinyllama-templatefree: 0
  • tinyllama-sharegpt: 38
  • finetuned-openai-gpt-3.5-turbo-1106: 0
  • finetuned-llama3-7b-32k-openpipe: 0
  • mistral-lora-templatefree: 0
  • finetuned-mistral-7b-optimised-openpipe: 0
  • ft-solar-1-mini-chat-240612-predibase: 0

ความแม่นยำรายฟิลด์

• การประเมินความแม่นยำอิงคุณสมบัติทั้งหมด 13 รายการ
  • start_date
  • province
  • target_group
  • event_type
  • min_killed
  • min_captured
  • killq
  • captureq
  • killcaptureraid
  • airstrike
  • noshotsfired
  • min_leaders_killed
  • min_leaders_captured
• จำนวนงานทั้งหมดในทุกชาร์ตคือ 724 รายการ

• start_date

  • ในความแม่นยำของ start_date Solar และโมเดล GPT-3.5 ที่ไฟน์จูนแล้วทำผลงานดีที่สุด
  • คะแนนมีดังนี้
    • gpt-4o: 527
    • gpt-4-turbo: 522
    • gpt-3.5-turbo: 492
    • tinyllama-templatefree: 231
    • tinyllama-sharegpt: 479
    • finetuned-openai-gpt-3.5-turbo-1106: 646
    • finetuned-llama3-7b-32k-openpipe: 585
    • mistral-lora-templatefree: 0
    • finetuned-mistral-7b-optimised-openpipe: 636
    • ft-solar-1-mini-chat-240612-predibase: 649
  • แม้แต่โมเดลที่ดีที่สุดก็ยังทำนายวันที่ผิด 75 รายการ แสดงว่ายังมีพื้นที่ให้ปรับปรุงการสกัดวันที่

• province

  • ในการทำนายจังหวัด (province) โมเดลไฟน์จูนทำได้ดีกว่าโมเดล OpenAI
  • คะแนนมีดังนี้
    • gpt-4o: 649
    • gpt-4-turbo: 645
    • gpt-3.5-turbo: 595
    • tinyllama-templatefree: 335
    • tinyllama-sharegpt: 660
    • finetuned-openai-gpt-3.5-turbo-1106: 704
    • finetuned-llama3-7b-32k-openpipe: 707
    • mistral-lora-templatefree: 0
    • finetuned-mistral-7b-optimised-openpipe: 711
    • ft-solar-1-mini-chat-240612-predibase: 704

• target_group และ event_type

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

• ฟิลด์ตัวเลขและบูลีน

  • ในการประมาณค่าตัวเลขอย่าง min_killed ช่องว่างระหว่างโมเดลไฟน์จูนกับโมเดล OpenAI แคบลง
  • Mistral ได้คะแนนสูงสุด แต่ต่างกันไม่มาก และโมเดล OpenAI ก็ทำผลงานได้ดีในรายการนี้
  • มีความเป็นไปได้ว่า กฎการตีความตัวเลข ที่รวมอยู่ในพรอมป์ยาวช่วยได้
  • คุณสมบัติบูลีนอย่าง killq โมเดลส่วนใหญ่ทำความแม่นยำได้สูง
  • Mistral ที่ไฟน์จูนแล้วทำคะแนนในรายการนี้เหนือกว่าคะแนนสูงสุดของ GPT-4o ด้วย
  • killcaptureraid เป็นรายการที่โมเดล OpenAI ดูเสียเปรียบ
    • kill-capture raid เป็นศัพท์เฉพาะที่ใช้ในแบบเฉพาะในการติดป้ายกำกับ
    • โมเดล OpenAI ไม่รู้เกณฑ์การตัดสินป้ายกำกับดังกล่าว
  • noshotsfired เป็นฟิลด์ที่มาจากการที่ข่าวประชาสัมพันธ์ในบางช่วงเน้นข้อเท็จจริงว่า “ไม่มีการยิงปืน”
  • โมเดล OpenAI แสดงประสิทธิภาพในลำดับตรงข้ามกับที่คาดไว้ และต้องมีการตรวจสอบเพิ่มเติมเพื่อเข้าใจสาเหตุ
  • min_leaders_killed และ min_leaders_captured โดยรวมได้คะแนนสูง
  • ตรงข้ามกับความเชื่อทั่วไปว่า LLM ไม่ถนัดตัวเลข งานนี้กลับให้ประสิทธิภาพสูง และถึงอย่างนั้นโมเดลไฟน์จูนก็ยังให้ผลดีที่สุด

ผลสรุปรวมสุดท้าย

• นำคะแนนความแม่นยำรายฟิลด์ทั้ง 13 รายการมารวมกันแล้วหาค่าเฉลี่ย เพื่อคำนวณความแม่นยำสรุปรวมบนสเกล 0–100
• ในผลลัพธ์สุดท้าย โมเดลไฟน์จูนเหนือกว่าโมเดลตระกูล OpenAI GPT
• TinyLlama ก็มีความแม่นยำสรุปรวมสูงกว่า GPT-3.5 Turbo
• โมเดลที่ทำผลงานดีที่สุดคือ Mistral-7B ที่ไฟน์จูนบน OpenPipe
• Solar LLM และ Llama3-7B ตามหลัง Mistral-7B อย่างเฉียดฉิวมาก
• สำหรับการไฟน์จูนงานสกัดข้อมูลแบบมีโครงสร้าง แนวทางที่เหมาะสมดูเหมือนจะเป็นการเริ่มจาก Mistral-7B, Solar 7B และ Llama3-7B แล้วเปรียบเทียบว่าโมเดลใดเหมาะที่สุด
• หากดูเฉพาะความแม่นยำ โมเดลทั้งสามอาจใกล้เคียงกันมาก
• การเสิร์ฟโมเดล ประสิทธิภาพ และ latency อาจมี trade-off แยกต่างหาก

ข้อดีและต้นทุนของการไฟน์จูน

• โมเดล OpenAI ก็สามารถเพิ่มประสิทธิภาพได้หากใส่ตัวอย่างและกฎในพรอมป์มากขึ้น
• แต่เมื่อพรอมป์ยาวขึ้น ต้นทุนต่อคำขอก็เพิ่มขึ้น
• โมเดลที่ไฟน์จูนเองให้ข้อดีดังนี้
  • ความเป็นส่วนตัวของข้อมูล เพราะไม่ต้องส่งข้อมูลลับไปยัง OpenAI
  • โอกาสเพิ่มประสิทธิภาพจากโมเดลที่เล็กกว่า
  • อำนาจควบคุมที่มากขึ้น
  • โอกาสลดต้นทุน
• ขณะนี้ยังสรุปการเปรียบเทียบต้นทุนอย่างชัดเจนได้ยาก
  • ผู้ให้บริการคลาวด์รายใหญ่สามารถใช้ประโยชน์จาก economy of scale ได้
  • ใน use case จริงที่ต้อง inference ซ้ำ ๆ ในระยะยาว เหตุผลด้านต้นทุนของโมเดลที่เป็นของตัวเองอาจมีน้ำหนักมากขึ้น
  • หากต้องการปรับปรุงการเรียก OpenAI ต้องใส่ตัวอย่างและคำอธิบายจำนวนมาก ทำให้ต้นทุนต่อ query สูงขึ้น

การดำเนินงานประเมินและความซับซ้อนของ MLOps

• การไฟน์จูนทำผลงานได้ดีกว่า GPT-4 ด้วยการปรับแต่งค่อนข้างน้อย
  • โมเดลที่ใช้เป็นโมเดลไฟน์จูนชุดแรก ๆ ที่สร้างจากข้อมูลที่นำเข้ามา
  • ส่วนใหญ่ใช้ค่าเริ่มต้น
• ต่อไปมีแผนจะโฟกัสที่โมเดล Solar, Llama3 และ Mistral 7B
• การประเมินถูกทำขึ้นโดยมี Jupyter notebook เป็นศูนย์กลาง และกระบวนการดำเนินงานค่อนข้างยุ่งยาก
  • บางโมเดลทำงานบนเครื่องโลคัล
  • บางโมเดลถูก deploy ไปยังบริการและสภาพแวดล้อมที่ต่างกัน
  • วิธีวนผ่าน 724 แถวค่อนข้างช้า
• ในรอบถัดไป จำเป็นต้องทำให้การประเมินรันได้ในเครื่องโลคัล และใช้วิธีประเมินเฉพาะบาง slice ของข้อมูลก่อน แล้วจึงขยายไปยังข้อมูลทั้งหมด
• เมื่อต้องจัดการหลายโมเดลในโปรเจกต์เดียวกัน จำเป็นต้องมี อินเทอร์เฟซ inference มาตรฐาน
• เมื่อโมเดลกระจายอยู่หลายที่ มีการไฟน์จูนและอัปเดตซ้ำ ๆ และข้อมูลเปลี่ยนแปลงต่อเนื่อง ก็จำเป็นต้องมีระบบสำหรับจัดการสิ่งเหล่านี้
• trade-off หลักของ LLM ที่ไฟน์จูนคือ ต้องจัดการองค์ประกอบจำนวนมากเพื่อให้การดำเนินงานเสถียรและทำซ้ำได้

คุณค่าที่ได้จากการประเมินและขั้นถัดไป

• แม้การทำระบบประเมินจะยุ่งยาก แต่ก็ให้ เกณฑ์เฉพาะงาน สำหรับตรวจสอบว่าการปรับปรุงข้อมูลฝึกหรือโมเดลสร้างความคืบหน้าจริงหรือไม่
• หากไม่มีการประเมิน ก็ยากที่จะตัดสินได้ว่าดีขึ้นหรือไม่
• แนวคิดการสร้างโมเดลเฉพาะทางย่อยหลายตัวแยกกันยังไม่ใช่ขั้นถัดไปที่ชัดเจนในตอนนี้
  • เช่น โมเดลแยกที่เก่งเฉพาะการประมาณจำนวนผู้ถูกจับ
  • หากดูจากประสิทธิภาพของโมเดลปัจจุบัน ยังไม่ชัดเจนว่าแนวทางนี้จะเพิ่มความแม่นยำได้มากหรือไม่
• ขั้นถัดไปที่มีลำดับความสำคัญสูงคือการประเมินด้านอื่นนอกเหนือจากความแม่นยำ
  • ตัวอย่างคือการประเมินข้อมูล out-of-domain ที่กล่าวถึงในบทความก่อนหน้า
  • ต้องการตรวจสอบพฤติกรรมกับข้อมูลปลอมในหัวข้อที่แตกต่างอย่างสิ้นเชิง
• ขั้นถัดไปอีกอย่างคือการลงลึกเรื่อง การเสิร์ฟ LLM ของโมเดล 3 อันดับแรก
  • การเสิร์ฟ LLM มีเครื่องมือ trade-off และเทคนิคที่ต่างจากการเสิร์ฟโมเดลที่ไม่ใช่ LLM
• หากต้องเจาะลึกปัญหามากขึ้น แนวทางที่มีประโยชน์คือการนำเคสที่ทายผิดขึ้นเว็บอินเทอร์เฟซอย่าง Lilac หรือ Argilla เพื่อวิเคราะห์แพตเทิร์นความล้มเหลว
• การทำความเข้าใจสถานการณ์ที่ล้มเหลวอาจช่วยปรับปรุงความแม่นยำได้มากกว่าการปรับพารามิเตอร์ไฟน์จูน

[GN⁺]

ความเห็นจาก Hacker News

• ในฐานะผู้ก่อตั้ง OpenPipe มองว่า โมเดลที่ผ่านการ fine-tuning เหมาะกับงานดึงข้อมูลเป็นพิเศษอยู่แล้ว ดังนั้นผลลัพธ์ที่ออกมาดีจึงไม่น่าแปลกใจ
  ถ้าสร้างข้อมูลฝึกที่แข็งแรงได้ ก็เคยพบว่าค่อนข้างง่ายที่จะเอาชนะ GPT-4 ได้ในงานหลายประเภท และในงานวิจัยที่เผยแพร่เมื่อสัปดาห์ก่อน Llama 3 8B ที่ผ่านการ fine-tuning ก็ทำได้ดีกว่า GPT-4 ใน 3 จาก 4 งานตัวอย่าง ได้แก่ การสรุปเชิงสร้างสรรค์ การถามตอบ การดึงข้อมูล และการจัดหมวดหมู่
  หัวใจสำคัญคือการสร้างวิธีผลิตข้อมูลฝึกคุณภาพสูงแบบวนซ้ำ ซึ่งบทความก็พูดถึงประเด็นนี้ไว้: https://openpipe.ai/blog/mixture-of-agents

  • สงสัยว่าคนที่ไม่ใช่ผู้เชี่ยวชาญแต่ชื่นชอบเทคโนโลยีจะสามารถ fine-tuning แล้วนำไปใช้งานได้ง่ายแค่ไหน
    กรณีใช้งานคือการฝึกจากเอกสารเทคนิค ข่าวเฉพาะทาง บล็อกโพสต์ย้อนหลัง 2 ปี แหล่งข้อมูลปฐมภูมิ และเธรดอธิบายบน Twitter เพื่อสร้าง LLM ผู้เชี่ยวชาญเฉพาะหัวข้อ ที่รวบรวมข้อมูลเชิงลึกเฉพาะด้านของหัวข้อหนึ่งในช่วง 2 ปีล่าสุด
  • สงสัยว่าถ้าสร้าง เมตาโมเดล ด้วย LLM ที่คอยเลือกหนึ่งในหลายโมเดลที่ผ่านการ fine-tuning ตามคำถาม จะให้ผลโดยรวมดีกว่า GPT-4 ได้หรือไม่
  • สงสัยว่าการ ฝึกโมเดลใหม่จากคำตอบของโมเดล ของผู้ให้บริการ LLM รายใหญ่ (เช่น OpenAI, Anthropic) จะผิดข้อกำหนดการใช้งานหรือไม่

• ผลลัพธ์นี้ไม่ได้น่าแปลกใจเลย และสอดคล้องกับผลก่อนหน้าที่บอกว่าแม้แต่โมเดลขนาดเล็กที่ออกแบบเฉพาะทางก็ทำได้ดีกว่าในงานดึงข้อมูลและจัดประเภทข้อความ
  ตอนทำปริญญาเอกเคยทำงานสกัดเหตุการณ์/อารมณ์แบบ ACE ที่ละเอียดมาก และทรานส์ฟอร์เมอร์ขนาด “เล็ก” ที่ fine-tuning เฉพาะทางก็ทำได้ดีกว่าการพรอมป์ BERT หรือ Roberta-large
  ถ้ามี คะแนนของโมเดลขนาดเล็ก รวมกับไปป์ไลน์ล่าสุดด้วยก็น่าจะดี และถึงจะเป็นการทำซ้ำผลที่รู้กันอยู่แล้ว ก็ยังถือว่าเป็นงานที่ดี

  • มีข้อสังเกตอยู่ว่าถ้าไม่รู้วิธีสร้างโมเดลเฉพาะทางที่ดี ก็อาจมีแต่เสียเวลาและเงินของทุกคน: https://www.threads.net/@ethan_mollick/post/C46AfItO8RS?hl=e...
  • หัวข้อวิทยานิพนธ์ดูน่าสนใจ อยากรู้ว่ามีลิงก์หรือไม่

• การใช้งาน LLM แบบจริงจังที่เคยใช้แล้วมีประโยชน์ในงานจริง มีเพียง การดึง/จัดโครงสร้างข้อมูล เท่านั้น
  เคยต้องดึงจุดเริ่มต้น จุดสิ้นสุด และคำอธิบายของเหตุการณ์จากรายงานการเก็บตัวอย่างประสบการณ์ที่แชร์ออนไลน์ไม่ได้ แล้วใช้ llama.cpp รันโมเดลเพื่อแปลงเป็น CSV 4 คอลัมน์คือ onset, offset, description และระบุว่าตรงตามเงื่อนไขเฉพาะหรือไม่
  แค่ใส่ตัวอย่างโครงสร้างที่ต้องการไว้ในพรอมป์สักสองสามแบบ หลายโมเดลก็จัดการได้ดี และชอบ Mixtral 8x7b เพราะเป็นรุ่นที่เร็วที่สุดในกลุ่มคุณภาพใกล้กันบนโน้ตบุ๊ก
  สำหรับงานนี้มีโอกาสสูงที่โมเดลเล็กกว่าซึ่งผ่านการ fine-tuning จะดีกว่าและเร็วกว่า และเมื่อไม่สามารถส่งข้อมูลไปให้ OpenAI หรือผู้ให้บริการคล้ายกันได้ การประมวลผลแบบออฟไลน์จึงจำเป็น ทำให้โมเดลที่เล็ก รันในเครื่องได้ และ fine-tuning ได้ โดดเด่นขึ้นมา

  • เคยตระหนักเรื่องนี้ตั้งแต่ทดลองใช้ GPT-3 เพื่อดึงข้อมูลจากเว็บ และหลังจากโพสต์ต้นแบบแรกลง Reddit กับ HN ก็เห็นความต้องการด้านระบบอัตโนมัติสำหรับสแตก web scraping แบบอิงกฎจำนวนมาก
    นั่นนำไปสู่สตาร์ทอัพ https://kadoa.com ที่ทำระบบอัตโนมัติกับปัญหา “น่าเบื่อและยาก” นี้ ซึ่งต้องบำรุงรักษาสูงและขยายได้ยาก
    จุดที่ AI สร้างมูลค่าได้มากที่สุดน่าจะเป็นกรณีใช้งานที่ไม่หวือหวามากแบบนี้ และแทนที่จะลบงาน มันจะช่วยทำงานซ้ำ ๆ อย่าง web scraping, กรอกแบบฟอร์ม, ป้อนข้อมูล ให้เป็นอัตโนมัติ
  • ขั้นต่อไปอยากทำงานด้าน deployment/inference เพื่อดูว่าสามารถย่อโมเดลให้เล็กได้แค่ไหน
    Spacy ผลักดันแนวทางนี้มานานแล้วด้วยโมเดลขนาดหลักสิบ MB และก็น่ายินดีที่ตอนนี้คนเริ่มสนใจกันมากขึ้น
    ในอุดมคติอยากให้มี โมเดลจิ๋วมาก จำนวนมากที่เฉพาะทางสุด ๆ ขนาดเล็กและอนุมานได้เร็ว แต่ถ้าจัดการระบบไม่ดี สักจุดหนึ่งการดูแลให้ทุกตัวทันสมัยอยู่เสมอก็จะเกินรับไหว

• นั่นแหละคือหัวใจของการ fine-tuning โมเดล
  ชอบที่มีการพาไล่ดูขั้นตอน fine-tuning โดยผสมทั้งตัวเลือกแบบโฮสต์และแบบรันในเครื่อง

  • สงสัยว่ามีบริการดี ๆ แบบ “นี่คือชุดข้อมูล ช่วย fine-tuning โมเดล 9 ตัวนี้แล้วส่งสถิติการประเมินกลับมา” หรือไม่
  • ประเด็นสำคัญไม่ใช่แค่ว่า fine-tuning โมเดลแล้วดีขึ้น แต่คือการเอาโมเดลที่ง่ายกว่ามากมาทำ fine-tuning แล้วเอาชนะโมเดลที่ล้ำหน้ากว่ามากได้

• บทความเขียนดีและให้ข้อมูลมาก
  สังเกตว่าในการทดสอบ GPT ของตัวอย่างใช้ temperature=1 เลยสงสัยว่านี่เป็นแนวปฏิบัติที่ดีสำหรับงานที่ต้องการ structured output หรือไม่
  เท่าที่เข้าใจคร่าว ๆ งานลักษณะนี้น่าจะเหมาะกับ temperature 0 ที่สุด ส่วน temperature สูงเหมาะกับงานเชิงสร้างสรรค์มากกว่า

  • ตั้งค่าตามคำแนะนำของแต่ละโมเดล
    ผู้ให้บริการ fine-tuning LLM บางรายระบุให้ใช้ temperature 0 โดยตรงก็ทำตามนั้น ส่วนบางรายแนะนำ 1
    สามารถทดลองซ้ำเพื่อหาค่าที่ดีที่สุดสำหรับแต่ละโมเดลได้ และถ้าเป็นโมเดลที่จะโฟกัสต่อในรอบถัดไป/การ fine-tuning ต่อ ก็อาจคุ้มที่จะทำแบบนั้น

• อยากเห็นตัวอย่างที่ GPT-4o ตอบผิด แต่โมเดลที่ทำคะแนนดีที่สุดตอบถูก
  อีกอย่างในฐานะคนที่ทำงานดึงข้อมูลแบบมีโครงสร้างมาเยอะ อยากให้ลองใหม่ด้วย temperature 0 เพราะจากประสบการณ์ควรใช้ 0 เสมอ และความต่างอาจมากทีเดียว
  temperature 1 หมายความว่าในทางปฏิบัติมันเริ่มเลือกโทเคนที่มีโอกาสถูกต้องต่ำลงด้วย

  • สำหรับกรณีใช้งานนี้ที่อิงข้อมูลย้อนหลังและมีคำตอบถูก/ผิดชัดเจน การเปรียบเทียบที่ temperature 0 น่าจะน่าสนใจ
    ตอนทดลอง temperature กับ AI SQL editor พบว่า 0.3 เหมาะที่สุด เพราะยิ่งใกล้ 0 ยิ่งเหมาะกับความแม่นยำ แต่ถ้าเกิดข้อผิดพลาดขึ้นมาก็จะกู้ตัวเองกลับได้ยาก

• เคยเขียนบทความวิจัยในประเด็นคล้ายกัน: https://www.nature.com/articles/s41467-024-45563-x

• สงสัยว่าเนื้อหาที่อาจก่อให้เกิดข้อถกเถียงในข่าวต้นทาง จะส่งผลต่อความสามารถในการสรุปของ ChatGPT หรือไม่

  • กำลังใช้ OpenAI Azure สำหรับดึงข้อมูลด้วย LLM จากข่าวการเงิน และนี่เป็นปัญหาใหญ่
    แค่ข้อความข่าวการเงินอย่างเดียวก็ทำให้ 4% ของบทความได้ 404 content moderation response แล้ว ซึ่งเป็นหนึ่งในเหตุผลหลักที่กำลังพิจารณาโมเดลแบบเปิด
  • ไม่น่าจะใช่แบบนั้น
    ปกติถ้าเกิดข้อผิดพลาดแบบนั้นมักจะไม่มีเอาต์พุตออกมาเลย แต่ในบทความแสดงให้เห็นว่าได้ JSON ปกติจากทั้ง 724 เคสทดสอบสำหรับทุกคำถาม
    หัวข้อแบบนี้น่าจะอยู่ในข้อมูลฝึกค่อนข้างมาก และโมเดลโอเพนซอร์สก็น่าจะใช้ข้อมูลคล้ายกัน จึงไม่น่ามีช่องว่างใหญ่มากระหว่างโมเดลปิดกับโอเพนซอร์ส

• ขอเสี่ยงพูดให้ดูเหมือนคนรุ่นเก่าว่า ลำดับความสำคัญสูงสุดควรเป็นการทำให้ ทุกโมเดลเปิดกว้างและเป็นโอเพนซอร์สให้มากที่สุด เพื่อให้ทุกคนสามารถนำไป fine-tuning ได้
  นี่เป็นกรณีย่อยของแนวคิดที่ว่าเสรี/โอเพนซอร์สมักดีกว่าทั้งในแง่เสรีภาพและคุณภาพ

  • ฟังดูเหมือนว่าฝั่งที่สะสมข้อมูลส่วนบุคคลไว้มากที่สุดและอ้างสิทธิ์ความเป็นเจ้าของ จะเป็นฝ่ายสร้างผลิตภัณฑ์ที่ดีที่สุดได้
    คล้ายกับเมื่อก่อนที่โฆษณาแบบปรับแต่งเฉพาะบุคคลดู “เกี่ยวข้อง” มากกว่าจึงถูกมองว่าดีกว่า แต่ตอนนี้ไม่ได้มีแค่โฆษณา แม้แต่ผลิตภัณฑ์ที่มีประโยชน์ก็เป็นแบบนั้นด้วย
    เจ้าของแพลตฟอร์มอย่าง Apple หรือ Microsoft สามารถดึงข้อมูลจากแอปและผลิตภัณฑ์ต่าง ๆ ได้ แม้กระทั่งจากในเครื่อง จึงได้เปรียบมากกว่าการนำหน้าด้านคุณภาพโมเดลเพียง 3-6 เดือนเสียอีก
    ไม่ชอบความรวมศูนย์ของเทคโนโลยีนี้ และแม้การที่โมเดลเล็กที่ผ่านการ fine-tuning ทำได้ดีกว่าจะเป็นสัญญาณที่น่าหวัง แต่แค่ ความเปิดกว้างและความเป็นส่วนตัว อย่างเดียวอาจยังเอาชนะไม่ได้ หรือแทบไม่มีโอกาสเลย
    ทางที่ดีที่สุดคือให้โมเดลเปิดแพร่หลายในพื้นที่บริการของธุรกิจขนาดเล็กและกลางอย่างมีประสิทธิภาพ จนไม่จำเป็นต้องจ่ายค่าโทเคน OpenAI โดยไม่จำเป็น
    นี่น่าจะเป็นแผนของ Zuck มาตั้งแต่แรก และอาจตั้งใจสกัดกั้นไม่ให้เกิดผู้เฝ้าประตูแบบรวมศูนย์ในเทคโนโลยีที่คู่แข่งได้ประโยชน์เป็นหลัก
    ถึงอย่างนั้น ศัตรูของศัตรูก็ยังเป็นมิตร และนี่อาจเป็นหนึ่งในการกระทำเพื่อประโยชน์สาธารณะที่ดีที่สุดที่เขาเคยทำก็ได้

• ช่วงหลังที่ Predibase ทำ การทดลอง fine-tuning มากกว่า 700 ครั้ง เพื่อ benchmark ประสิทธิภาพของโอเพนซอร์ส LLM ยอดนิยมใน 30 งาน และเทียบกับ GPT-4
  ใน 85% ของกรณีสามารถชนะ GPT-4 ได้ และดูผลได้ที่นี่: https://predibase.com/fine-tuning-index
  ในเว็บมีทั้งกราฟแบบอินเทอร์แอกทีฟและลิงก์ไปยังบทความบน Arxiv