สรุปจากคลิป ดูคลิปต้นฉบับ

What Lies Beneath the API เมื่อไรธุรกิจควรเริ่ม Fine-tune AI

หลายทีมเริ่มใช้ AI ด้วยการเรียก API จาก model ระดับ frontier แล้วโตได้เร็วมาก แต่มักมีจุดหนึ่งที่เริ่มรู้สึกว่า “ของเดิมดี แต่ยังไม่ใช่ของเรา” ค่าใช้จ่ายสูงขึ้น ความหน่วงเริ่มกระทบงานจริง และผลลัพธ์เริ่มตันแม้จะลองปรับ prompt ไปมากแล้ว นี่คือประเด็นหลักจากคลิป What Lies Beneath the API บนช่อง AI Engineer ที่ชวนคิดได้ตรงมากสำหรับเจ้าของธุรกิจและคนทำงานที่อยากใช้ AI แบบเอาไปทำเงินได้จริง

หัวใจของคลิปไม่ได้บอกให้ทุกทีมรีบเทรน model ทันที แต่ชี้ให้เห็นว่า เมื่อสินค้าหรือบริการเริ่มมีความเฉพาะทางมากขึ้น เรามักเดินเข้าใกล้จุดที่ควรมี model ของตัวเองมากขึ้นเรื่อยๆ ประเด็นนี้สำคัญกับธุรกิจไทยมาก เพราะหลายทีมยังคิดว่า fine-tuning เป็นเรื่องไกลตัว ทั้งที่จริงสิ่งที่ต้องใช้ในการเริ่มต้น อาจมีอยู่ในระบบงานแล้ว

สารบัญ

• Step 1: เข้าใจก่อนว่า API อย่างเดียวอาจไม่พอเมื่อธุรกิจเริ่มโต
• Step 2: มองภาพ “สเปกตรัมของ model” ให้ขาด
• Step 3: เช็ก 3 สัญญาณว่าเริ่มถึงเวลา fine-tune แล้วหรือยัง
• Step 4: อย่าเพิ่งเทรน ถ้ายังไม่มี data และ eval ที่เชื่อถือได้
• Step 5: ถ้ามี agent harness อยู่แล้ว เราอาจใกล้กว่าที่คิด
• Step 6: เข้าใจว่า fine-tuning วันนี้ไม่ได้หนักเหมือนเมื่อก่อน
• Step 7: รู้จัก RL ในมุมธุรกิจ ไม่ใช่มองว่าเป็นของงานวิจัยเท่านั้น
• Step 8: อย่าลืมว่าเทรนเสร็จแล้ว ยังต้องเสิร์ฟ model ให้คุ้ม
• Step 9: แปลงบทเรียนนี้ให้เข้ากับธุรกิจไทย
• Step 10: Actionable Insights ที่เอาไปทำต่อได้ทันที
• Step 11: Troubleshooting ปัญหาที่มักเจอเมื่อเริ่มคิดเรื่อง fine-tuning
• Step 12: การต่อยอดที่ควรคิดต่อจากคลิปนี้
• Step 13: สรุป Checklist ทั้งหมด

Step 1: เข้าใจก่อนว่า API อย่างเดียวอาจไม่พอเมื่อธุรกิจเริ่มโต

ช่วงเริ่มต้น การใช้ frontier API เป็นทางเลือกที่สมเหตุสมผลมาก เพราะเริ่มได้เร็ว ไม่ต้องตั้งทีม infra ไม่ต้องดูแล cluster และทดลอง use case ใหม่ๆ ได้แทบจะทันที ธุรกิจที่ต้องรีบพิสูจน์ตลาดควรเริ่มแบบนี้ก่อนแทบทั้งหมด

