ฐานข้อมูลเวกเตอร์คือ abstraction ที่ผิด

 (timescale.com)
11 คะแนน โดย GN⁺ 2024-10-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ข้อความที่ตามหลอกหลอนทีมวิศวกรรมที่พยายามสร้างแอปพลิเคชัน AI คือ: "embedding ไม่ได้ซิงก์กันอีกต่อไป"
  • การทำเวกเตอร์เสิร์ชแบบง่าย ๆ มักพัฒนาไปเป็นออร์เคสตราที่ซับซ้อนของการมอนิเตอร์ การซิงก์ และการแก้ปัญหา
  • หลังจากพูดคุยกับทีมวิศวกรรมที่สร้างระบบ AI ด้วยฐานข้อมูลเวกเตอร์ ผู้เขียนพบทั้ง abstraction ที่ผิดของฐานข้อมูลเวกเตอร์และข้อบกพร่องของวิธีใช้งานในปัจจุบัน

"กรณีใช้งานทั่วไปของการสร้างระบบ RAG"

  • ใช้ Pinecone เป็นฐานข้อมูลเวกเตอร์เพื่อเก็บและค้นหา embedding
  • เนื่องจากข้อมูลข้อความไม่เข้ากับเมตาดาต้าของ Pinecone มากนัก จึงใช้ DynamoDB จัดการ blob และข้อมูลแอปพลิเคชัน
  • ต้องใช้ OpenSearch สำหรับการค้นหาเชิงศัพท์
  • ตอนนี้การเชื่อมและซิงก์ทั้ง 3 ระบบกลายเป็นฝันร้าย

เมื่อลบเอกสารต้นทาง ต้องทำสิ่งต่อไปนี้:

  1. รัน boto3 เพื่อลบเรคอร์ดออกจาก DynamoDB
  2. อัปเดต Pinecone เพื่อยืนยันว่า embedding ถูกลบแล้ว
  3. ต้องส่งคำขอ POST เพื่ออัปเดตดัชนีค้นหาเชิงศัพท์
  • ต้องทำแบบนี้ทุกครั้งที่มีการอัปเดต เพิ่ม หรือลบเอกสารต้นทาง
  • การจัดการคอนฟิกไม่เพียงยุ่งเหยิง แต่ยังเสี่ยงอีกด้วย
  • มีทีมหนึ่งที่จ่าย $2,000 ต่อเดือนสำหรับดัชนีที่ควรถูกลบไปตั้งแต่ 4 เดือนก่อน
  • มีความเสี่ยงที่จะส่งคืนข้อมูลผิดหรือข้อมูลล้าสมัยให้ผู้ใช้

ฐานข้อมูลเวกเตอร์ถูกสร้างบน abstraction ที่ผิด

  • ฐานข้อมูลเวกเตอร์ปฏิบัติต่อ embedding เสมือนเป็นข้อมูลอิสระ ไม่ใช่ข้อมูลอนุพันธ์
  • การปฏิบัติต่อ embedding เป็นข้อมูลอิสระสร้างความซับซ้อนที่ไม่จำเป็น

วิธีที่ดีกว่า: abstraction แบบ "Vectorizer"

  • เสนอ abstraction แบบ "vectorizer" ที่ปฏิบัติต่อ embedding เหมือนดัชนีของฐานข้อมูล
  • แนวทางนี้ซิงก์ embedding กับข้อมูลต้นทางโดยอัตโนมัติ และช่วยตัดต้นทุนการดูแลรักษาออกไป
  • vectorizer ที่เทียบได้กับคำสั่ง CREATE INDEX มีหน้าตาแบบนี้:
SELECT ai.create_vectorizer(
    'public.blogs'::regclass,
    embedding => ai.embedding_openai('text-embedding-3-small', 1536),
    chunking => ai.chunking_recursive_character_text_splitter('content')
);
  • คำสั่งนี้จะสร้าง embedding สำหรับทุกแถวในตารางบล็อก และอัปเดต embedding ต่อเนื่องเมื่อข้อมูลในตารางเปลี่ยนแปลง

