AI Engineering จากศูนย์สู่โมเดลเฉพาะทาง

AI ไม่ได้เริ่มต้นที่ ChatGPT

คำว่า “ปัญญาประดิษฐ์” (Artificial Intelligence: AI) มักถูกเชื่อมโยงกับ ChatGPT, ภาพที่สร้างจากข้อความ หรือผู้ช่วยที่ตอบคำถามได้ทันที แต่เครื่องมือเหล่านี้เป็นเพียงช่วงหนึ่งของการพัฒนาแนวคิดที่ยาวนานกว่านั้นมาก สิ่งที่เปลี่ยนแปลงอยู่เสมอไม่ใช่เพียงชื่อของเครื่องมือ หากเป็นวิธีที่มนุษย์ใช้ทำให้คอมพิวเตอร์แก้ปัญหา

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

คอมพิวเตอร์ควรรู้วิธีแก้ปัญหาจากกฎที่มนุษย์เขียน หรือควรเรียนรู้วิธีแก้ปัญหาจากข้อมูล

การเข้าใจคำถามนี้ช่วยให้ผู้อ่านไม่มอง AI เป็นกล่องวิเศษ และช่วยแยกได้ว่าในระบบหนึ่ง ๆ ส่วนใดมาจากกฎ ส่วนใดมาจากข้อมูล และส่วนใดเป็นความสามารถของโมเดล

จากกฎที่มนุษย์เขียนสู่การตัดสินใจอัตโนมัติ

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

• หากพบคำว่า “ใบแจ้งหนี้” ให้จัดเป็นเอกสารการเงิน
• หากพบคำว่า “วันลา” หรือ…

ข้อมูลในรูปของตัวเลข

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

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

สเกลาร์: ค่าตัวเลขเพียงหนึ่งค่า

สเกลาร์ (Scalar) คือค่าตัวเลขเพียงหนึ่งค่า เช่น

7
0.25
-3.5

แม้จะดูเรียบง่าย แต่สเกลาร์ปรากฏอยู่แทบทุกขั้นตอนของการทำงานกับโมเดล ตัวอย่างเช่น

• อุณหภูมิของภาพหนึ่งภาพ
• คะแนนความมั่นใจของการจำแนกประเภท
• ค่าความสูญเสียของการฝึกหนึ่งรอบ
• ค่า Learning Rate ที่กำหนดให้การปรับพารามิเตอร์
• ค่าพารามิเตอร์หนึ่งตัวภายในโมเดล

สมมติว่าระบบ Nara รับคำถามเกี่ยวกับนโยบายการลางาน แล้วคำนวณค่าความสูญเสียได้เท่ากับ 0.42 ตัวเลข 0.42 นี้เป็นสเกลาร์ มันบอกขนาดของความผิดพลาดตามฟังก์ชันที่เลือกใช้ แต่ไม่ได้บอกด้วยตัวเองว่าผิดตรงไหน หรือควรปรับพารามิเตอร์ตัวใด การตีความต้องอาศัยบริบทของการคำนวณทั้งหมด

สเกลาร์ยังใช้เป็นตัวคูณเพื่อเปลี่ยนขนาดของข้อมูล…

Neural Network มองข้อมูลเป็นชั้น ๆ

เครือข่ายประสาทเทียม (Neural Network) เป็นวิธีจัดการข้อมูลโดยแบ่งการคำนวณออกเป็นชั้น ๆ แต่ละชั้นรับค่าจากชั้นก่อนหน้า แปลงค่าเหล่านั้น แล้วส่งต่อเป็นข้อมูลรูปแบบใหม่ให้ชั้นถัดไป แนวคิดนี้ทำให้โมเดลไม่จำเป็นต้องรับรู้กฎที่มนุษย์เขียนไว้ทุกข้อ แต่สามารถเรียนรู้ว่าคุณลักษณะใดควรใช้ประกอบการตัดสินใจจากข้อมูลตัวอย่าง

