Skip to main content
Rinda Logo

ความแตกต่างระหว่างทีมที่ 'ใช้' AI กับทีมที่ 'เข้าใจ' AI

ทีมที่นำเครื่องมือ AI มาใช้โดยไม่มีความเข้าใจ กับทีมที่เข้าใจหลักการทำงานของ AI อย่างถ่องแท้นั้นส่งผลต่อคุณภาพของการตัดสินใจในการออกแบบผลิตภัณฑ์ ทีม Grinda AI แชร์ประสบการณ์ตรงจากการศึกษา Transformer Architecture สิ่งที่ค้นพบ และการปรับเปลี่ยนแนวทางการออกแบบผลิตภัณฑ์ให้ดีขึ้น

GRINDA AI
28 พฤษภาคม 2569
อ่าน 3 นาที
แชร์
ความแตกต่างระหว่างทีมที่ 'ใช้' AI กับทีมที่ 'เข้าใจ' AI

ความแตกต่างระหว่างทีมที่ 'ใช้' AI กับทีมที่ 'เข้าใจ' AI

🔑 สรุปใจความสำคัญ (TL;DR) ความแตกต่างที่แท้จริงของกลยุทธ์การนำ AI มาใช้ อยู่ที่ระดับระหว่างการ 'ใช้' กับการ 'เข้าใจ' เครื่องมือ ทีมที่เข้าใจหลักการทำงานของ LLM ในระดับปฏิบัติจริง จะสามารถวินิจฉัยสาเหตุของข้อผิดพลาดในการประมวลผล (Output) ได้ และยกระดับการตัดสินใจในการออกแบบผลิตภัณฑ์ให้แม่นยำยิ่งขึ้น ไม่จำเป็นต้องเขียนโค้ดเป็น เพียงแค่เข้าใจแนวคิดหลัก 3 ประการ ก็เปลี่ยนทิศทางการตัดสินใจเลือกใช้ AI ได้แล้ว

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

ภาพทีมงานคนหนึ่งกำลังมองหน้าจอโน้ตบุ๊กด้วยความสงสัย พร้อมไดอะแกรมที่ซับซ้อน

"ความเข้าใจ" ในกลยุทธ์การใช้ AI หมายถึงอะไร?

บอกตามตรงว่าในช่วงแรก ทีมของเราก็แค่เชื่อมต่อ ChatGPT API เข้ากับระบบธรรมดา ใส่ Prompt ลงไป แล้วดูผลลัพธ์ที่ออกมา การนำเครื่องมือ AI เข้ามาใช้ในตอนแรกมันไม่ใช่เรื่องยากเลย ปัญหาจริงๆ มาเกิดหลังจากนั้นต่างหาก เช่น เมื่อผลลัพธ์มีความแกว่ง หรือเมื่อได้รับผลลัพธ์ที่ต่างกันออกไปทั้งที่ Input เหมือนเดิม — เรากลับไม่รู้ว่าต้องไปแก้ไขตรงไหน หรืออธิบายอย่างไร

นี่คือจุดที่ 'ทีมที่ใช้' กับ 'ทีมที่เข้าใจ' แตกต่างกันอย่างชัดเจน

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

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

หากพูดถึงโมเดลขั้นการนำ AI มาใช้ของ Gartner ทีมส่วนใหญ่มักจะติดอยู่ระหว่าง 'Awareness' (การรับรู้) และ 'Adoption' (การเริ่มใช้งาน) หากต้องการก้าวไปสู่ 'Integration' (การบูรณาการ) ที่แท้จริง ทีมของคุณต้องสามารถอธิบายได้ว่าเครื่องมือทำงานอย่างไร

ภาพสองคนยืนอยู่หน้ากระดานไวท์บอร์ด กำลังวาดไดอะแกรมและพูดคุยกัน

ทำไมพวกเราถึงต้องอ่าน論文สถาปัตยกรรม Transformer?

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

ตอนนั้นทีมเลยพูดขึ้นมาว่า "เราแยกไม่ออกหรือเปล่าว่านี่คือ Bug หรือว่าเป็นธรรมชาติของโมเดลที่สร้างผลลัพธ์แบบสุ่ม (Probabilistic Model)?" คำถามนั้นทำให้เราเริ่มศึกษาอย่างจริงจัง ช่วงแรกที่เปิดอ่านงานวิจัยอย่าง Attention Is All You Need (2017) โดย Vaswani et al. ยอมรับเลยว่ามึนตึ้บ เห็นหน้านี้เต็มไปด้วยสูตรคณิตศาสตร์เราก็ตั้งคำถามกับตัวเองเหมือนกันว่า "เราอ่านไปทำไมนะ?"