ปัญหาของฐานข้อมูลเวกเตอร์ (และชนิดข้อมูลเวกเตอร์)

  • ฐานข้อมูลเวกเตอร์ถูกพัฒนาขึ้นเพื่อจัดการ embedding เวกเตอร์จำนวนมากสำหรับข้อมูลข้อความ รูปภาพ และมัลติโหมด
  • ฐานข้อมูลเอนกประสงค์อย่าง PostgreSQL, MySQL, MongoDB และ Oracle ก็เพิ่มการรองรับการค้นหาเวกเตอร์เช่นกัน
  • แต่ abstraction ของความสามารถค้นหาเวกเตอร์ ไม่ว่าจะในระบบแยกเดี่ยวหรือที่เพิ่มเข้ามาในฐานข้อมูลเดิม มีข้อบกพร่องร้ายแรง
  • เมื่อ embedding ถูกแทรกเข้าไปในฐานข้อมูล ความเชื่อมโยงระหว่างข้อมูลไร้โครงสร้างที่ถูก embed กับ embedding เวกเตอร์นั้นก็ขาดออกจากกัน
  • เมื่อไม่มีความเชื่อมโยงนี้ embedding จึงถูกปฏิบัติผิด ๆ เสมือนเป็นอะตอมข้อมูลอิสระที่นักพัฒนาต้องดูแลเอง แทนที่จะเป็นข้อมูลอนุพันธ์
  • เมื่อมอง embedding ใหม่ในฐานะข้อมูลอนุพันธ์ ก็จะเห็นความย้อนแย้งของ abstraction ฐานข้อมูลเวกเตอร์ในปัจจุบันอย่างชัดเจน ว่ามันไม่เชื่อม embedding เข้ากับข้อมูลต้นทาง

ทีมพัฒนาต้องจัดการสิ่งต่อไปนี้:

  • ไปป์ไลน์ ETL (extract-load-transform) ที่ซับซ้อน

  • ฐานข้อมูลเวกเตอร์สำหรับ embedding, ฐานข้อมูลอีกตัวสำหรับเมตาดาต้าและข้อมูลแอป, และดัชนีค้นหาเชิงศัพท์

  • บริการซิงก์ข้อมูล

  • ระบบคิวสำหรับการอัปเดตและซิงก์

  • เครื่องมือมอนิเตอร์เพื่อตรวจจับ data drift และรับมือกับ rate limit ของบริการ embedding เป็นต้น

  • ระบบแจ้งเตือนเมื่อการค้นหาส่งคืนผลลัพธ์ล้าสมัย

  • การตรวจสอบความถูกต้องของทุกระบบ

  • หากต้องการอัปเกรดไปใช้โมเดล embedding ใหม่ หรือลองวิธี chunking แบบอื่น ก็ต้องเขียนโค้ดคัสตอมและประสานการเปลี่ยนแปลงข้ามบริการข้อมูลและฐานข้อมูลหลายตัว

  • งานเหล่านี้ทำให้ทีมพัฒนาต้องแบกรับภาระในการรับประกันว่า embedding จะถูกสร้างอย่างทันท่วงทีตามการเปลี่ยนแปลงของข้อมูลต้นทาง

  • ไม่เช่นนั้นก็เสี่ยงที่ embedding จะล้าสมัยอยู่บ่อยครั้ง และทำให้ผู้ใช้ได้รับประสบการณ์แอปที่แย่ลง

วิธีที่ดีกว่า: ให้ฐานข้อมูลจัดการความซับซ้อน

  • เมื่อมอง embedding เป็นข้อมูลอนุพันธ์ ก็สามารถมอบความรับผิดชอบในการสร้างและอัปเดต embedding ตามการเปลี่ยนแปลงของข้อมูลพื้นฐานให้ระบบจัดการฐานข้อมูลได้
  • การเปลี่ยนแปลงนี้ช่วยปลดภาระนักพัฒนาจากการต้องคอยซิงก์ embedding กับข้อมูลต้นทางด้วยมือ
  • ความแตกต่างนี้อาจไม่สำคัญนักสำหรับแอปง่าย ๆ ที่นำเข้าข้อมูลครั้งเดียวเพื่อใช้กับ RAG
  • แต่ในแอปจริงส่วนใหญ่ ข้อมูลมีการเปลี่ยนแปลงอย่างต่อเนื่อง
  • ลองนึกถึงแพลตฟอร์มอีคอมเมิร์ซที่ใช้การค้นหาเชิงความหมายด้วย embedding หรือแอป RAG สำหรับผู้ช่วยด้านผลิตภัณฑ์ที่ต้องคงความทันสมัยด้วยข้อมูลสินค้าล่าสุด
  • การติดตามความเปลี่ยนแปลงเหล่านี้ด้วยมือและสร้าง embedding ใหม่ ไม่เพียงใช้แรงงานมากและเกิดข้อผิดพลาดได้ง่าย แต่ยังรบกวนนักพัฒนาไม่ให้โฟกัสกับเป้าหมายธุรกิจหลัก
  • ในเมื่อระบบฐานข้อมูลจัดการให้อัตโนมัติได้ แล้วจะเสียเวลาพัฒนาไปทำไม?

