Vectorize ของ Cloudflare เก็บ Embedding ได้กี่มิติ แล้วใช้ทำ RAG ได้จริงไหม

ทีมที่เริ่มทำฟีเจอร์ค้นหาด้วยความหมาย (semantic search) หรือ RAG (Retrieval-Augmented Generation) มักเจอทางแยกแรกตั้งแต่ยังไม่เขียนโค้ดสักบรรทัด นั่นคือจะเก็บเวกเตอร์ไว้ที่ไหน ถ้าทีมใช้ Cloudflare Workers เป็น backend อยู่แล้ว คำถามที่ตามมาเร็วมากคือ Vectorize พอใช้ได้จริงไหม หรือควรไปพึ่งฐานข้อมูลเวกเตอร์เฉพาะทางอย่าง Pinecone หรือ pgvector บน Postgres แทน

คำตอบสั้น ๆ คือ Vectorize ใช้ได้จริง แต่ 'ใช้ได้' กับ 'เหมาะกับงานที่กำลังทำ' เป็นคนละคำถามกัน เพราะ Vectorize ถูกออกแบบมาให้ทำงานร่วมกับ Workers และ Workers AI เป็นหลัก จุดแข็งคือ latency ต่ำเพราะรันอยู่ในเครือข่าย edge เดียวกัน ไม่ต้องเปิด connection ข้ามไปหาฐานข้อมูลภายนอก แต่จุดที่ต้องเข้าใจก่อนคือมันไม่ใช่ vector database แบบ full-feature ที่มีทุกอย่างเหมือนโซลูชันเฉพาะทาง

บทความนี้จะพาไปดูตั้งแต่ embedding คืออะไรในบริบทของ Vectorize จริง ๆ, index กับ query ทำงานยังไง, metadata filtering ช่วยตัดขอบเขตการค้นหาได้แค่ไหน, ไปจนถึงข้อจำกัดที่มักทำให้ทีมพลาดตอนออกแบบ schema ตั้งแต่ต้น เพื่อให้ตัดสินใจได้ว่า Vectorize เหมาะกับ use case ของทีมคุณจริงหรือไม่

Vectorize คืออะไร และแก้ปัญหาอะไรให้ Workers

Vectorize คือบริการฐานข้อมูลเวกเตอร์ (vector database) ของ Cloudflare ที่ออกแบบมาให้เรียกใช้งานได้โดยตรงจาก Workers ผ่าน binding โดยไม่ต้องตั้งค่า connection string หรือจัดการ credential แยกต่างหาก หลักการทำงานคือรับข้อมูลที่เป็นเวกเตอร์ (ตัวเลขหลายมิติที่แทนความหมายของข้อความ รูปภาพ หรือข้อมูลอื่น) เข้าไปเก็บใน index แล้วเปิดให้ค้นหาด้วยการเทียบความใกล้เคียงทางคณิตศาสตร์ระหว่างเวกเตอร์

ปัญหาที่ Vectorize แก้ให้ทีมที่ใช้ Workers อยู่แล้วคือการไม่ต้องเดินทางออกนอก edge network เพื่อไปหา backend ฐานข้อมูลเวกเตอร์อีกที ถ้าทีมมี Workers เป็นตัวรับ request จากผู้ใช้ แล้วต้องยิง query ไปหาฐานข้อมูลเวกเตอร์ที่โฮสต์อยู่ภูมิภาคเดียว (เช่น us-east) ทุกคนที่อยู่ไกลจากภูมิภาคนั้นจะเจอ latency สูงขึ้นทันที Vectorize เข้ามาตัดปัญหานี้ด้วยการกระจาย index ไปตามโครงสร้าง edge เดียวกับที่ Workers รันอยู่

ในทางปฏิบัติ Vectorize มักถูกใช้คู่กับ Workers AI ซึ่งเป็นบริการรันโมเดล machine learning บน edge เช่นโมเดลสร้าง embedding หรือโมเดลสร้างข้อความตอบกลับ ทำให้ pipeline ทั้งเส้นตั้งแต่รับข้อความผู้ใช้ แปลงเป็นเวกเตอร์ ค้นหาบริบทที่เกี่ยวข้อง ไปจนถึงส่งให้โมเดลภาษาสรุปคำตอบ สามารถอยู่ในเครือข่ายเดียวกันได้ทั้งหมดโดยไม่ต้องออกไปนอก Cloudflare เลย

Embedding และจำนวนมิติที่ Vectorize รองรับ