แต่ข้อจำกัดของวิธีนี้ก็ชัดมากเช่นกัน เราปรับได้หลักๆ แค่ prompt, system instruction และ workflow รอบ model เท่านั้น พอผลิตภัณฑ์เริ่มจริงจังขึ้น ความต้องการจะไม่ใช่แค่ “ตอบได้” แต่กลายเป็น “ตอบแบบที่ธุรกิจเราต้องการ” เช่น ต้องใช้ภาษาเฉพาะอุตสาหกรรม ต้องตัดสินใจตาม policy ภายใน ต้องเร็วพอสำหรับงาน call center หรือแชต support ปริมาณมาก

มุมที่น่าสนใจจากคลิปคือ ผู้ให้บริการ model ระดับ frontier พยายามชนะทุกสนามพร้อมกัน แต่ธุรกิจของเราไม่ได้ต้องการ model ที่เก่งทุกเรื่อง เราต้องการ model ที่เก่งเรื่องที่เกี่ยวกับรายได้ ต้นทุน และ logic ของธุรกิจเราเท่านั้น

สำหรับธุรกิจไทย ภาพนี้ชัดมากในงานประเภทต่อไปนี้

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

ถ้างานของเราเริ่มเป็นแบบนี้ นั่นคือสัญญาณว่า model ทั่วไปอาจเริ่มไม่พอแล้ว

Step 2: มองภาพ “สเปกตรัมของ model” ให้ขาด

คลิปอธิบายภาพได้ดีมากว่าโลกของ AI ไม่ได้มีแค่สองฝั่ง คือใช้ API สำเร็จรูป หรือไม่ก็ต้องสร้างทุกอย่างเองบน infra ขนาดใหญ่ ความจริงมีพื้นที่ตรงกลางที่เริ่มใช้งานได้จริงมากขึ้น

ฝั่งหนึ่งคือ frontier API ที่เริ่มไวและสะดวกมาก แต่อีกฝั่งคือการเทรนและเสิร์ฟ model เองทั้งหมด ซึ่งให้การควบคุมสูงสุดแต่ก็แบกภาระมากสุด ทั้งเรื่อง compute, deployment, scaling และทีมงาน

ประเด็นสำคัญจากคลิปคือ ตอนนี้เริ่มมี platform แบบ serverless compute ที่ช่วยให้ทีมขยับจาก “แค่เรียก API” ไปสู่ “ควบคุม algorithm และ deployment มากขึ้น” โดยไม่ต้องแบก infra แบบเต็มตัว นี่คือพื้นที่กลางที่ทำให้ fine-tuning เข้าถึงได้ง่ายกว่าเดิม

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

มุมที่เราเห็นด้วยมากคือ หลายทีมไม่แพ้เพราะ model ไม่เก่ง แต่แพ้เพราะเลือก architecture ผิดช่วงเวลา บางทีมรีบสร้างเองเร็วเกินไปจนแบกต้นทุน บางทีมใช้ API ยาวเกินไปจนเสีย margin และเสียโอกาสสร้าง moat

Step 3: เช็ก 3 สัญญาณว่าเริ่มถึงเวลา fine-tune แล้วหรือยัง

คลิปเสนอ 3 สัญญาณที่ใช้ตัดสินใจได้ตรงและ practical มาก

1) ค่า API สูงจน margin เริ่มพัง

ถ้าค่า model สูงขึ้นตาม usage จนรายได้ต่อหนึ่งลูกค้าโตไม่ทัน นี่ไม่ใช่แค่ปัญหาเทคนิค แต่เป็นปัญหา unit economics โดยตรง ต่อให้ยอดขายเพิ่ม ธุรกิจก็อาจไม่เหลือกำไร

ตัวอย่างที่เห็นภาพสำหรับไทยคือธุรกิจแชตขายของหรือ customer support ที่ต้องตอบหลายรอบต่อเคส หากทุกข้อความไปพึ่ง model ราคาแพงทั้งหมด ต้นทุนจะพุ่งเร็วมาก

2) คะแนน eval เริ่มตัน

ถ้าเราลอง prompt engineering, RAG, workflow orchestration มาหลายรอบแล้ว แต่คุณภาพไม่ดีขึ้น นี่อาจแปลว่าปัญหาไม่ได้อยู่ที่ prompt แล้ว แต่อยู่ที่ model ยังไม่เข้าใจงานเฉพาะทางของเราในระดับพอใช้จริง

