OpenAI หรือ Cohere Embeddings: คะแนนห่าง 0.4 แต่ข้อความยาวต่าง 16 เท่า

หากต้องเลือกระหว่าง OpenAI text-embedding-3-large กับ Cohere embed-english-v3.0 สำหรับระบบ RAG ตัวเลขในตารางเปรียบเทียบของงานวิจัย NAACLให้คะแนน MTEB Retrieval nDCG@10 ที่ 55.4 กับ 55.0 ห่างกัน 0.4 จุด แต่ระบุเพดานอินพุต 8,192 กับ 512 โทเคน ต่างกัน 16 เท่า. ดังนั้นคะแนนที่ใกล้กันยังไม่พอสำหรับเลือกโมเดล: ความยาวเอกสาร วิธีแบ่งข้อความ และภาษาในคลังมีผลต่อดัชนีที่จะสร้างจริง

สำหรับคลังภาษาไทย text-embedding-3-large เป็นตัวเลือกเริ่มทดสอบที่ตรงโจทย์กว่า embed-english-v3.0 เพราะตารางรุ่นของ Cohereจัดรุ่นหลังไว้สำหรับภาษาอังกฤษเท่านั้น และระบุว่า embed-multilingual-v3.0 รองรับภาษาไทย. หากทีมต้องการเปรียบเทียบผู้ให้บริการสำหรับงานไทย ควรนำรุ่นหลายภาษามาเข้าชุดทดสอบเดียวกันก่อนตัดสินใจ ส่วนคู่รุ่นในงานวิจัยยังมีประโยชน์สำหรับมองข้อแลกเปลี่ยนด้านคะแนน ความยาวอินพุต และขนาดเวกเตอร์ โดยต้องรักษาขอบเขตของผลไว้ตามรุ่นที่ศึกษา

คะแนน Retrieval ที่ใกล้กันตอบคำถามใด

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

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

ตัวเลข MTEB อีกชุดหนึ่งมีขอบเขตต่างออกไป: คู่มือ embeddings ของ OpenAIแสดงผล MTEB 64.6% สำหรับ text-embedding-3-large ระบุเวกเตอร์เริ่มต้น 3,072 มิติ และอธิบายพารามิเตอร์สำหรับลดมิติ. ค่า 64.6% เป็นผลประเมิน MTEB ที่บริษัทแสดงในคู่มือ จึงนำไปลบกับค่าเฉลี่ยเฉพาะหมวด Retrieval ข้างต้นเพื่อหาส่วนต่างของสองบริษัทไม่ได้ แม้จะเป็นชื่อ benchmark เดียวกัน เมตริกและขอบเขตงานที่นำมาเฉลี่ยต้องตรงกันก่อนตัวเลขจึงจะเปรียบเทียบได้

งานวิจัยบันทึกเวกเตอร์ของ embed-english-v3.0 ที่ 1,024 มิติ เทียบกับค่าเริ่มต้น 3,072 มิติของ text-embedding-3-large ความต่างนี้เป็นคุณสมบัติของเอาต์พุต ไม่ใช่หลักฐานว่าเวกเตอร์ที่ยาวกว่าจะค้นคืนได้ดีกว่าเสมอ เมื่อใช้การลดมิติของ OpenAI ขนาดดัชนีและผลค้นคืนอาจเปลี่ยนพร้อมกัน จึงต้องระบุค่ามิติที่ใช้จริงควบคู่กับผลทดสอบทุกครั้ง

เพดานอินพุตเปลี่ยนจำนวนช่วงข้อความ

เพดานที่ยาวกว่าทำให้ text-embedding-3-large รับช่วงข้อความที่ครอบคลุมหลายย่อหน้าหรือหัวข้อย่อยได้โดยไม่ต้องตัดเร็วเท่า embed-english-v3.0 แต่การส่งเนื้อหายาวที่สุดเท่าที่รับได้ไม่จำเป็นต้องให้ผลค้นคืนดีที่สุด เอกสารที่มีหลายเรื่องในเวกเตอร์เดียวอาจทำให้สัญญาณของประโยคที่ตอบคำถามถูกเนื้อหาอื่นเจือจาง ขนาดช่วงข้อความที่เหมาะสมจึงขึ้นกับตำแหน่งของหลักฐานในเอกสาร ไม่ใช่เพดาน API เพียงอย่างเดียว

หากใช้ embed-english-v3.0 กับเอกสารยาว ทีมต้องแบ่งเนื้อหาเป็นช่วงก่อนฝัง หรือยอมให้คำขอจัดการส่วนเกินตามค่าที่ตั้งไว้ ข้อกำหนด Embed API ของ Cohereระบุว่าค่า truncate เริ่มต้นเป็น END ซึ่งตัดท้ายข้อความเมื่อเกินขนาดที่รับได้ และตั้งเป็น NONE เพื่อให้คำขอคืนข้อผิดพลาดแทนได้. สำหรับงานค้นคืนที่คำตอบอาจอยู่ท้ายเอกสาร การปล่อยให้ตัดท้ายโดยไม่ตรวจสอบทำให้เนื้อหานั้นไม่มีเวกเตอร์ในดัชนี การแบ่งเอกสารอย่างตั้งใจทำให้เห็นชัดว่าข้อความส่วนใดถูกเก็บไว้

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

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

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