Vectorizer: embedding เวกเตอร์ในฐานะดัชนี

  • abstraction ที่มีประสิทธิภาพกว่าคือการมอง embedding เวกเตอร์เป็นดัชนีพิเศษของข้อมูลที่ถูก embed แทนที่จะเป็นตารางอิสระหรือชนิดข้อมูลหนึ่ง
  • embedding เวกเตอร์ไม่ใช่ดัชนีในความหมายดั้งเดิม
  • แต่ทำหน้าที่เป็นกลไกการจัดทำดัชนีเพื่อดึงส่วนของข้อมูลที่เกี่ยวข้องที่สุดตาม embedding
  • เราอาจเรียก abstraction ใหม่ที่คล้ายดัชนีนี้ว่า "vectorizer"

ประโยชน์หลักของ abstraction แบบ vectorizer:

การซิงก์อัตโนมัติ

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

ความสัมพันธ์ข้อมูล-embedding ที่แน่นแฟ้นขึ้น

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

การจัดการข้อมูลง่ายขึ้น

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

Vectorizer คือวิวัฒนาการตามธรรมชาติของคำมั่นสัญญาหลักของ DBMS

  • แนวคิด vectorizer คือวิวัฒนาการตามธรรมชาติของความสามารถในระบบจัดการฐานข้อมูลสมัยใหม่ (DBMS)
  • ทุกวันนี้ DBMS มีความชำนาญในการจัดการการแปลงข้อมูลและการซิงก์ผ่านโครงสร้างเชิงประกาศอย่างดัชนี ทริกเกอร์ และ materialized view อยู่แล้ว
  • abstraction แบบ vectorizer เข้ากับพาราไดม์นี้ได้อย่างดี โดยมอบเครื่องมือใหม่สำหรับจัดการงานดูแล embedding เวกเตอร์ที่ยิ่งทวีความสำคัญ
  • เมื่อรวมความสามารถนี้เข้าไว้ใน DBMS โดยตรง เราก็ขยับเข้าใกล้การทำให้คำมั่นสัญญาสูงสุดของระบบฐานข้อมูลเป็นจริงมากขึ้น
  • นั่นคือการจัดการข้อมูลโดยซ่อนความซับซ้อนไว้ เพื่อให้ผู้ใช้โฟกัสกับสิ่งที่ทำได้ดีที่สุด ไม่ว่าจะเป็นการสร้างแอปพลิเคชัน วิเคราะห์ข้อมูล หรือขับเคลื่อนนวัตกรรม

การนำ vectorizer ไปใช้กับ PostgreSQL: pgai Vectorizer

  • ด้วยแรงผลักดันจากคำมั่นว่าจะลดภาระของนักพัฒนา ทีมวิศวกรรม AI ของ Timescale จึงสร้าง vectorizer สำหรับ PostgreSQL ขึ้นมา
  • มันมีชื่อว่า pgai Vectorizer และตอนนี้อยู่ในสถานะ Early Access
  • มันเป็นส่วนหนึ่งของโครงการ PGAI ที่มุ่งทำให้ PostgreSQL เหมาะกับระบบ AI มากขึ้น และทำให้การพัฒนา AI ง่ายขึ้นสำหรับนักพัฒนาที่คุ้นเคยกับ PostgreSQL
  • หากต้องการดูว่า pgai Vectorizer สร้างและอัปเดต embedding เวกเตอร์ให้ข้อมูลใน PostgreSQL อย่างอัตโนมัติได้อย่างไร โปรดดูวิดีโอเดโม