3) latency หรือ throughput ไม่ตอบโจทย์

บางงานไม่ได้วัดกันที่คำตอบสวยที่สุด แต่ต้องเร็วพอและรับโหลดได้ เช่น ระบบช่วย agent หน้าบ้าน ระบบ voice processing หรือระบบภายในที่มีผู้ใช้จำนวนมาก endpoint แบบ shared อาจตอบโจทย์ไม่พอ

สรุปง่ายๆ คือ ถ้าเจออย่างน้อยหนึ่งข้อ เราควรเริ่มคิดเรื่อง fine-tuning และ custom inference อย่างจริงจัง ไม่ใช่รอจนระบบตันก่อน

Step 4: อย่าเพิ่งเทรน ถ้ายังไม่มี data และ eval ที่เชื่อถือได้

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

นี่เป็นมุมที่เจ้าของธุรกิจต้องจำให้ขึ้นใจ เพราะหลายทีมอยากข้ามไปสู่คำว่า fine-tuned model เร็วเกินไป ทั้งที่ยังตอบไม่ได้เลยว่า

• งานแบบไหนคือ output ที่ดี
• จะวัดดีหรือไม่ดียังไง
• เคสพังที่เจอบ่อยคืออะไร
• ข้อมูลจริงที่ลูกค้าใช้มีหน้าตาแบบไหน

ถ้าจะเริ่มให้ถูกทาง ธุรกิจควรเก็บสิ่งเหล่านี้ก่อน

• คำถามจริงจากลูกค้าหรือทีมงาน
• คำตอบที่ถือว่า “ผ่าน” และ “ไม่ผ่าน”
• เหตุผลของการตัดสินว่า output ดีหรือไม่ดี
• ประเภทของงานที่ model ทำพลาดบ่อย
• เกณฑ์วัด เช่น ความแม่นยำ เวลาเฉลี่ย ต้นทุนต่อเคส อัตราการส่งต่อให้คน

ถ้าเรามีของพวกนี้เมื่อไร นั่นคือรากฐานของการเทรนที่เริ่มจับต้องได้แล้ว

Step 5: ถ้ามี agent harness อยู่แล้ว เราอาจใกล้กว่าที่คิด

หนึ่งใน insight ที่ดีที่สุดของคลิปคือ ถ้าเราเคยสร้าง agent workflow หรือระบบทดสอบการทำงานของ AI มาก่อน เราอาจมีส่วนประกอบที่จำเป็นสำหรับการเทรนอยู่แล้ว

เหตุผลคือระบบพวกนี้มักมีครบทั้ง input, output, feedback loop และข้อมูลว่าคำตอบแบบไหนเวิร์กหรือไม่เวิร์ก ซึ่งทั้งหมดคือวัตถุดิบสำคัญของ supervised fine-tuning หรือแม้แต่ reinforcement learning

แปลเป็นภาษาคนทำธุรกิจคือ ถ้าองค์กรมี

• ประวัติแชตหรือ ticket support
• การให้คะแนนคำตอบจากทีมงาน
• workflow ที่ให้ AI ลองทำงานแล้วมีผลลัพธ์ให้เทียบ
• ชุดกรณีทดสอบที่ใช้ประเมินคุณภาพประจำ

เราไม่ได้เริ่มจากศูนย์แล้ว เราแค่ยังไม่ได้จัดสิ่งเหล่านี้ให้กลายเป็น training pipeline เท่านั้นเอง

สำหรับธุรกิจไทย นี่เป็นข่าวดีมาก เพราะหลายองค์กรมีข้อมูลอยู่แล้วใน CRM, helpdesk, call log, knowledge base และเอกสาร SOP ปัญหาไม่ได้อยู่ที่ไม่มีข้อมูล แต่อยู่ที่ข้อมูลยังไม่ถูกจัดให้อยู่ในรูปที่ model เรียนรู้ต่อได้