แต่พอค่อยๆ ทำความเข้าใจเรื่อง Tokenizing, Embedding และ Positional Encoding ทีละขั้น เราเริ่มมีสัญชาตญาณในการใช้งานจริงเกิดขึ้น เราได้คำตอบสำหรับคำถามที่ว่า "ทำไมการใส่เอกสารยาวๆ ลงไปถึงทำให้ผลลัพธ์เลอะเทอะ?" ในแง่การทำงานจริง คู่มือหรือหลักสูตรทั่วไปให้ได้แค่ "สัญชาตญาณของหลักการ" เท่านั้น ซึ่งยังห่างไกลจากความสามารถในการประยุกต์ใช้จริง เรามองว่าการยอมรับความแตกต่างนี้เป็นเรื่องที่ถูกต้องและสำคัญที่สุด

ภาพทีมงานรวมตัวกันรอบโต๊ะที่มีสมุดจดและโน้ตบุ๊ก

3 กรณีศึกษาที่การเข้าใจ LLM เปลี่ยนการตัดสินใจด้านผลิตภัณฑ์ AI

เราขอยกตัวอย่าง 3 กรณีที่ความรู้เชิงทฤษฎีส่งผลต่องานจริง:

  1. กลยุทธ์การทำ Chunking: ก่อนที่จะเข้าใจขีดจำกัดของ Context Window เราใส่เอกสารธุรกิจส่งออกยาวๆ เข้าไปทั้งหมด พอเราเข้าใจหลักการ เราจึงเปลี่ยนมาแบ่งเอกสารตามหน่วยความหมาย (Chunking) ก่อนประมวลผล ซึ่งผลลัพธ์ที่ได้เสถียรขึ้นอย่างเห็นได้ชัด

  2. เกณฑ์การเลือกโมเดล: โมเดลที่คะแนนเบนช์มาร์กสูงอาจไม่ใช่คำตอบที่ดีที่สุดเสมอไป เราเริ่มโฟกัสว่าโมเดลนั้นเข้ากับคำศัพท์เฉพาะทางด้านการส่งออกและโครงสร้างเอกสารของเราหรือไม่ รวมถึงความเป็นไปได้ในการ Fine-tuning

  3. การรับมือกับข้อผิดพลาด: หลังจากเข้าใจว่า LLM ทำงานแบบสุ่ม เราจึงออกแบบ Logic การลองใหม่ (Retry Logic) ใหม่ทั้งหมด ไม่ได้แค่สั่ง "เรียกใหม่" อีกต่อไป แต่เป็นการออกแบบ Branch เงื่อนไขตามสถานการณ์แทน

อย่างไรก็ตาม ต้องขอสารภาพอย่างหนึ่งว่า การก้าวไปสู่ Agentic AI (การอนุมานหลายขั้นตอน, Tool Calling, การจัดการหน่วยความจำ) นั้นเป็นคนละระดับกับการเข้าใจ LLM พื้นฐาน การใช้งาน Framework อย่าง LangChain ไม่ได้แปลว่าคุณจะออกแบบระบบ Agentic ที่ดีได้ทันที เราเองก็ยังคงเรียนรู้อยู่เช่นกัน

ภาพหน้าจอโน้ตบุ๊กที่แสดงโค้ดและโครงสร้าง Prompt พร้อมสมุดโน้ตที่มีข้อความบันทึก

ท่ามกลางกระแส AI สารพัด สิ่งที่จำเป็นจริงๆ คืออะไร?

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

แต่ต้องมองอย่างเป็นธรรมว่า การเข้าใจ LLM ทั้งหมดผ่าน "หนังสือเล่มเดียว" เป็นเรื่องยาก ด้วยความซับซ้อนในการติดตั้งใช้งานจริง สิ่งที่หนังสือมอบให้คือ "สัญชาตญาณ" ไม่ใช่ "ศักยภาพในการทำงาน" หากคุณสัมผัสขีดจำกัดของ ChatGPT Prompt ได้แต่ไม่สามารถอธิบายเหตุผลได้ ความคาดหวังย่อมไม่ตรงกับความเป็นจริง

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

  • "ทำไมผลลัพธ์ถึงอาจไม่เสถียร"
  • "ในเงื่อนไขใดที่ไม่ควรเชื่อถือ AI"
  • "การทำ Fine-tuning มีความหมายเมื่อใด"