เวกเตอร์ที่เก็บใน Vectorize ไม่ได้เกิดขึ้นเองในระบบ ต้องผ่านขั้นตอนสร้าง embedding ก่อนเสมอ ซึ่งเป็นหน้าที่ของโมเดล embedding ไม่ใช่ของ Vectorize เอง ทีมสามารถเลือกใช้โมเดล embedding จาก Workers AI เช่นตระกูล BGE หรือจะเรียก API ภายนอกอย่าง OpenAI embeddings ก็ได้ ประเด็นสำคัญคือทุกเวกเตอร์ที่ยัดเข้า index เดียวกันต้องมาจากโมเดลเดียวกันและมีจำนวนมิติเท่ากันเสมอ

จำนวนมิติ (dimension) คือขนาดของ array ตัวเลขที่โมเดล embedding แต่ละตัวคายออกมา เช่นโมเดลขนาดเล็กบางตัวให้ 384 มิติ โมเดลขนาดกลางให้ 768 มิติ ส่วนโมเดลจาก OpenAI บางรุ่นให้สูงถึง 1536 หรือ 3072 มิติ เมื่อสร้าง index ใน Vectorize ต้องกำหนดจำนวนมิติไว้ตายตัวตั้งแต่ตอนสร้าง แล้วทุกเวกเตอร์ที่ insert เข้าไปหลังจากนั้นต้องมีมิติตรงกันเป๊ะ ถ้าสลับโมเดลกลางทางโดยไม่สร้าง index ใหม่ ระบบจะปฏิเสธการ insert หรือให้ผลค้นหาที่ผิดเพี้ยนทันที

อีกจุดที่ต้องตัดสินใจตอนสร้าง index คือ distance metric ที่จะใช้วัดความใกล้เคียง ซึ่งปกติมีให้เลือกระหว่าง cosine similarity, Euclidean distance และ dot product แต่ละแบบเหมาะกับลักษณะข้อมูลต่างกัน โมเดล embedding ส่วนใหญ่ที่ใช้กันในงานข้อความจะแนะนำให้ใช้ cosine เพราะสนใจทิศทางของเวกเตอร์มากกว่าขนาด แต่ควรตรวจเอกสารของโมเดลที่เลือกใช้ก่อนเสมอ เพราะบางโมเดลออกแบบมาให้ทำงานกับ dot product โดยเฉพาะ

โครงสร้าง Index และวิธี Query แบบ Similarity Search

การทำงานกับ Vectorize แบ่งเป็นสองฝั่งหลัก ฝั่งแรกคือการ insert หรือ upsert เวกเตอร์เข้า index พร้อมกับ id ที่ไม่ซ้ำกันและ metadata ที่จะใช้กรองภายหลัง ฝั่งที่สองคือการ query โดยส่งเวกเตอร์ตัวอย่าง (เช่นเวกเตอร์ที่แปลงจากคำค้นหาของผู้ใช้) เข้าไปแล้วขอผลลัพธ์ top-k ที่ใกล้เคียงที่สุด พร้อมค่าคะแนนความคล้ายที่คำนวณตาม distance metric ที่ตั้งไว้

ตัวอย่างสมมติของ flow ที่ใช้บ่อยคือ ผู้ใช้พิมพ์คำถามในแชทบอทเอกสาร ระบบจะแปลงคำถามนั้นเป็นเวกเตอร์ผ่านโมเดล embedding ตัวเดียวกับที่ใช้ตอน index เอกสารไว้ตั้งแต่แรก แล้วส่งเวกเตอร์นั้นไป query หา top-5 ชิ้นข้อความที่ใกล้เคียงที่สุด ก่อนเอาข้อความทั้ง 5 ชิ้นไปแนบเป็นบริบทให้โมเดลภาษาสรุปคำตอบ ขั้นตอนทั้งหมดนี้ต้องทำภายในเวลาที่ผู้ใช้รอได้ ซึ่งเป็นจุดที่ latency ต่ำของ Vectorize ช่วยได้จริง

ค่าที่ query กลับมามักไม่ใช่แค่ id กับคะแนน แต่ยังรวม metadata ที่แนบไว้ตอน insert ด้วย ทำให้ไม่ต้องไปเปิดฐานข้อมูลอีกตัวเพื่อดึงรายละเอียดเพิ่ม แต่ต้องระวังว่าขนาดของ metadata ต่อเวกเตอร์มีเพดานจำกัด ถ้าพยายามยัดข้อความเต็มของเอกสารทั้งหน้าเข้าไปใน metadata แทนที่จะเก็บแค่ id แล้วไปดึงเนื้อหาเต็มจากที่อื่น มักเจอปัญหา insert ล้มเหลวหรือ index บวมเร็วเกินคาด

Metadata Filtering ใช้จำกัดขอบเขตการค้นหายังไง