วิธีการทำงานของ pgai Vectorizer

  • กำหนดและสร้าง vectorizer ใน SQL
  • คิวรีต่อไปนี้จะสร้าง vectorizer และระบุตารางที่มันทำงานด้วย คอลัมน์ที่จะทำเวกเตอร์ไรซ์ โมเดล embedding ที่จะใช้ และรูปแบบเพิ่มเติมสำหรับข้อมูลอื่นที่ต้องรวมในข้อมูลต้นทางที่จะนำไป embed
-- สร้าง vectorizer ที่ embed ข้อมูลในตาราง blogs โดยอัตโนมัติ
SELECT ai.create_vectorizer(
   'public.blogs'::regclass
   -- ใช้โมเดล OpenAI text-embedding-3-small
 , embedding=>ai.embedding_openai('text-embedding-3-small', 1536, api_key_name=>'OPENAI_API_KEY')
   -- สร้างดัชนี StreamingDiskANN อัตโนมัติเมื่อมี 100k แถวในตาราง
 , indexing => ai.indexing_diskann(min_rows => 100000, storage_layout => 'memory_optimized'),
   -- ใช้ recursive chunking กับคอลัมน์ content
 , chunking=>ai.chunking_recursive_character_text_splitter('content')
   -- เพิ่มเมตาดาต้าจากคอลัมน์อื่นเข้าไปใน embedding เพื่อให้ค้นหาได้ดีขึ้น
 , formatting=>ai.formatting_python_template('Blog title: $title url: $url blog chunk: $chunk')
);
-- vectorizer จะอัปเดต embedding เมื่อมีการเปลี่ยนแปลงในตารางต้นทาง
-- ไม่ต้องมีการกระทำอื่นจากผู้ใช้
  • นอกจากนี้ ยังมีการกำหนดฟังก์ชัน chunking พื้นฐาน เพราะข้อความยาวจำเป็นต้องถูกแบ่งเป็นหลายชิ้นเล็กเพื่อให้พอดีกับข้อจำกัดจำนวนโทเค็นของโมเดล embedding

การติดตามการเปลี่ยนแปลงของข้อมูลต้นทาง

  • ภายใน pgai Vectorizer จะตรวจสอบการเปลี่ยนแปลงในตารางต้นทาง (insert, update, delete) และสร้างกับอัปเดต embedding เวกเตอร์แบบอะซิงโครนัส
  • pgai Vectorizer ถูกสร้างมาสำหรับการดีพลอย 2 แบบ: self-hosted และแบบ fully managed บน Timescale Cloud
  • ในการใช้งาน pgai Vectorizer แบบโฮสต์บนคลาวด์ จะใช้ฟังก์ชันคลาวด์ของแพลตฟอร์ม Timescale Cloud เพื่อสร้าง embedding
  • ส่วนเวอร์ชันโอเพนซอร์สของ pgai Vectorizer จะรัน worker ภายนอกเพื่อสร้าง embedding
  • pgai Vectorizer เก็บข้อมูลการตั้งค่าและแค็ตตาล็อก พร้อมข้อมูล internal bookkeeping สำคัญไว้ภายในฐานข้อมูล

แล้ว embedding ถูกสร้างจริง ๆ ที่ไหน?

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