Step 6: เข้าใจว่า fine-tuning วันนี้ไม่ได้หนักเหมือนเมื่อก่อน

ผู้พูดเน้นหลายครั้งว่า การเทรน model สมัยนี้ง่ายขึ้นมากเมื่อเทียบกับอดีต มี open source libraries และ serverless platform ที่ช่วยลดงาน infra ลงไปเยอะมาก จุดนี้สำคัญเพราะมันเปลี่ยนคำถามจาก “ทำได้ไหม” เป็น “ควรทำเมื่อไร”

ในคลิปมีตัวอย่างว่า supervised fine-tuning ทำได้ในราว 300 บรรทัดของ Python ประเด็นนี้ไม่ได้หมายความว่าทุกทีมจะทำได้ภายในวันเดียว แต่สะท้อนว่าความซับซ้อนเชิงเทคนิคเริ่มลดลง และ barrier หลักกำลังย้ายไปอยู่ที่ data quality กับ decision making มากกว่า

มุมที่ควรระวังคือ “เขียนไม่กี่ร้อยบรรทัด” ไม่ได้แปลว่าโปรเจกต์จะง่ายทั้งหมด สิ่งที่ยังยากเสมอคือ

• เลือก use case ที่คุ้ม
• จัดข้อมูลให้สะอาด
• ออกแบบ eval ให้ตรงกับ KPI ธุรกิจ
• รู้ว่าเมื่อไรควรหยุดลอง

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

Step 7: รู้จัก RL ในมุมธุรกิจ ไม่ใช่มองว่าเป็นของงานวิจัยเท่านั้น

อีกช่วงที่น่าสนใจมากคือการพูดถึง reinforcement learning หรือ RL ซึ่งหลายคนมักมองว่าเป็นเรื่องไกลตัว แต่คลิปชี้ว่าถ้า model ต้อง “ฝึกทำงาน” ผ่านการลองหลายรอบในสภาพแวดล้อมที่วัดผลได้ RL จะมีประโยชน์มาก

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

ในเชิงธุรกิจไทย RL อาจเหมาะกับงานอย่าง

• agent ที่ต้องเลือกขั้นตอนตอบลูกค้าตามสถานการณ์
• workflow ที่ต้องใช้หลายเครื่องมือร่วมกัน
• ระบบช่วยพนักงานที่ต้องตัดสินใจตามกฎหลายชั้น

อย่างไรก็ดี นี่คือจุดที่เราเห็นว่าหลายทีมไม่จำเป็นต้องเริ่มด้วย RL ก่อน ถ้ายังไม่มี eval ที่ชัด หรือยังควบคุมสภาพแวดล้อมไม่ได้ การเริ่มจาก supervised fine-tuning มักง่ายกว่าและคุมความเสี่ยงได้ดีกว่า

Step 8: อย่าลืมว่าเทรนเสร็จแล้ว ยังต้องเสิร์ฟ model ให้คุ้ม

หลายทีมคิดถึงแต่การเทรน แต่คลิปเตือนว่าของจริงยังมีเรื่อง inference ต่อ เพราะสุดท้าย model ต้องรับทราฟฟิกจริง และควร scale ตามปริมาณงานได้

มีการยกเครื่องมืออย่าง vLLM ขึ้นมาเป็นตัวอย่างของการเสิร์ฟ model ที่ใช้จริงได้ พร้อมแนวคิดเรื่อง autoscaling บน serverless platform ซึ่งช่วยให้เราไม่ต้องจ่าย fixed cost สูงตลอดเวลา

มุมธุรกิจที่ต้องคิดเพิ่มคือ ถ้าเราจะทำ custom model สิ่งที่ต้องวัดไม่ใช่แค่คุณภาพ แต่รวมถึง

• ต้นทุนต่อคำขอ
• ความเร็วตอบกลับ
• ความเสถียรช่วงทราฟฟิกพีค
• การ fallback เมื่อตอบไม่ได้