งานจริงแทบไม่มีกรณีที่ต้องการค้นหาทั่วทั้ง index โดยไม่มีเงื่อนไขเลย เช่นระบบ FAQ หลายภาษาต้องกรองเฉพาะภาษาที่ผู้ใช้เลือก หรือระบบเอกสารหลายลูกค้าต้องกรองเฉพาะเอกสารของ tenant นั้น ๆ Vectorize รองรับการแนบ metadata เป็น key-value เข้ากับแต่ละเวกเตอร์ตอน insert แล้วใช้ filter ตอน query เพื่อจำกัดขอบเขตให้ค้นหาเฉพาะเวกเตอร์ที่ metadata ตรงเงื่อนไขก่อนคำนวณความคล้าย

จุดที่ทีมมักพลาดคือคิดว่า metadata ทุก field filter ได้แบบไม่มีเงื่อนไข ในความเป็นจริงต้องกำหนดว่า field ไหนเป็น indexed metadata ตั้งแต่ตอนสร้าง index field ที่ไม่ได้ประกาศไว้จะ filter ไม่ได้หรือทำงานช้ากว่าที่คาด การวางแผน metadata schema ตั้งแต่ต้น เช่นจะมี field tenant_id, language, category กี่ตัว จึงสำคัญพอ ๆ กับการเลือกโมเดล embedding

อีกแนวทางที่ช่วยลดภาระของ metadata filtering คือการแยก index ตาม tenant หรือ namespace ตั้งแต่ต้น แทนที่จะยัดทุกอย่างไว้ใน index เดียวแล้วพึ่ง filter อย่างเดียว วิธีนี้เหมาะกับระบบที่มีลูกค้าจำนวนไม่มากแต่แต่ละรายมีข้อมูลเยอะ ส่วนระบบที่มี tenant จำนวนมากแต่ข้อมูลต่อรายน้อย การใช้ metadata filter ใน index เดียวมักจัดการง่ายกว่าในเชิงปฏิบัติการ

วาง RAG Pipeline ร่วมกับ Workers AI แบบ End-to-end

การทำ RAG ให้ใช้งานได้จริงต้องมองเป็นสาย pipeline ไม่ใช่แค่การเรียก query ครั้งเดียว เริ่มจากขั้นตอนเตรียมข้อมูล (ingestion) ที่ต้องตัดเอกสารยาวออกเป็นชิ้นเล็ก ๆ ที่เรียกว่า chunk ก่อน เพราะโมเดล embedding มีขีดจำกัดความยาวข้อความที่รับได้ และ chunk ที่สั้นเกินไปจะขาดบริบท ส่วน chunk ที่ยาวเกินไปจะทำให้ embedding เบลอความหมายจนค้นหาไม่แม่น

หลังจากมี chunk ที่เหมาะสมแล้ว แต่ละ chunk จะถูกส่งเข้าโมเดล embedding เพื่อสร้างเวกเตอร์ แล้ว insert เข้า Vectorize พร้อม metadata ที่บอกว่า chunk นี้มาจากเอกสารไหน หน้าไหน หรือหมวดหมู่ใด ขั้นตอนนี้มักรันเป็น batch job แยกจาก request ของผู้ใช้ ไม่ใช่ทำแบบ real-time ทุกครั้งที่มีคนถาม เพราะการ index เอกสารใหม่ไม่จำเป็นต้องเร็วเท่าการตอบคำถาม

เมื่อถึงเวลาผู้ใช้ถามจริง flow จะกลับด้าน คือรับคำถาม แปลงเป็นเวกเตอร์ query หา chunk ที่เกี่ยวข้องจาก Vectorize แล้วประกอบ context ส่งให้โมเดลภาษาสรุปคำตอบ ขั้นตอนนี้ถ้าใช้ Workers AI ทำโมเดลภาษาด้วย ก็สามารถรันทั้งสายอยู่บน edge เดียวกันได้ ตัวอย่างสมมติเช่นระบบตอบคำถามเอกสารภายในองค์กรที่ต้องการ latency ต่ำกว่าหนึ่งวินาทีสำหรับการค้นหาส่วนเวกเตอร์ ก่อนที่จะไปเสียเวลาที่ขั้นตอนสร้างคำตอบจากโมเดลภาษาต่อ

ทีมที่กำลังตัดสินใจว่าจะฝากทั้ง pipeline ไว้กับ Cloudflare ทั้งหมดหรือผสมกับบริการอื่น ควรอ่านเรื่อง เปรียบเทียบ Vectorize กับ pgvector บน Supabase ประกอบ เพราะแต่ละทางเลือกมีจุดคุ้มค่าต่างกันตามขนาดข้อมูลและงบประมาณทีม

ข้อจำกัดเรื่อง Dimension จำนวนเวกเตอร์ และค่าใช้จ่าย

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

ทำแบบนี้แล้วพัง เพราะเข้าใจผิดเรื่อง Consistency

