Embedding คืออะไร: ทำไม AI ถึงเข้าใจว่าความหมายใกล้กัน
ลองพิมพ์คำว่า “รถยนต์ไฟฟ้า” ลงในช่องค้นหาของเว็บยุคใหม่ แล้วได้ผลลัพธ์ที่มีคำว่า “EV”, “Tesla”, “แบตเตอรี่รถ” ขึ้นมา ทั้งที่หน้าเหล่านั้นอาจไม่มีคำว่า “รถยนต์ไฟฟ้า” อยู่เลยสักตัว — คำถามคือระบบรู้ได้ยังไงว่าคำพวกนี้ “ความหมายใกล้กัน” ทั้งที่ตัวอักษรไม่เหมือนกันเลย คำตอบคือเทคโนโลยีที่ชื่อ embedding ซึ่งเป็นรากฐานเงียบ ๆ ที่อยู่ใต้แทบทุกอย่างในโลก AI ยุคนี้ ตั้งแต่ search, RAG, ระบบแนะนำสินค้า ไปจนถึงการจัดกลุ่มเอกสารอัตโนมัติ
Embedding คือการแปลงความหมายเป็นพิกัด
หัวใจของ embedding สั้นมาก: มันคือการแปลงข้อความ (หรือรูป เสียง อะไรก็ได้) ให้กลายเป็นชุดตัวเลข ที่เรียกว่า vector — ลองนึกถึงพิกัดบนแผนที่ แต่แทนที่จะเป็นแค่ละติจูด-ลองจิจูด 2 ตัว มันคือพิกัดในปริภูมิที่มีหลายร้อยถึงหลายพันมิติ
ทำไมต้องแปลงเป็นตัวเลข? เพราะคอมพิวเตอร์ไม่เข้าใจคำว่า “แมว” แต่เข้าใจตัวเลขได้ดีมาก ถ้าเราออกแบบให้ตัวเลขชุดนี้สะท้อน “ความหมาย” ได้ คำที่ความหมายใกล้กันก็จะมีพิกัดอยู่ใกล้กันในปริภูมินั้น
หัวใจของ embedding คือ: ความหมายที่ใกล้กัน = พิกัดที่อยู่ใกล้กัน ระยะห่างในปริภูมิตัวเลข กลายเป็นตัวแทนของความเหมือนทางความหมาย
ลองนึกภาพแผนที่ความหมาย — “แมว” กับ “สุนัข” อยู่ใกล้กันเพราะเป็นสัตว์เลี้ยงเหมือนกัน ส่วน “แมว” กับ “รถบรรทุก” อยู่ไกลกันมาก และสิ่งมหัศจรรย์คือคำว่า “cat” ในภาษาอังกฤษก็จะถูกวางไว้ใกล้ ๆ “แมว” ด้วย เพราะโมเดลที่ดีเรียนรู้ว่าทั้งสองหมายถึงสิ่งเดียวกัน นี่คือเหตุผลที่ search ยุคใหม่ค้นข้ามภาษาและข้ามคำพ้องได้
จากนับคำ สู่เข้าใจความหมาย
เพื่อให้เห็นว่า embedding เก่งตรงไหน ลองย้อนดูวิธีเดิมก่อน ระบบค้นหาสมัยก่อนใช้การ “จับคู่คำ” ตรง ๆ (keyword matching) — ถ้าคุณค้น “รถยนต์ไฟฟ้า” มันก็ไปหาหน้าที่มีคำนี้เป๊ะ ๆ ปัญหาคือถ้าเอกสารเขียนว่า “EV” หรือ “ยานยนต์พลังงานสะอาด” ระบบจะมองไม่เห็นเลย เพราะตัวอักษรไม่ตรงกัน
วิธีนับคำแบบเก่า (เช่น TF-IDF) มองข้อความเป็นแค่ “ถุงคำ” (bag of words) นับว่าคำไหนโผล่กี่ครั้ง แต่ไม่เข้าใจว่าคำไหนหมายถึงอะไร มันแยกไม่ออกว่า “ธนาคาร” ในประโยค “ไปฝากเงินที่ธนาคาร” กับ “นั่งริมธนาคารแม่น้ำ” เป็นคนละความหมาย
embedding แก้ปัญหานี้ได้เพราะมันเรียนรู้จากบริบท โมเดลถูกเทรนด้วยข้อความมหาศาลจนจับ pattern ได้ว่า คำที่มักปรากฏในบริบทคล้าย ๆ กัน น่าจะมีความหมายใกล้กัน นี่คือแนวคิดที่นักภาษาศาสตร์สรุปไว้นานแล้วว่า “คุณรู้จักคำได้จากเพื่อนที่มันคบ”
เลขคณิตของความหมาย
ตัวอย่างคลาสสิกที่ทำให้คนทึ่งกับ embedding คือมันทำ “เลขคณิตกับความหมาย” ได้ ตัวอย่างที่โด่งดังคือ:
king − man + woman ≈ queen
แปลว่า ถ้าเอา vector ของ “กษัตริย์” ลบความเป็น “ผู้ชาย” ออก แล้วบวกความเป็น “ผู้หญิง” เข้าไป ผลลัพธ์จะอยู่ใกล้ vector ของ “ราชินี” มากที่สุด สิ่งนี้บอกเราว่า embedding ไม่ได้แค่จำคำ แต่จับ “ความสัมพันธ์เชิงโครงสร้าง” ของความหมายได้ เช่น แกนของเพศ แกนของกาลเวลา แกนของประเทศ-เมืองหลวง
ในทางปฏิบัติ เราไม่ค่อยทำเลขคณิตแบบนี้ตรง ๆ แต่มันเป็นหลักฐานว่าปริภูมิ embedding มี “โครงสร้าง” ที่มีความหมายซ่อนอยู่จริง ไม่ใช่ตัวเลขสุ่ม ๆ
วัดความใกล้กันยังไง: cosine similarity
พอทุกอย่างเป็น vector แล้ว คำถามต่อไปคือ “จะวัดว่าสอง vector ใกล้กันแค่ไหน” วิธีที่ใช้บ่อยที่สุดคือ cosine similarity — แทนที่จะวัดระยะทางตรง ๆ มันวัด “มุม” ระหว่าง vector สองตัว
- มุมแคบ (ชี้ไปทางเดียวกัน) = ความหมายใกล้กัน ค่าเข้าใกล้ 1
- มุมตั้งฉาก = ไม่เกี่ยวกัน ค่าราว 0
- ชี้ตรงข้าม = ความหมายตรงข้าม ค่าเข้าใกล้ -1
เหตุผลที่นิยมวัดมุมมากกว่าระยะทาง เพราะมันสนใจ “ทิศทาง” ของความหมายมากกว่า “ขนาด” ของ vector ทำให้เปรียบเทียบข้อความสั้นกับข้อความยาวได้ยุติธรรมกว่า นี่คือกลไกที่อยู่เบื้องหลังคำว่า “หา chunk ที่ใกล้ที่สุด” ในระบบ RAG — มันคือการหา vector ที่มี cosine similarity สูงสุดกับคำถามนั่นเอง
Embedding อยู่ตรงไหนในงานจริง
เมื่อเข้าใจหลักแล้ว ลองดูว่ามันถูกใช้จริงตรงไหนบ้าง:
- Semantic search — ค้นหาด้วยความหมาย ไม่ใช่คำเป๊ะ ผู้ใช้พิมพ์ “วันลาพักร้อนได้กี่วัน” ระบบเจอเอกสารที่เขียนว่า “นโยบายวันหยุดประจำปี” ได้
- RAG — หัวใจของขั้น retrieval คือการ embed คำถามแล้วหา chunk เอกสารที่ใกล้ที่สุดมาป้อนให้ LLM (อ่านเพิ่มได้ในบทความเรื่อง RAG ของเรา)
- ระบบแนะนำ (recommendation) — embed สินค้าหรือคอนเทนต์ แล้วแนะนำของที่ vector ใกล้กับสิ่งที่ผู้ใช้เคยชอบ
- จัดกลุ่มและจำแนก — จับเอกสารที่ความหมายคล้ายกันมารวมกลุ่มอัตโนมัติ (clustering) หรือคัดกรองเนื้อหา
- ตรวจจับข้อความซ้ำ/ใกล้เคียง — หาคำถามที่ถามซ้ำใน support ticket ทั้งที่พิมพ์คนละแบบ
เรื่องที่ต้องระวังในทางปฏิบัติ
embedding ทรงพลังแต่ก็มีกับดักที่เจอบ่อย เก็บไว้ในใจก่อนเอาไปใช้จริง:
- ต้องใช้โมเดลเดียวกันทั้งตอน index และตอน query — vector จากคนละโมเดลอยู่กันคนละปริภูมิ เอามาเทียบกันไม่ได้ ถ้าเปลี่ยนโมเดล embedding ต้องสร้าง vector ของข้อมูลทั้งหมดใหม่
- มิติเยอะไม่ได้แปลว่าดีกว่าเสมอ — vector มิติสูงกินพื้นที่เก็บและคำนวณช้ากว่า ต้องชั่งระหว่างคุณภาพกับต้นทุน หลายงานใช้โมเดลมิติปานกลางก็เพียงพอ
- embedding สะท้อนอคติในข้อมูลที่เทรนมา — ถ้าข้อมูลต้นทางมีอคติ vector ก็จะมีอคตินั้นติดมาด้วย ต้องระวังในงานที่อ่อนไหว
- ภาษาไทยและโดเมนเฉพาะทาง — โมเดล embedding ทั่วไปอาจเข้าใจภาษาไทยหรือศัพท์เฉพาะวงการ (เช่น กฎหมาย การแพทย์) ได้ไม่ดีเท่าภาษาอังกฤษ ควรทดสอบกับข้อมูลจริงก่อนเสมอ
- ข้อความยาวเกินไปทำความหมายเจือจาง — ถ้ายัดข้อความยาวมากเข้าไป embed ทีเดียว ใจความสำคัญจะถูกเฉลี่ยจนจาง นี่คือเหตุผลที่ RAG ต้องตัด chunk ให้พอดี
กับดักที่เจอบ่อยที่สุดคือลืมว่า embedding ตอน index กับตอน query ต้องมาจากโมเดลเดียวกัน — ผิดข้อนี้ระบบจะค้นมั่วทั้งที่โค้ดไม่ error
สรุป
embedding คือสะพานที่เปลี่ยน “ความหมาย” ของภาษาให้กลายเป็น “ตัวเลข” ที่คอมพิวเตอร์คำนวณได้ หลักการมีแค่อย่างเดียว — ความหมายใกล้กันจะถูกวางไว้ใกล้กันในปริภูมิ vector — แต่จากหลักการง่าย ๆ นี้ ต่อยอดเป็นได้ทั้ง search ที่ฉลาดขึ้น, RAG ที่ดึงข้อมูลตรงประเด็น และระบบแนะนำที่เข้าใจรสนิยมคน
สำหรับคนที่อยากเป็น AI Engineer การเข้าใจ embedding ให้ลึกพอจะรู้ว่า “ทำไมระบบค้นผิด” หรือ “ทำไมต้องเลือกโมเดลนี้” เป็นทักษะพื้นฐานที่คุ้มค่าลงทุนเรียนรู้ เพราะไม่ว่าเทรนด์ AI จะเปลี่ยนไปแค่ไหน การแปลงความหมายเป็น vector ยังคงเป็นรากฐานที่อยู่ใต้แทบทุกระบบที่เราสร้าง