พูดอีกแบบคือ model ที่เก่งขึ้นแต่เสิร์ฟจริงไม่ไหว ก็ยังไม่ใช่คำตอบ

Step 9: แปลงบทเรียนนี้ให้เข้ากับธุรกิจไทย

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

ตัวอย่างการนำไปใช้ที่เห็นภาพ

• ธุรกิจบริการ ใช้ข้อมูล ticket support เพื่อ fine-tune model ให้ตอบในสไตล์แบรนด์และลดการส่งต่อให้คน
• ธุรกิจ B2B ใช้เอกสาร proposal, FAQ, ข้อยกเว้น และประวัติดีล เพื่อสร้างผู้ช่วยเซลส์ที่ตอบแม่นกว่า model ทั่วไป
• ธุรกิจประกัน การเงิน อสังหา ใช้ข้อมูลแบบฟอร์มและกฎภายในเพื่อให้ model ช่วยคัดกรอง เคลม หรือประเมินเคสเบื้องต้น
• องค์กรขนาดกลาง เริ่มจาก custom inference endpoint ก่อน ถ้าต้นทุน API และ latency เริ่มกด margin

ส่วนจุดที่ต้องไม่หลงคือ ไม่ใช่ทุกธุรกิจจำเป็นต้อง fine-tune เสมอ บางเคสแค่จัด knowledge base ใหม่ ทำ RAG ให้ดีขึ้น หรือออกแบบ workflow ใหม่ ก็อาจพอแล้ว การจะขยับไปเทรนควรมีเหตุผลเชิงธุรกิจรองรับ ไม่ใช่ทำเพราะฟังดูเท่

Step 10: Actionable Insights ที่เอาไปทำต่อได้ทันที

• ลิสต์ use case ที่ AI มีผลต่อรายได้ ต้นทุน หรือความเร็วงานโดยตรงก่อน use case ที่แค่ดูน่าสนใจ
• เก็บ eval data ทุกสัปดาห์ แยกให้ชัดว่า output แบบไหนผ่านหรือไม่ผ่าน และเพราะอะไร
• คำนวณต้นทุนต่อคำขอ เทียบกับรายได้หรือมูลค่างานที่ AI สร้างให้ เพื่อรู้ว่า economics เริ่มตึงหรือยัง
• จัดข้อมูลจากระบบจริง เช่น ticket, chat, SOP, feedback ให้พร้อมใช้ต่อยอดเป็น training set
• เริ่มจากโจทย์เล็ก ที่วัดผลได้ก่อน เช่น งานตอบซ้ำๆ หรือ classify งานภายใน ไม่ต้องเริ่มจาก assistant ครอบจักรวาล

Step 11: Troubleshooting ปัญหาที่มักเจอเมื่อเริ่มคิดเรื่อง fine-tuning

• ปัญหา: อยาก fine-tune แต่ไม่แน่ใจว่าคุ้มหรือไม่
  สาเหตุ: ยังไม่มี metric ธุรกิจที่ชัดว่าปัญหาปัจจุบันคืออะไร
  วิธีแก้: วัด 3 อย่างก่อน ได้แก่ ต้นทุนต่อคำขอ, latency, และคะแนน eval เทียบกับเป้าหมายงานจริง
• ปัญหา: มีข้อมูลเยอะ แต่ใช้เทรนไม่ได้
  สาเหตุ: ข้อมูลกระจัดกระจาย ไม่มี label หรือไม่มีตัวอย่างคำตอบที่ถือว่าดี
  วิธีแก้: เลือก use case เดียวก่อน จากนั้นดึงตัวอย่าง 100 ถึง 300 เคสที่มีคุณภาพ แล้วให้ทีมงานช่วย annotate
• ปัญหา: ปรับ prompt มาหลายรอบแล้ว แต่ผลไม่ดีขึ้น
  สาเหตุ: ข้อจำกัดอยู่ที่ model ยังไม่เข้าใจงานเฉพาะทาง ไม่ใช่ที่ prompt
  วิธีแก้: ทดสอบด้วยชุด eval เดิม ถ้าคะแนนนิ่งหลายรอบ ให้เริ่มประเมิน supervised fine-tuning
