Postgres รับมือไปป์ไลน์ RAG ของคุณได้หรือไม่

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

• RAG (‘การสร้างคำตอบโดยเสริมข้อมูลที่ค้นคืนมา’) กลายเป็นรูปแบบที่ใช้กันแพร่หลายมาก โดยคุณดูแลฐานความรู้ (เอกสาร วิกิ นโยบาย บทถอดเสียง ฯลฯ) ใช้การค้นหาเชิงความหมายกับคำถามของผู้ใช้เพื่อดึงส่วนเนื้อหาที่เกี่ยวข้องที่สุดด้วย embedding แล้วป้อนส่วนเหล่านั้นพร้อมคำถามให้ LLM วิธีนี้ช่วยจำกัดบริบทของโมเดล และหากทำอย่างถูกต้องก็จะช่วยเพิ่มคุณภาพของคำตอบและลดการสร้างข้อมูลเท็จ

• pgai คือส่วนขยาย Postgres แบบโอเพนซอร์ส (พร้อมเครื่องมือที่ใช้ร่วมกัน) ซึ่งช่วยให้คุณสร้างเวิร์กโฟลว์ “การค้นคืนข้อมูลด้วย AI” บน PostgreSQL ฐานข้อมูลโอเพนซอร์สที่ได้รับความไว้วางใจ

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

• ความเห็นเบื้องต้นคือ pgai มีแนวโน้มที่ดี แต่เมื่อไปป์ไลน์ RAG ของคุณเริ่มซับซ้อนขึ้นแม้เพียงเล็กน้อย (โดยเฉพาะแนวทางการแบ่งส่วน) เครื่องมือนี้ก็ไม่เหมาะแล้ว อย่างไรก็ตาม เราจะติดตามโครงการนี้อย่างใกล้ชิด

การสร้าง RAG ทำได้หลายวิธี หากต้องการอ่านรายละเอียดเพิ่มเติมเกี่ยวกับแนวทาง RAG แบบต่างๆ โปรดอ่าน ตัวอย่างการใช้งานจริงของโซลูชัน RAG ที่ปรับแต่งเฉพาะ เมื่อให้ความสำคัญกับคุณภาพ จะพบว่าตัวเลือกในการออกแบบนั้นลึกซึ้งกว่าที่คิด ส่วนแนวทาง “เริ่มต้น” ที่ใช้กันทั่วไปมักเป็นดังนี้:

1. รวบรวมเอกสารจำนวนหนึ่ง

2. แบ่งเอกสารออกเป็นส่วนๆ ขั้นตอนนี้ทำได้หลายวิธี (เช่น แบ่งตามย่อหน้าหรือกลุ่มความหมาย)

3. แปลงแต่ละส่วนเป็น embedding

4. จัดเก็บ embedding ในฐานข้อมูลเวกเตอร์ (Pinecone, Milvus ฯลฯ) หรือใน Postgres โดยใช้ pgvector