ราคา API และพื้นที่ดัชนีคิดคนละส่วน

ต้นทุนการฝังข้อความเริ่มจากโทเคนที่ส่งเข้า API โดยหน้ารุ่น text-embedding-3-large ของ OpenAIแสดงราคา $0.13 ต่อหนึ่งล้านโทเคนอินพุต. ตารางในงานวิจัยข้างต้นบันทึก $0.10 ต่อหนึ่งล้านโทเคนสำหรับ Cohere รุ่นที่ศึกษา แต่เป็นอัตราที่ใช้ในช่วงศึกษานั้น ไม่ควรถือเป็นราคาที่บัญชีใช้งานปัจจุบันจะได้รับ การตั้งงบต้องใช้อัตราของรุ่น ช่องทางใช้งาน และเงื่อนไขบัญชีที่จะเรียกเก็บจริง

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

พื้นที่เวกเตอร์ใช้สูตรอีกชุดหนึ่ง: จำนวนช่วงข้อความคูณจำนวนมิติคูณจำนวนไบต์ต่อค่า สมมติว่าจัดเก็บเป็น float32 ซึ่งใช้ 4 ไบต์ต่อค่า เวกเตอร์ 3,072 มิติใช้ 12,288 ไบต์ต่อช่วง ส่วนเวกเตอร์ 1,024 มิติใช้ 4,096 ไบต์ต่อช่วง เมื่อจำนวนช่วงเท่ากัน ส่วนข้อมูลเวกเตอร์ของรุ่นแรกจึงใหญ่เป็นสามเท่า ตัวเลขนี้ยังไม่รวมโครงสร้างดัชนีสำหรับค้นหา ข้อมูลกำกับเอกสาร หรือสำเนาสำรอง

ตัวอย่างแบบมีเงื่อนไขช่วยให้เห็นขนาดงาน: หากแต่ละทางเลือกสร้าง 100,000 ช่วง และเก็บเวกเตอร์เป็น float32 โดยไม่มีการบีบอัด ข้อมูลเวกเตอร์ล้วนจะใช้ประมาณ 1.23 กิกะไบต์สำหรับ 3,072 มิติ และ 0.41 กิกะไบต์สำหรับ 1,024 มิติ ในระบบจริงสองทางเลือกอาจสร้างจำนวนช่วงไม่เท่ากัน เพราะเพดานข้อความและวิธีซ้อนทับต่างกัน จึงต้องแทนจำนวนช่วงที่วัดได้จริงในสูตรก่อนเทียบค่าเก็บข้อมูล

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

ข้อมูลภาษาไทยต้องใช้คู่ทดสอบที่ตรงงาน

การระบุว่า embed-english-v3.0 รองรับภาษาอังกฤษเท่านั้นทำให้คะแนน Retrieval ของรุ่นนั้นใช้ตัดสินคุณภาพค้นคืนภาษาไทยโดยตรงไม่ได้ หากเอกสารหรือคำถามหลักเป็นไทย คู่ที่ตรงโจทย์กว่าคือ text-embedding-3-large กับ embed-multilingual-v3.0 ภายใต้คลังและคำถามเดียวกัน การเปลี่ยนรุ่น Cohere เท่ากับเปลี่ยนตัวแบบที่กำลังประเมิน จึงต้องตรวจเพดานอินพุต ขนาดเวกเตอร์ อัตราคิดค่าบริการ และผลค้นคืนของรุ่นหลายภาษาแยกจากตัวเลขของรุ่นภาษาอังกฤษ

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

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

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

เวิร์กชีตคำนวณก่อนสร้างดัชนีใหม่

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

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

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

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

ใช้คำถามจริง 50 ข้อก่อนย้ายทั้งคลัง

ชุดนำร่อง 50 ข้อควรมาจากงานที่ผู้ใช้ต้องทำ ไม่ใช่คำถามที่แต่งให้ตรงถ้อยคำในเอกสาร ตัวอย่างการจัดกลุ่มที่ปรับตามคลังได้คือคำถามหาข้อเท็จจริงสั้น 20 ข้อ คำถามที่หลักฐานอยู่ในเอกสารยาวหรือหลายย่อหน้า 15 ข้อ คำถามที่เปลี่ยนถ้อยคำหรือผสมไทยอังกฤษ 10 ข้อ และคำถามที่คลังไม่มีคำตอบ 5 ข้อ ระบุเอกสารและช่วงข้อความที่นับเป็นหลักฐานถูกต้องของแต่ละข้อก่อนทดสอบโมเดล

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

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

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

อ่านเพิ่มเติม:

• Docker หรือ DigitalOcean: sandbox สำหรับ AI agent คิดเงินคนละจังหวะ
• LangChain หรือ LlamaIndex: งาน RAG ซับซ้อนกับงานค้นคืนเลือกคนละตัว
• RAG หรือ Fine-tuning: ข้อมูลเปลี่ยนบ่อยกับพฤติกรรมผิด ต้องแก้คนละจุด