• ปัญหา: กลัวว่าการเทรนต้องใช้ทีมเทคนิคใหญ่
  สาเหตุ: ยึดภาพจำเดิมว่าต้องมี cluster และดูแล infra เองทั้งหมด
  วิธีแก้: สำรวจทางเลือกแบบ managed หรือ serverless platform และเริ่มจาก proof of concept ขนาดเล็ก
• ปัญหา: model ดีขึ้น แต่เสิร์ฟจริงแล้วแพงหรือช้า
  สาเหตุ: คิดเรื่อง training แต่ไม่ออกแบบ inference ตั้งแต่แรก
  วิธีแก้: วางแผน deployment พร้อมกันตั้งแต่ต้น และประเมินเครื่องมืออย่าง vLLM หรือ inference server ที่เหมาะกับโหลดจริง

Step 12: การต่อยอดที่ควรคิดต่อจากคลิปนี้

• ทำ AI readiness audit ภายในองค์กร เพื่อเช็กว่า data, eval, workflow และ KPI พร้อมแค่ไหนสำหรับการทำ custom model
• เลือก 1 use case ที่มี volume สูง แล้วทำ benchmark ระหว่าง frontier API, RAG และ fine-tuned model เพื่อดูความคุ้มจริง
• ออกแบบระบบ feedback จากทีมงานให้กลายเป็น training asset อัตโนมัติ เช่น ปุ่มให้คะแนนคำตอบหรือแก้คำตอบแล้วบันทึกกลับเข้าระบบ

Step 13: สรุป Checklist ทั้งหมด

• ☐ ระบุ use case ที่ AI มีผลต่อรายได้ ต้นทุน หรือความเร็วงานชัดเจน
• ☐ ประเมินว่าตอนนี้ยังเหมาะกับ frontier API หรือเริ่มเข้าเขตงานเฉพาะทางแล้ว
• ☐ เช็ก 3 สัญญาณหลัก ได้แก่ ค่า API สูงเกิน, eval ตัน, latency ไม่พอ
• ☐ จัดเก็บข้อมูลใช้งานจริงจาก chat, ticket, SOP หรือ workflow ภายใน
• ☐ สร้างระบบ eval ที่ตอบได้ว่า output แบบไหนดีหรือแย่
• ☐ ตรวจว่ามี agent harness หรือ feedback loop ที่ใช้เป็น training data ได้แล้วหรือยัง
• ☐ เริ่มจาก supervised fine-tuning ก่อน ถ้ายังไม่พร้อมสำหรับ RL
• ☐ วางแผนเรื่อง inference และ autoscaling ไปพร้อมกับ training
• ☐ ทำ proof of concept ขนาดเล็กก่อนลงทุนเต็ม
• ☐ ตัดสินใจจาก economics และ KPI ธุรกิจ ไม่ใช่จากกระแส

สรุปแล้ว แก่นของ What Lies Beneath the API คือการเตือนว่า API เป็นจุดเริ่มต้นที่ดี แต่ไม่ใช่ปลายทางของทุกธุรกิจ เมื่อผลิตภัณฑ์เริ่มมีความเฉพาะทางมากขึ้น ข้อมูลและกฎธุรกิจของเราจะกลายเป็นทรัพย์สินที่ model ทั่วไปเลียนแบบไม่ได้

คำถามที่ควรถามต่อจึงไม่ใช่ “ต้อง fine-tune ตอนนี้ไหม” แต่คือ “ถ้าอีก 6 ถึง 12 เดือนเราจำเป็นต้อง fine-tune วันนี้เราเริ่มเตรียม data, eval และ workflow ไว้หรือยัง” ทีมที่ตอบคำถามนี้ได้ก่อน มักจะไม่ใช่ทีมที่วิ่งตาม AI แต่เป็นทีมที่ค่อยๆ เปลี่ยน AI ให้กลายเป็นข้อได้เปรียบของธุรกิจตัวเอง