หากมีสัญชาตญาณใน 3 เรื่องนี้ กลยุทธ์และการตัดสินใจเรื่อง AI ของคุณจะเปลี่ยนไป หากอยากศึกษาลึกกว่านี้ คอร์สเรียนฟรีของ Stanford CS224N หรือ เอกสารอย่างเป็นทางการของ Hugging Face มีประสิทธิภาพและเป็นรูปธรรมมากกว่าวิธี "ทัก DM" มากครับ

ทำไมทีมที่เข้าใจเทคโนโลยีถึงสื่อสารกับลูกค้าได้แตกต่างออกไป

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

สิ่งที่เรากำลังศึกษาต่อคือการเพิ่มประสิทธิภาพของท่อส่งผ่าน RAG (Retrieval-Augmented Generation) และการออกแบบ Agentic Workflow ปัญหาที่เรากำลังเจอคือการจัดการข้อมูลคู่ค้าต่างชาติ (Buyer Info) ที่อัปเดตแบบเรียลไทม์ผ่าน LLM ซึ่งซับซ้อนมาก และเราจะนำมาแบ่งปันในบล็อกนี้อย่างต่อเนื่องครับ


ผู้เขียน · ทีมวิจัยการขายส่งออก RINDA (บรรณาธิการวิจัยด้านการหาคู่ค้าต่างชาติและระบบขายส่งออกอัตโนมัติ)

จัดทำกลยุทธ์และรายการตรวจสอบที่พร้อมใช้งานในงานส่งออกจริง โดยอาศัยข้อมูลจาก Pipeline การหาคู่ค้าต่างชาติของบริษัทส่งออกเกาหลีกว่า 200 แห่งและการเรียนรู้ภายในแพลตฟอร์ม RINDA


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


Q. ต้องเข้าใจหลักการ LLM ลึกแค่ไหนถึงจะช่วยตัดสินใจกลยุทธ์ AI ได้?

A. ไม่จำเป็นต้องเขียนโค้ดเป็นครับ แค่เข้าใจว่า "Context Window คืออะไร", "ผลลัพธ์ของ AI มีความน่าจะเป็นและอาจเปลี่ยนไปมาได้", "Fine-tuning สำคัญตอนไหน" — แค่ 3 อย่างนี้ก็เพียงพอต่อการวางกลยุทธ์แล้ว ส่วนที่ลึกกว่านั้นเป็นเรื่องของการสร้างผลิตภัณฑ์ครับ

Q. เริ่มเรียนสถาปัตยกรรม Transformer ได้จากที่ไหน?

A. จากประสบการณ์ของทีมเรา การเรียนผ่านคอร์สของ Stanford CS224N และ Hugging Face NLP ได้ผลใช้งานได้จริงที่สุดครับ การอ่านงานวิจัยของ Vaswani et al. แนะนำให้ทำความเข้าใจพื้นฐานก่อนแล้วค่อยอ่าน จะทำให้ย่อยข้อมูลได้ง่ายขึ้นมาก

Q. Agentic AI ถูกพูดถึงบ่อยมาก แตกต่างจากการเข้าใจ LLM อย่างไร?

A. การเข้าใจ LLM คือพื้นฐานร่างกายที่ดี แต่การออกแบบ Agentic AI คือทักษะเฉพาะชิ้น เช่น การอนุมานหลายขั้นตอน, การจัดการ Tool ต่างๆ, การใช้หน่วยความจำ — สิ่งเหล่านี้ไม่ใช่แค่การ "รู้วิธีใช้" LLM แต่เป็นเรื่องของการ "ออกแบบระบบ" พวกเราเองก็กำลังเรียนรู้อยู่เช่นกัน และการแยกสองอย่างนี้จากกันให้ชัดเจนจะช่วยให้ความคาดหวังในการใช้งานจริงไม่คลาดเคลื่อนครับ

ความเข้าใจ LLMการเรียนรู้ AI ในทีมTransformer ArchitectureAgentic AIGrinda AIการออกแบบผลิตภัณฑ์ AIเรื่องเล่าในทีมการใช้ AI ในระดับ B2B