การปรับแต่งกระบวนการ

  • pgai Vectorizer มีความยืดหยุ่น: คุณสามารถระบุกฎ chunking และ formatting ที่ใช้สร้าง embedding ได้
  • โดยเฉพาะอย่างยิ่ง คุณสามารถกำหนดคอลัมน์ของตารางต้นทางที่จะนำมาเวกเตอร์ไรซ์ และตั้งกฎ chunking กับ formatting เพื่อให้ข้อมูลต้นทางพอดีกับข้อจำกัดโทเค็นของ embedding และมีข้อมูลที่เกี่ยวข้องรวมอยู่ในแต่ละ embedding
  • ใน Early Access ของ pgai Vectorizer ผู้ใช้สามารถปรับแต่งการเลือกโมเดล embedding ของ OpenAI, กลยุทธ์ chunking สำหรับแบ่งข้อความเป็นชิ้นเล็ก, ตัวเลือก formatting เพื่อเติมบริบทเพิ่มเติมในแต่ละชิ้น, รวมถึงการตั้งค่า indexing แบบกำหนดเองเพื่อสร้างดัชนีอัตโนมัติและจูนประสิทธิภาพ
  • และในเร็ว ๆ นี้ มีแผนจะเพิ่มความยืดหยุ่นยิ่งขึ้น โดยให้ผู้ใช้ส่งโค้ด Python ของตนเองเพื่อปรับแต่ง chunking, embedding และ formatting ได้อย่างเต็มที่

ตัวอย่างเช่น ด้านล่างนี้คือ vectorizer ที่ตั้งค่าให้แบ่งไฟล์ต้นทาง HTML แบบ recursive และสร้าง OpenAI embedding จากข้อมูลต้นทาง คุณสามารถตั้งค่า chunking และ formatting ให้เหมาะกับข้อมูลแอปของคุณ ไม่ว่าจะเป็นโค้ด เอกสาร Markdown และอื่น ๆ

-- การตั้งค่า vectorizer ขั้นสูง
SELECT ai.create_vectorizer(
   'public.blogs'::regclass,
   destination => 'blogs_embedding_recursive',
   embedding => ai.embedding_openai('text-embedding-3-small', 1536),
   -- ใช้ recursive chunking กับ HTML content ตามการตั้งค่าที่กำหนด
   chunking => ai.chunking_recursive_character_text_splitter(
       'content',
       chunk_size => 800,
       chunk_overlap => 400,
       -- ตัวคั่นแบบรู้จัก HTML เรียงจากลำดับความสำคัญสูงสุดไปต่ำสุด
       separator => array[
           E'

', -- แบ่งที่ส่วนเอกสารหลัก
           E'

',    -- แบ่งที่ขอบเขต div
           E'

',
           E'

',      -- แบ่งที่ย่อหน้า
           E'
',      -- แบ่งที่จุดขึ้นบรรทัดใหม่
           E'
',     -- แบ่งที่รายการลิสต์
           E'. ',        -- ใช้ขอบเขตประโยคแทน
           ' '          -- ทางเลือกสุดท้าย: แบ่งที่ช่องว่าง
       ]
   ),
   formatting => ai.formatting_python_template('title: $title url: $url $chunk')
);

ความเห็นของ GN⁺

  • pgai Vectorizer ดูเหมือนเป็นเครื่องมือที่ทรงพลังและสร้างสรรค์ ซึ่งสามารถทำให้การจัดการ embedding ง่ายขึ้นอย่างมาก abstraction แบบ vectorizer ช่วยลดภาระที่นักพัฒนาต้องจัดการ embedding ด้วยมือ และรับประกันว่า embedding จะซิงก์กับข้อมูลต้นทาง
  • โดยเฉพาะเมื่อต้องนำการเปลี่ยนแปลงอย่างการอัปเกรดโมเดล embedding หรือเปลี่ยนกลยุทธ์ chunking มาใช้ มันน่าจะมีประโยชน์มาก ในฐานข้อมูลเวกเตอร์แบบเดิม การเปลี่ยนแปลงเหล่านี้อาจนำไปสู่กระบวนการซับซ้อนที่ต้องเขียนโค้ดคัสตอมและประสานหลายระบบ แต่เมื่อใช้ pgai Vectorizer ก็เพียงอัปเดตคอนฟิกของ vectorizer
  • นอกจากนี้ การจัดการ embedding ในฐานข้อมูลเอนกประสงค์อย่าง PostgreSQL ยังช่วยหลีกเลี่ยงปัญหาการต้องออร์เคสเทรตระบบเฉพาะทางหลายตัว ซึ่งอาจทำให้การพัฒนาแอปพลิเคชันง่ายขึ้นมาก
  • ประเด็นหนึ่งที่ควรพิจารณาคือ embedding จริงถูกสร้างในโปรเซส Python ภายนอก ซึ่งเป็นตัวเลือกด้านการออกแบบที่ดีเพราะไม่กระทบประสิทธิภาพฐานข้อมูล แต่ก็หมายความว่าต้องมอนิเตอร์และจัดการกระบวนการสร้าง embedding แยกต่างหาก
  • ท้ายที่สุด pgai Vectorizer แสดงถึงความก้าวหน้าที่สำคัญของวิธีจัดการ embedding สำหรับแอปพลิเคชัน AI เมื่อมีทีมใช้งานมากขึ้นและให้ฟีดแบ็กมากขึ้น ก็คาดว่าเครื่องมือทรงพลังนี้จะพัฒนาต่อไปอีก การผสานการจัดการ embedding เข้ากับเครื่องมือที่คุ้นเคยอย่าง Postgres จะช่วยให้นักพัฒนาจำนวนมากขึ้นเข้าถึงความสามารถ AI ขั้นสูงได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-30