เพื่อให้เห็นภาพ ลองพิจารณางานจำแนกเอกสารบริการลูกค้าภาษาไทยว่าเป็น “เร่งด่วน” หรือ “ไม่เร่งด่วน” อินพุตอาจประกอบด้วยจำนวนคำที่เกี่ยวข้องกับการหยุดให้บริการ ระดับความไม่พอใจของลูกค้า หรือการปรากฏของคำว่า “ใช้งานไม่ได้” แต่เครือข่ายประสาทเทียมจะไม่รับรู้คำเหล่านี้ในรูปแบบความหมายโดยตรง ข้อมูลต้องถูกแปลงเป็นตัวเลขก่อน จากนั้นจึงผ่านการคำนวณหลายขั้น

Neuron: หน่วยคำนวณพื้นฐาน

หน่วยคำนวณพื้นฐานของ Neural Network มักเรียกว่า Neuron หรือ Node แต่ละหน่วยรับอินพุตหลายค่า แล้วคำนวณรวมกันเป็นเอาต์พุตหนึ่งค่า

สมมติว่าระบบได้รับคุณลักษณะสามค่า

• x1 = จำนวนครั้งที่พบคำเกี่ยวกับระบบล่ม
• x2 = ระดับความรุนแรงของปัญหา
• x3 = ระยะเวลาที่ลูกค้ารอการแก้ไข

Neuron จะให้ความสำคัญกับแต่ละคุณลักษณะไม่เท่ากัน โดยใช้ค่าที่เรียกว่า Weight หรือ “น้ำหนัก” เข้ามาคูณกับอินพุตแต่ละตัว ผลรวมเบื้องต้นเขียนได้ในรูปแบบง่าย ๆ ดังนี้

z = x1w1 + x2w2 + x3w3 +…

Tokenizer แบ่งภาษาอย่างไร

ข้อความที่ผู้อ่านเห็นบนหน้าจอไม่ได้ถูกส่งเข้าโมเดลในรูปคำหรือประโยคโดยตรง ก่อนเข้าสู่กระบวนการ Inference ข้อความจะผ่าน Tokenizer ซึ่งแปลงข้อความให้เป็นลำดับของโทเคน (Token) และมักแปลงโทเคนเหล่านั้นต่อเป็น Token ID หรือตัวเลขที่โมเดลใช้ประมวลผลได้

ลำดับโดยทั่วไปมีลักษณะดังนี้

ข้อความดิบ
↓
การเตรียมข้อความตามกติกาของระบบ
↓
Tokenizer แบ่งข้อความเป็นโทเคน
↓
แปลงโทเคนเป็น Token ID
↓
เติม Special Token หรือ Padding ตามรูปแบบที่กำหนด
↓
ส่งลำดับตัวเลขเข้าโมเดล

ตัวอย่างเช่น ข้อความ Nara ตอบคำถาม อาจถูกแบ่งเป็นโทเคนที่แทนคำเต็ม ส่วนของคำ หรืออักขระแต่ละตัวก็ได้ ขึ้นอยู่กับวิธีสร้าง Tokenizer และ Vocabulary ของโมเดลนั้น จึงไม่มีคำตอบสากลว่าข้อความหนึ่งข้อความ “มีจำนวนโทเคนเท่าใด” หากยังไม่ระบุ Tokenizer ที่ใช้

ความแตกต่างนี้สำคัญในทางปฏิบัติ เพราะจำนวนโทเคนส่งผลต่อ Context Window ความหน่วง การใช้หน่วยความจำ และในกรณีบริการแบบคิดตามการใช้งาน อาจส่งผลต่อต้นทุนด้วย

Tokenizer ทำหน้าที่อะไร

Tokenizer มีหน้าที่สองทิศทาง

• แปลงข้อความเป็นโทเคนและ Token ID เพื่อป้อนให้โมเดล
• แปลงลำดับโทเคนหรือ Token ID ที่โมเดลสร้างกลับเป็นข้อความ

โมเดลไม่ได้รับข้อความในลักษณะเดียวกับที่ผู้อ่านอ่าน แต่รับลำดับตัวเลข เช่น [152, 48, 901, 7]…

จากหน้าเว็บสู่ API

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

แต่เมื่อผลลัพธ์นั้นต้องกลายเป็นส่วนหนึ่งของซอฟต์แวร์ ความแตกต่างระหว่าง “ใช้งานผ่านหน้าจอ” กับ “เรียกใช้ผ่าน API” จะชัดเจนขึ้น การทดลองที่เคยทำด้วยตนเองต้องเปลี่ยนเป็นกระบวนการที่ระบบทำซ้ำได้ ตรวจสอบได้ และเชื่อมต่อกับงานอื่นได้