ปัญหาที่ทีมมือใหม่เจอบ่อยที่สุดคือ insert เวกเตอร์เข้าไปแล้ว query ทันทีในโค้ดถัดไป แต่ผลลัพธ์กลับไม่เจอเวกเตอร์ที่เพิ่ง insert สาเหตุคือ Vectorize เป็นระบบแบบกระจาย (distributed system) การเขียนข้อมูลใหม่ต้องใช้เวลาสั้น ๆ กว่าจะพร้อมให้ query เห็น ถ้าเขียนเทสหรือออกแบบ flow โดยสมมติว่าเป็น consistency แบบทันทีเหมือนฐานข้อมูลบนเครื่องเดียว โค้ดจะพังตอนขึ้น production ที่มีปริมาณข้อมูลจริง

อีกอาการที่พบบ่อยคือทีมลบ (delete) เวกเตอร์เก่าแล้ว insert เวกเตอร์ใหม่ด้วย id เดียวกันทันที คาดหวังว่าจะเห็นแค่เวอร์ชันใหม่ แต่บางครั้งกลับเจอผลลัพธ์ปนกันในช่วงเวลาสั้น ๆ ทางแก้ที่ปลอดภัยกว่าคือใช้ upsert แทนการ delete แล้ว insert แยกสองขั้นตอน เพราะ upsert ถูกออกแบบมาให้จัดการกรณีอัปเดตข้อมูลเดิมโดยเฉพาะ

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

เมื่อไรควรใช้ Vectorize และเมื่อไรควรมองที่อื่น

Vectorize เหมาะกับทีมที่ใช้ Workers เป็น backend หลักอยู่แล้ว และต้องการ latency ต่ำสำหรับงานค้นหาความหมาย เช่นแชทบอทเอกสาร ระบบแนะนำสินค้าจากคำอธิบาย หรือระบบค้นหาความหมายในแอปที่ผู้ใช้กระจายอยู่หลายภูมิภาคทั่วโลก จุดแข็งที่ชัดคือไม่ต้องดูแล infrastructure แยกต่างหาก และผูกกับ Workers AI ได้ลื่นไหลกว่าการต่อฐานข้อมูลภายนอก

ในทางกลับกัน ถ้าทีมมีฐานข้อมูล Postgres อยู่แล้วและต้องการเก็บเวกเตอร์ไว้ใกล้กับข้อมูลเชิงสัมพันธ์เดิม เช่นต้อง join กับตาราง order หรือ user โดยตรง การใช้ pgvector บน Postgres อาจสมเหตุสมผลกว่า เพราะไม่ต้องเขียนโค้ดเชื่อมสองระบบแยกกัน หรือถ้าทีมต้องการฟีเจอร์ขั้นสูงของฐานข้อมูลเวกเตอร์เฉพาะทาง เช่นการปรับ index algorithm แบบละเอียด ก็อาจต้องพิจารณาโซลูชันเฉพาะทางอื่นแทน

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

สรุป

Vectorize ไม่ใช่ฐานข้อมูลเวกเตอร์ที่ดีที่สุดในทุกสถานการณ์ แต่เป็นตัวเลือกที่สมเหตุสมผลมากสำหรับทีมที่ผูกอยู่กับ Workers และต้องการ latency ต่ำระดับ edge โดยไม่อยากดูแล infrastructure เพิ่ม จุดที่ต้องเข้าใจก่อนเริ่มใช้จริงคือเรื่องมิติของ embedding ที่ต้องคงที่ตลอด index, metadata schema ที่ควรวางแผนล่วงหน้า และพฤติกรรม consistency แบบ distributed system ที่ต่างจากฐานข้อมูลบนเครื่องเดียว

ก่อนตัดสินใจผูกทั้งระบบไว้กับ Vectorize ควรลองประเมินปริมาณข้อมูลและรูปแบบการ query ที่คาดว่าจะเกิดขึ้นจริงในหนึ่งปีข้างหน้า แล้วเทียบกับข้อจำกัดที่ตรวจสอบจากเอกสารล่าสุดของ Cloudflare อีกครั้ง เพราะเพดานหลายจุดเปลี่ยนแปลงได้เร็วตามการพัฒนาผลิตภัณฑ์

• Vectorize ผูกกับ Workers โดยตรง เหมาะกับงานที่ต้องการ latency ต่ำระดับ edge
• จำนวนมิติของ index ต้องตรงกับโมเดล embedding ตลอดชุดข้อมูล เปลี่ยนโมเดลต้องสร้าง index ใหม่
• metadata filtering ต้องวางแผน field ที่จะ index ไว้ตั้งแต่ต้น ไม่ใช่เพิ่มทีหลัง
• consistency เป็นแบบ distributed system มีดีเลย์สั้น ๆ หลัง insert ก่อนที่ query จะเห็นข้อมูลใหม่
• เหมาะกับทีมที่ใช้ Workers เป็น backend หลัก ส่วนทีมที่ผูกกับ Postgres เดิมอาจเหมาะกับ pgvector มากกว่า

คำถามที่พบบ่อย