ความเห็นจาก Hacker News

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

    • ข้อเสียใหญ่ที่สุดของการเก็บ embedding ไว้ในฐานข้อมูล Postgres คือเวิร์กโหลดต่างกันมาก ดัชนี HNSW ใช้ทรัพยากรมากและอาจทำให้เกิดปัญหาการแย่งทรัพยากรได้ หากย้ายฐานข้อมูล ปัญหาความสอดคล้องก็จะกลับมาอีก
    • มีคำถามเกี่ยวกับการทำงานร่วมกับการกรอง ว่าสามารถใช้ partial index ได้หรือไม่ และข้อจำกัดของการทำ HNSW ใน pgvector ยังมีอยู่หรือเปล่า

  • ในฐานะพนักงานของ Elastic มีการกล่าวถึงว่า Elasticsearch เพิ่งเพิ่มชนิดข้อมูลชื่อ semantic_text เข้ามา ซึ่งจะตัดข้อความเป็นชังก์โดยอัตโนมัติและคำนวณพร้อมจัดเก็บ embedding เอาไว้ อีกทั้งยังทำให้คำสั่ง query เรียบง่ายขึ้น ลด I/O และทำให้โค้ดฝั่งไคลเอนต์ง่ายขึ้น

  • มีการแนะนำเครื่องมือสำหรับ PostgreSQL ที่ตีความ vector embedding ใหม่ให้เป็นดัชนีของฐานข้อมูล ตอนนี้รองรับแค่ OpenAI แต่มีแผนจะรองรับโมเดล local และ OSS ในเร็ว ๆ นี้ และกำลังรอฟีดแบ็กกับกระแสตอบรับ

  • มีการตั้งคำถามกับการใช้ FAISS เป็นฐานข้อมูลเดี่ยว โดยมองว่านี่คล้ายกับ sqlite สำหรับ vector embedding และสามารถเก็บ metadata กับ vector ไว้ด้วยกันเพื่อรักษาความสัมพันธ์ได้

  • มีมุมมองเชิงบวกต่อการใช้ vector บน Postgres และตั้งคำถามเรื่องลำดับการกรองเมื่อใส่ทั้งการค้นหา vector และตรรกะไว้ใน SQL query ชอบ DX ของ pg_vector แต่การกรองหลังค้นหา vector อาจทำให้ช้าลงได้

  • มีการกล่าวว่าการเก็บ raw embedding ไว้ใน vector database ก็เหมือนกับการเก็บ raw n-gram ของข้อความไว้ในฐานข้อมูล การเก็บเอกสารน่าจะสมเหตุสมผลกว่า

  • มีการใช้งาน sqlite-vec และ FTS5 บน SQLite อยู่ และระบุว่ามีประโยชน์มาก

  • มีการสร้าง PostgreSQL ORM บน Node.js เพื่อให้เขียนโค้ดที่มีฟิลด์ vector ได้ ซึ่งสามารถ query ได้ทั้งข้อมูลและเนื้อหา embedding และกำหนดได้ว่าจะเก็บฟิลด์ใดของโมเดลเป็น embedding

  • มีการกล่าวว่า Materialized Views นั้นดี

  • มีการกล่าวว่าแอป AI ที่ใช้ชังก์แบบอิงจำนวนตัวอักษรยังไม่เคยก้าวพ้นขั้น PoC