หน้าเว็บเหมาะกับการทดลอง แต่ระบบจริงต้องการสัญญาที่ชัดเจน

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

ความสะดวกนี้ทำให้หน้าเว็บเหมาะกับงาน เช่น

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

อย่างไรก็ตาม สิ่งที่เกิดขึ้นเบื้องหลังหน้าเว็บอาจไม่ปรากฏให้เห็นทั้งหมด ผู้อ่านอาจไม่ทราบแน่ชัดว่า

-…

ทำไมต้องรันโมเดลเอง

การเลือกว่าจะรันโมเดลบนเครื่องของตนเองหรือเรียกใช้ผ่านบริการ API ไม่ใช่การตัดสินใจว่าแนวทางใด “ดีกว่า” เสมอไป แต่เป็นการจับคู่ระหว่างลักษณะของงาน ข้อกำหนดของข้อมูล และทรัพยากรที่องค์กรมีอยู่จริง บางงานเหมาะกับ API เพราะต้องการเริ่มต้นเร็วและรองรับปริมาณการใช้งานที่เปลี่ยนแปลงมาก ขณะที่บางงานมีข้อมูลละเอียดอ่อนหรือจำเป็นต้องควบคุมสภาพแวดล้อมอย่างเข้มงวดจน Local AI มีเหตุผลรองรับมากกว่า

ในที่นี้ Local AI หมายถึงการนำโมเดลมาประมวลผลบนคอมพิวเตอร์ส่วนตัว เซิร์ฟเวอร์ขององค์กร หรือโครงสร้างพื้นฐานที่องค์กรควบคุมเอง ส่วน API คือการส่งคำขอไปยังผู้ให้บริการภายนอกผ่านเครือข่าย แล้วรับผลลัพธ์กลับมา การเปรียบเทียบจึงไม่ได้อยู่ที่ความสามารถของโมเดลเพียงอย่างเดียว แต่รวมถึงเส้นทางของข้อมูล ต้นทุนแฝง เวลาในการตอบ การดูแลระบบ และความรับผิดชอบเมื่อเกิดข้อผิดพลาด

กรณีของ Nara: คำถามง่าย แต่ข้อมูลไม่ง่าย

สมมติว่า Nara เป็นผู้ช่วยความรู้ภายในองค์กร ตอบคำถามจากคู่มือ นโยบาย และเอกสารภายใน เช่น

• “พนักงานที่ผ่านช่วงทดลองงานต้องยื่นเอกสารอะไรบ้าง”
• “หากลูกค้าขอยกเลิกบริการ ต้องดำเนินการตามขั้นตอนใด”
• “กรณีคืนเงินเกินวงเงินที่กำหนด ต้องขออนุมัติจากใคร”
• “นโยบายการเก็บรักษาข้อมูลลูกค้าระบุระยะเวลาเท่าใด”

คำถามเหล่านี้ดูเหมือนเป็นงานถามตอบทั่วไป…

Prompt คือสัญญาระหว่างระบบกับโมเดล

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

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

Prompt ในฐานะข้อกำหนดงาน

ในระบบซอฟต์แวร์ทั่วไป คุณไม่บอกฟังก์ชันเพียงว่า “ช่วยจัดการข้อมูลนี้ให้ดี” แต่ต้องกำหนดอินพุต กระบวนการ เงื่อนไข และเอาต์พุตที่คาดหวัง Prompt ก็ควรได้รับการออกแบบด้วยหลักการเดียวกัน แม้โมเดลจะรับคำสั่งในรูปข้อความ แต่ระบบที่นำไปใช้งานจริงควรถือว่า Prompt เป็นอินเทอร์เฟซ (Interface) ระหว่างโปรแกรมกับโมเดล

ข้อกำหนดพื้นฐานของ Prompt แบ่งได้เป็นสี่ส่วน

• เป้าหมาย: โมเดลต้องทำอะไร
• อินพุต: โมเดลต้องพิจารณาข้อมูลใด
• เงื่อนไข: โมเดลต้องปฏิบัติตามกฎหรือข้อจำกัดใด
• ผลลัพธ์:…