5. เมื่อมีคำถาม ให้ค้นหาส่วนเนื้อหาที่ใกล้เคียงที่สุด `แล้วส่งให้ LLM (และเช่นเคย... ขั้นตอนนี้ก็ทำได้หลายวิธีเช่นกัน)

ในสแต็กจำนวนมาก ขั้นตอน (1)–(3) เกิดขึ้นนอกฐานข้อมูล ภายในโค้ดแอปพลิเคชันหรือไปป์ไลน์ข้อมูล ส่วนฐานข้อมูลจะใช้เป็นหลักเพื่อ:

• จัดเก็บ embedding

• ค้นหา embedding

pgai คือส่วนขยาย Postgres แบบโอเพนซอร์สที่พัฒนาโดย Timescale ซึ่งพยายามทำให้เส้นแบ่งดังกล่าวเลือนรางลง

แทนที่จะให้แอปของคุณจัดการ embedding ด้วยตนเอง pgai เปลี่ยน embedding ให้เป็นฟีเจอร์ของฐานข้อมูล:

• คุณกำหนดตารางหรือเอกสารที่ต้องการสร้าง embedding

• คุณระบุโมเดล embedding และกลยุทธ์การแบ่งส่วน

• pgai จัดการส่วนที่เหลือ รวมถึงการอัปเดต embedding ให้ทันกับการเปลี่ยนแปลงของข้อมูลต้นทาง

แนวคิดนี้น่าสนใจ:

• มีโค้ดเชื่อมระบบที่เขียนขึ้นเฉพาะและต้องบำรุงรักษาน้อยลง

• การรักษา embedding ให้ “สดใหม่” ตามการเปลี่ยนแปลงของเอกสารต้นทางน่าจะทำได้ง่ายขึ้น

• Postgres/pgai จัดการการลองใหม่ การจำกัดอัตรา งานที่ล้มเหลว และอื่นๆ ให้คุณ

หมายเหตุสำหรับผู้อ่าน: pgai รวม pgvector (ส่วนขยาย Postgres สำหรับ RAG ที่ได้รับความนิยมมากอีกตัวหนึ่ง) มาให้ในตัว pgvector เพิ่มความสามารถในการจัดเก็บเวกเตอร์และค้นหาความคล้ายคลึงให้ Postgres ส่วน pgai ต่อยอดจากความสามารถดังกล่าวเพื่อทำให้ขั้นตอนในไปป์ไลน์ RAG เป็นอัตโนมัติ เช่น การแบ่งส่วน การสร้าง embedding และการอัปเดต embedding ให้เป็นปัจจุบัน

1) เริ่มใช้งานได้ง่าย

การตั้งค่าตามเส้นทางมาตรฐานค่อนข้างง่าย:

• ดึง Docker image ของ Timescale (ฐานข้อมูล + worker)

• ระบุ API key ของผู้ให้บริการ embedding

• เรียกใช้ SQL เพียงเล็กน้อยเพื่อประกาศ vectoriser (กล่าวโดยสรุปคือ จะสร้าง embedding จากอะไร แบ่งส่วนอย่างไร และใช้โมเดลใด)

จากนั้น pgai จะจัดให้ worker ของ vectoriser ทำงานเป็นโปรเซสแยกและสร้าง embedding แบบอะซิงโครนัส (เช่น ทุก 5 นาที หรือตามรอบเวลาที่คุณต้องการ)

2) การทำไปป์ไลน์ทั้งหมดให้ “อยู่ใกล้” ฐานข้อมูลนั้นสะดวกดี

pgai นำเข้าเนื้อหาจากตารางได้ และยังโหลดเอกสารจากแหล่งอย่าง S3 ก่อนแยกวิเคราะห์ แบ่งส่วน และสร้าง embedding ได้ด้วย นอกจากนี้ยังรองรับเอกสารข้อความหลากหลายรูปแบบ เช่น PDF และ Markdown

1) คุณสูญเสียการควบคุมไปมาก (และบางครั้ง RAG ก็จำเป็นต้องควบคุมอย่างละเอียด)

ระบบ RAG ที่มีประสิทธิภาพสูง (เมื่อวัดจากคุณภาพคำตอบ) มักต้องใช้ไปป์ไลน์ที่ปรับแต่งเฉพาะ เช่น:

• กฎการแบ่งส่วนแบบกำหนดเอง (ตามหัวข้อ หน้า ช่วงผลัดกันพูด ฯลฯ)

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

• กลยุทธ์ embedding ที่แตกต่างกันสำหรับเอกสารแต่ละประเภท

pgai มีความยืดหยุ่นในด้านข้างต้นน้อยกว่า

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

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

2) เน้นข้อความเป็นหลัก ไม่ใช่หลายสื่อ

โจทย์ RAG ที่น่าสนใจจำนวนมากไม่ได้จำกัดอยู่แค่ข้อความอีกต่อไป:

• PDF ที่มีแผนภาพ

• ภาพหน้าจอ / รูปภาพ

• ไฟล์บันทึกเสียง

• คลิปวิดีโอ

แม้คุณจะ “สกัดข้อความ” จากแหล่งเหล่านี้ได้ แต่ก็ไม่เหมือนกับไปป์ไลน์ embedding แบบหลายสื่อที่แท้จริง

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

3) หากคุณต้องการเพียง embedding ก็อาจไม่จำเป็นต้องใช้ pgai

หากไปป์ไลน์การนำเข้าของคุณปรับแต่งเฉพาะอยู่แล้ว (หรือจำเป็นต้องเป็นเช่นนั้น) การ “สร้าง embedding จากส่วนข้อความ” ก็ไม่ใช่ส่วนที่ยากที่สุดของ RAG ในกรณีดังกล่าว pgai กำลังแก้ปัญหาในส่วนที่ง่ายที่สุด

นอกจากนี้ หากฐานความรู้ของคุณไม่ค่อยได้รับการอัปเดต การซิงค์ embedding อัตโนมัติก็มีประโยชน์น้อยลง

วิธีหนึ่งที่เหมาะอย่างยิ่งในการใช้ pgai คือการติดตั้งอินเทอร์เฟซ text-to-SQL ครอบฐานข้อมูลของคุณ ทำได้ค่อนข้างง่ายด้วยโมดูล semantic_catalog ที่ pgai มีให้ เพียงตั้งค่าดังนี้:

1OPENAI_API_KEY="your-OpenAPI-key-goes-here"2TARGET_DB="postgres://user:password@host:port/database"3CATALOG_DB="postgres://user:password@host:port/database"

จากนั้นให้ semantic catalog รวบรวมพจนานุกรมข้อมูลของคุณด้วย pgai semantic-catalog create คำสั่งนี้จะสร้างบริบทจากแหล่งจัดเก็บข้อมูลของคุณ ซึ่งมีหน้าตาประมาณนี้:

1---2schema: postgres_air3name: aircraft4type: table5description: Lists aircraft models with performance characteristics and unique codes.6columns:7- name: model8  description: Commercial name of the aircraft model.9- name: range10  description: Maximum flight range in kilometers.11- name: class12  description: Airframe class category or configuration indicator.13- name: velocity14  description: Cruising speed of the aircraft.15- name: code16  description: Three-character aircraft code serving as the primary key.17...

ขณะนี้ pgai สามารถใช้บริบทดังกล่าวได้หลายวิธี:

ผ่านการค้นหาเชิงความหมาย:

คำสั่งค้นหานี้จะแสดงตาราง ฟังก์ชัน และออบเจ็กต์อื่นๆ ที่อาจเกี่ยวข้องกับคำถามภาษาธรรมชาติของคุณ:

1pgai semantic-catalog search -p "Your natural language question goes here!"

รับบริบทดิบ:

คำสั่งนี้จะแสดงบริบท YAML ดิบที่เกี่ยวข้องกับคำถามภาษาธรรมชาติของคุณ:

1pgai semantic-catalog search -p "Your natural language question goes here!" --render

สร้าง SQL:

หรือจะสร้าง SQL ดิบที่จำเป็นสำหรับตอบคำถามของคุณโดยตรงก็ได้ บริบทจากขั้นตอนก่อนหน้าจะถูกส่งให้ LLM เพื่อสร้างคำตอบ:

1pgai semantic-catalog generate-sql -p "Your natural language question goes here!"

หากคุณกำลังสร้างระบบ RAG ที่ค่อนข้างเรียบง่าย pgai ก็น่าลองหากคุณต้องการ:

• ใช้ Postgres เป็นแหล่งข้อมูลหลักที่เชื่อถือได้

• ใช้โค้ดเชื่อมระบบให้น้อยที่สุด

• ให้ embedding ซิงค์โดยอัตโนมัติอยู่เสมอ

• นำ text-to-SQL มาใช้กับฐานข้อมูลได้อย่างรวดเร็ว

• ทดลองใช้เครื่องมือ RAG และส่วนขยาย Postgres ใหม่ๆ

คุณอาจควรรอให้ pgai พัฒนาไปอีกสักระยะ หากไปป์ไลน์ RAG ของคุณต้องการสิ่งต่อไปนี้:

• ตรรกะการนำเข้าหรือแบ่งส่วนที่ปรับแต่งอย่างมาก

• เอกสารหลายประเภทที่ต้องใช้วิธีแยกวิเคราะห์ต่างกัน

• embedding แบบหลายสื่อ

สุดท้ายนี้ แม้จะเห็นได้ชัดว่า pgvector ได้รับการนำไปใช้อย่างแพร่หลาย แต่ยังไม่แน่ว่า pgai จะได้รับความสนใจและการสนับสนุนในระดับเดียวกันหรือไม่ (แม้ต้องคำนึงด้วยว่าเปิดตัวมาเพียงราว 18 เดือน)

pgai เป็นแนวทาง RAG ที่น่าสนใจ เพราะให้ฐานข้อมูลรับหน้าที่ปฏิบัติการประจำมากขึ้น จึงช่วยให้โค้ดแอปพลิเคชันของคุณเรียบง่ายขึ้น

ขณะนี้ pgai:

• ใช้งานได้จริงและสะดวกอย่างแท้จริงสำหรับระบบ RAG แบบเรียบง่าย

• ยังยืดหยุ่นไม่พอสำหรับไปป์ไลน์ที่ปรับแต่งเฉพาะมากขึ้น (โดยเฉพาะแบบหลายสื่อ)

pgai มีแนวโน้มที่ดีและควรค่าแก่การติดตามอย่างยิ่งว่าจะพัฒนาต่อไปอย่างไร