Soilfish

23/08/2026

ใครไปงาน AI+FinTech Inclusion Conference ที่ Shanghai เดือนหนัา 9-12 September เจอกันนะครับ Soilfish.co ก็ไปกัน🚀

ใครที่มองหาบริษัทช่วยทำ software, AI, web/app, InsureTech, FinTech ที่มี ISO29110 ก็ inbox หาเราได้เลยนะ Soilfish.co 🥰

https://youtu.be/gT2XeAo29m0

The 2024 Bund Conference will continue to be based in Shanghai, est...

14/08/2026

ถ้าที่บริษัทไม่มีคนเถียงกันเมื่อไหร่ เตรียมตัวรับแรงกระแทกธุรกิจได้เลย
คำว่า "รับทราบ” อาจเป็นคำที่อันตรายที่สุดในบริษัท
เพราะมันฟังเหมือนงานกำลังเดินหน้า
ทั้งที่ความจริงเราไม่รู้เลยว่า
เขาเข้าใจหรือยัง เห็นด้วยหรือเปล่า ใครเป็นคนรับผิดชอบ และสุดท้ายงานจะเสร็จเมื่อไร
วันที่ 4 ตุลาคม 2021 Elon Musk ส่งอีเมลถึงพนักงานทุกคนที่ Tesla
Subject มีเพียงคำสั้นๆ ว่า

[“Please Note”
หาก Manager ได้รับคำสั่งโดยตรงจากผม (Elon)
คุณจะมีสิ่งที่ทำได้เพียง 3 อย่าง
1. ตอบกลับมาและอธิบายว่าทำไมสิ่งที่ ผม(Elon) พูดถึงไม่ถูกต้อง เพราะบางครั้งเขาก็ผิดได้
2. ขอคำอธิบายเพิ่มเติม หากคำสั่งนั้นไม่ชัดเจน
3. ลงมือทำตามคำสั่ง
หากไม่ทำตามสักข้อในนี้ Manager คนนั้นจะถูกขอให้ลาออกทันที
]
จบสั้นๆ 5555555
ตอนเบ้นอ่านหนังสือเกี่ยวกับ Elon Musk สิ่งหนึ่งที่เห็นซ้ำๆ ในวิธีทำงานของเขาคือ
' Elon ต้องการให้ทุกอย่างเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ '
ไม่ใช่เพราะเขาชอบความ Minimal
แนวคิดนี้มีประโยชน์กับธุรกิจที่เรากำลังจะทำกันอยู่มากๆ มาเข้าใจเรื่องนี้ผ่าน 3 เรื่องนี้กัน ภาษาซับซ้อน,พื้นที่สีเทา และ Manager
#อ่านจบปุ๊ปเก่งขึ้นปั๊ป
===============
[1] ภาษาที่ซับซ้อน ทำให้องค์กรช้าลง

ปี 2010 Elon เคยส่งอีเมลถึงพนักงาน SpaceX ทั้งบริษัท
Subject คือ “Acronyms Seriously Suck” (ตัวย่อแม่งห่วย)
Elon พบว่าคนในบริษัทเริ่มสร้างตัวย่อขึ้นมาใช้กันเองมากเกินไป
ตอนแรกตัวย่อไม่กี่คำก็ดูเหมือนไม่ใช่ปัญหา
แต่ถ้าพนักงานหนึ่งพันคนต่างคนต่างสร้างตัวย่อ สุดท้ายบริษัทจะมีพจนานุกรมอีกเล่มที่พนักงานใหม่ต้องท่องจำ
เมื่อใครไม่เข้าใจ ก็มักไม่กล้าถาม เพราะกลัวตัวเองดูโง่
สุดท้ายจึงนั่งอยู่ใน Meeting ทั้งที่ไม่รู้ว่าคนอื่นกำลังพูดเรื่องอะไร
Elon ไม่ได้ห้ามตัวย่อทุกคำ
แต่ตัวย่อไหนที่ไม่ได้ช่วยให้สื่อสารง่ายขึ้น ต้องถูกตัดทิ้ง
เขายกตัวอย่างว่า VTS-3 มีสี่พยางค์ แต่ Tripod มีเพียงสองพยางค์
ถ้าตัวย่อพูดยากกว่าคำปกติแล้วเราจะย่อมันไปทำไม?
Elon ไม่ได้พยายามทำให้ภาษาของคนในบริษัทดูฉลาด
เขาพยายามทำให้ทุกคนเข้าใจตรงกันเร็วที่สุด
เพราะภาษาที่ดีในองค์กร ไม่ใช่ภาษาที่ฟังดู Professional
แต่คือภาษาที่ฟังแล้วรู้ทันทีว่า ต้องทำอะไรต่อ

---------------
[2] ไม่มีพื้นที่สีเทาในการรับคำสั่ง

อีเมล “Please Note” สะท้อนวิธีคิดเดียวกัน

Elon ตัดทุกอย่างให้เหลือเพียง
1.คิดว่าผิด - อธิบายมาสิ
2.ไม่เข้าใจ - ก็ถาม
3.เข้าใจแล้ว -ไปลงมือทำ
ไม่มีพื้นที่สีเทา ไม่มีสถานะคลุมเครือ
ไม่มีคำตอบว่า “เดี๋ยวขอกลับไป Align กับทีมก่อนครับ”
สิ่งที่น่าสนใจที่สุดจึงไม่ใช่คำว่า “ลาออก”
แต่คือ Elon อนุญาตให้ลูกน้องบอกเขาตรงๆ ว่า
“คุณกำลังคิดผิด”
คุณไม่จำเป็นต้องเห็นด้วยกับผู้นำ
แต่ต้องรับผิดชอบต่อความไม่เห็นด้วยของตัวเอง
ถ้าคิดว่าเขาผิด อธิบายมา ถ้าไม่เข้าใจ ถามมา ถ้าไม่มีข้อโต้แย้ง ก็ลงมือทำ
สิ่งที่ไม่มีอยู่ในตัวเลือกคือ
เงียบไว้ก่อน แล้วหวังว่าเดี๋ยวเรื่องจะหายไปเอง
---------
[3] Manager ไม่ใช่มนุษย์ Forward Email
หลายองค์กรมี Manager ที่ทำหน้าที่เหมือนมนุษย์ Forward Email
ได้รับคำสั่งจากข้างบน ส่งต่อให้คนข้างล่าง แล้วถือว่าหน้าที่ตัวเองจบแล้ว
ถ้าหัวหน้าถาม ก็บอกว่ากำลัง Follow up
ถ้างานพัง ก็บอกว่าน่าจะมี Communication Gap
สุดท้ายทุกคนอยู่ใน Meeting ครบ แต่ไม่มีใครเป็นเจ้าของผลลัพธ์จริงๆ
หน้าที่ของ Manager จึงไม่ใช่แค่รับคำสั่งหรือส่งต่อข้อมูล
แต่คือเปลี่ยน Direction ให้กลายเป็น
คนรับผิดชอบ สิ่งที่ต้องส่งมอบ เวลาที่ต้องเสร็จ ปัญหาที่ต้องรายงานกลับ

เพราะการรับคำสั่ง ไม่เท่ากับการรับผิดชอบ
และงานยังไม่เริ่มเดินหน้า จนกว่าจะมีใครสักคนตอบได้ว่า
ใครจะทำอะไร และต้องเสร็จเมื่อไร
หลักการนี้ยิ่งสำคัญกับ One Person Business และธุรกิจทีมเล็ก
เพราะทีมเล็กไม่มีทรัพยากรพอจะปล่อยให้งานหนึ่งชิ้นเดินทางผ่าน Meeting ห้ารอบ

==================
#สรุปแบบลงดาบ
ธุรกิจส่วนใหญ่ไม่ได้ช้าเพราะคนในองค์กรไม่เก่ง
แต่ช้าเพราะคนไม่เข้าใจกัน ไม่มีใครกล้าถาม
และไม่มีใครเป็นเจ้าของผลลัพธ์
คำว่า “รับทราบครับ” จึงไม่มีความหมาย
ถ้าไม่รู้ว่า Step ต่อไปคืออะไร
Silence is not alignment. “Seen” is not ex*****on.
ถ้าคิดว่าผู้นำผิด จงอธิบาย ถ้าคำสั่งไม่ชัด จงถาม
ถ้าทุกอย่างชัดแล้ว จงลงมือทำ
เบ้น ชอบ Email Style ของ Elon มาก ไม่มีภาษาองค์กร ไม่ต้องมี HR มีแค่ 3 ทางให้เราเลือกแล้วก็ผลที่ตามมาของการออกนอก 3 ทางนี้
และ ไม่ว่าพวกเราจะเห็นด้วยกับวิธีนี้หรือไม่
นี่คือวิธีบริหารของคนที่สร้าง Tesla และกำลังบริหาร SpaceX
บริษัทที่เพิ่งเข้าตลาดด้วย IPO ครั้งใหญ่ที่สุดในประวัติศาสตร์
ผมหวังว่าเรื่องนี้จะช่วยสร้างวันของคุณ

25/07/2026

ลองจินตนาการว่าเรายื่นรายงานประจำปีหนา 300 หน้าให้พนักงานสองคน แล้วถามว่า

“สาเหตุหลักที่ทำให้กระแสเงินสดของบริษัทลดลงในปีนี้คืออะไร?”

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

ส่วนพนักงานคนที่สองเริ่มจากเปิดสารบัญ ดูว่าข้อมูลกระแสเงินสดอยู่บทไหน อ่านหัวข้อที่เกี่ยวข้อง ตรวจสอบตาราง และตามไปอ่านหมายเหตุประกอบงบการเงินเมื่อพบการอ้างอิง

ระบบ RAG ที่เราใช้งานกันมาหลายปี มีวิธีทำงานใกล้เคียงกับพนักงานคนแรก

แต่ PageIndex กำลังพยายามสร้างพนักงานคนที่สอง

# # RAG แบบดั้งเดิมทำงานอย่างไร

RAG หรือ Retrieval-Augmented Generation คือแนวทางที่ช่วยให้ AI ตอบคำถามจากข้อมูลหรือเอกสารขององค์กรได้ โดยไม่ต้องนำข้อมูลทั้งหมดไปฝึกโมเดลใหม่

กระบวนการทั่วไปประกอบด้วย

1. แยกข้อความออกจากเอกสาร
2. หั่นข้อความเป็นส่วนย่อยหรือ Chunk
3. แปลงแต่ละ Chunk เป็น Embedding
4. เก็บ Embedding ลงใน Vector Database
5. แปลงคำถามของผู้ใช้เป็น Embedding
6. ค้นหา Chunk ที่มีความหมายใกล้กับคำถาม
7. ส่งข้อมูลที่ค้นพบให้ LLM สร้างคำตอบ

แนวทางนี้ทำงานได้ดีในหลายกรณี โดยเฉพาะการค้นหาข้อมูลจากเอกสารจำนวนมาก

แต่ปัญหาสำคัญคือ ระบบไม่ได้เข้าใจเสมอไปว่าข้อมูลใด “เกี่ยวข้องกับคำถามจริง ๆ”

มันเพียงพยายามหาข้อความที่ “มีความหมายคล้ายกับคำถาม”

และสองสิ่งนี้ไม่ได้เหมือนกันเสมอไป

# # ความคล้ายไม่ได้แปลว่าความเกี่ยวข้อง

สมมติผู้ใช้ถามว่า

“บริษัทมีความเสี่ยงที่จะผิดนัดชำระหนี้หรือไม่?”

ระบบ Similarity Search อาจดึงย่อหน้าที่มีคำว่า “หนี้สิน” “ความเสี่ยง” และ “สภาพคล่อง” ขึ้นมา เพราะมีถ้อยคำใกล้เคียงกับคำถาม

แต่ข้อมูลที่จำเป็นต่อการตอบจริงอาจกระจายอยู่หลายส่วน เช่น

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

ข้อความเหล่านี้อาจไม่ได้ใช้ถ้อยคำคล้ายกับคำถามโดยตรง จึงมีโอกาสถูกระบบมองข้าม

นี่คือหนึ่งในปัญหาที่ PageIndex ต้องการเข้ามาแก้ไข

# # PageIndex คืออะไร

PageIndex เป็นแนวทาง RAG ที่ไม่ใช้ Vector Database เป็นแกนหลักในการค้นข้อมูล

แทนที่จะนำเอกสารไปหั่นเป็น Chunk แล้วแปลงทุกส่วนเป็น Embedding ระบบจะสร้างดัชนีแบบลำดับชั้น หรือ Hierarchical Tree Index

โครงสร้างดังกล่าวมีลักษณะคล้ายสารบัญอัจฉริยะ ประกอบด้วย

* ชื่อเอกสาร
* หัวข้อหลัก
* หัวข้อย่อย
* ช่วงหน้าของแต่ละหัวข้อ
* คำอธิบายของแต่ละส่วน
* ความสัมพันธ์ระหว่างหัวข้อแม่และหัวข้อลูก

เมื่อผู้ใช้ถามคำถาม LLM จะเริ่มจากการอ่านโครงสร้างของเอกสารก่อน

จากนั้นจึงวิเคราะห์ว่า คำตอบน่าจะอยู่ในบทใด หัวข้อใด หรือหน้าใด แล้วค่อยเปิดอ่านเฉพาะส่วนที่เกี่ยวข้อง

กระบวนการทำงานโดยคร่าว ๆ มีดังนี้

1. อ่านโครงสร้างของเอกสาร
2. วิเคราะห์ว่าหัวข้อใดน่าจะเกี่ยวข้อง
3. เปิดเนื้อหาเฉพาะช่วงหน้าที่ต้องการ
4. ตรวจสอบว่าหลักฐานเพียงพอหรือไม่
5. หากข้อมูลยังไม่ครบ ให้ย้อนกลับไปค้นหัวข้ออื่น
6. สร้างคำตอบจากข้อมูลที่พบ

พูดง่าย ๆ คือ PageIndex ไม่ได้ให้ AI ค้นหากองข้อความที่มีคำคล้ายกับคำถามเท่านั้น

แต่มันให้ AI เปิดสารบัญ เลือกบท พลิกไปยังหน้าที่น่าสนใจ และอ่านต่อเหมือนมนุษย์

# # ไม่มี Chunking จริงหรือไม่

คำว่า “ไม่มี Chunking” อาจทำให้หลายคนเข้าใจว่า PageIndex ไม่แบ่งเอกสารเลย

ความจริงคือ ระบบยังแบ่งเอกสารออกเป็นส่วนย่อย แต่ไม่ได้ตัดแบบความยาวคงที่ เช่น ทุก 500 หรือ 1,000 Token โดยไม่สนใจโครงสร้างของเนื้อหา

PageIndex พยายามแบ่งเอกสารตามโครงสร้างตามธรรมชาติ เช่น

* บท
* หัวข้อ
* หัวข้อย่อย
* ช่วงหน้า
* ตาราง
* ภาคผนวก

ดังนั้นคำอธิบายที่แม่นยำกว่าคือ

PageIndex ไม่ใช้การตัด Chunk แบบดั้งเดิมเพื่อทำ Vector Search แต่ยังคงจัดเนื้อหาออกเป็นส่วนย่อยตามโครงสร้างของเอกสาร

ความแตกต่างนี้สำคัญ เพราะการตัดเอกสารผิดตำแหน่งอาจทำให้

* ตารางถูกแยกออกจากคำอธิบาย
* หัวข้อถูกแยกออกจากเนื้อหา
* เงื่อนไขทางกฎหมายหลุดจากข้อยกเว้น
* ตัวเลขอยู่คนละส่วนกับคำอธิบาย
* การอ้างอิงข้ามบทหายไป

สำหรับเอกสารทางธุรกิจ การเงิน กฎหมาย หรือวิศวกรรม การรักษาโครงสร้างเดิมไว้จึงมีประโยชน์อย่างมาก

# # คะแนน 98.7% มาจากไหน

หนึ่งในเหตุผลที่ทำให้ PageIndex ถูกพูดถึงอย่างกว้างขวาง คือผลการทดสอบของระบบที่ชื่อว่า Mafin 2.5

Mafin 2.5 เป็นระบบตอบคำถามจากเอกสารการเงินที่สร้างขึ้นบนแนวคิดของ PageIndex และถูกนำไปทดสอบกับ FinanceBench

FinanceBench เป็นชุดคำถามที่ออกแบบมาเพื่อวัดความสามารถของ AI ในการอ่านและตอบคำถามจากรายงานทางการเงินของบริษัทจดทะเบียน

ทีมผู้พัฒนารายงานว่า Mafin 2.5 ทำคะแนนได้ 98.7% บนชุดทดสอบสาธารณะ

ถือเป็นตัวเลขที่โดดเด่นมาก โดยเฉพาะเมื่อเทียบกับระบบค้นคืนข้อมูลหลายรูปแบบที่เคยทดสอบกับโจทย์ลักษณะเดียวกัน

อย่างไรก็ตาม มีรายละเอียดสำคัญที่ควรรู้ก่อนนำตัวเลขนี้ไปพูดต่อ

ประการแรก คะแนน 98.7% เป็นผลของระบบ Mafin 2.5 ซึ่งประกอบด้วย PageIndex, การออกแบบ Prompt, โมเดลภาษา และกระบวนการเฉพาะด้านการเงิน

จึงไม่ควรสรุปว่า PageIndex เพียงอย่างเดียวจะทำคะแนน 98.7% ในทุกอุตสาหกรรม

ประการที่สอง ผลดังกล่าวมาจากโจทย์ด้านเอกสารการเงิน ซึ่งมีโครงสร้างค่อนข้างชัดเจน เช่น รายงานประจำปี งบการเงิน และเอกสารกำกับดูแล

ประการที่สาม วิธีประเมินบางส่วนใช้โมเดลภาษาเป็นผู้ช่วยตัดสินว่าคำตอบมีความหมายตรงกับคำตอบมาตรฐานหรือไม่

ดังนั้นตัวเลข 98.7% ควรถูกมองว่าเป็นผลทดสอบที่น่าสนใจมาก แต่ยังไม่ใช่หลักฐานว่า PageIndex ชนะ Vector RAG ทุกระบบในทุกสถานการณ์

# # PageIndex ฟรีจริงหรือไม่

ตัวโครงการหลักเปิดเป็นโอเพ่นซอร์สภายใต้ MIT License

ผู้ใช้สามารถนำโค้ดไปศึกษา แก้ไข พัฒนาต่อ หรือประยุกต์ใช้เชิงพาณิชย์ได้

แต่คำว่า “ฟรี” ควรแยกออกเป็นสองส่วน

ส่วนแรกคือ ตัวซอฟต์แวร์และ Source Code สามารถนำไปใช้งานได้ฟรี

ส่วนที่สองคือ ต้นทุนในการประมวลผลจริง ซึ่งยังอาจมีค่าใช้จ่าย เช่น

* ค่า LLM API
* ค่า OCR
* ค่าเครื่องเซิร์ฟเวอร์
* ค่า GPU
* ค่า Cloud Storage
* ค่าบริการระบบ Cloud ของผู้พัฒนา

การสร้าง Tree Index และการให้ AI วิเคราะห์เส้นทางการค้นยังต้องใช้โมเดลภาษา

ดังนั้น PageIndex ไม่ได้ทำให้ต้นทุนการประมวลผลหายไป เพียงแต่เปลี่ยนสถาปัตยกรรมจากการพึ่ง Vector Search ไปสู่การพึ่งโครงสร้างเอกสารและการให้เหตุผลของ LLM มากขึ้น

# # PageIndex เหมาะกับงานแบบใด

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

* รายงานประจำปี
* งบการเงิน
* สัญญาทางกฎหมาย
* กรมธรรม์ประกันภัย
* คู่มือ Compliance
* ระเบียบบริษัท
* คู่มือเครื่องจักร
* เอกสารวิศวกรรม
* เอกสารประกวดราคา
* งานวิจัย
* ตำราเรียน
* คู่มือปฏิบัติงาน
* เอกสารตรวจสอบภายใน

โจทย์เหล่านี้ไม่ได้ต้องการเพียงย่อหน้าที่มีคำคล้ายกับคำถาม

แต่ต้องเข้าใจว่า ข้อมูลอยู่ส่วนใด ต้องเปิดตารางไหน ต้องดูข้อยกเว้นจากบทใด และต้องตามการอ้างอิงไปยังภาคผนวกหรือหมายเหตุใด

แนวทางที่รักษาโครงสร้างของเอกสารไว้จึงมีโอกาสให้คำตอบที่แม่นยำและตรวจสอบย้อนกลับได้ง่ายกว่า

# # แล้ว Vector Database กำลังจะตายหรือไม่

ยังเร็วเกินไปที่จะสรุปเช่นนั้น

Vector Search ยังมีข้อได้เปรียบหลายด้าน

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

ขณะที่ PageIndex ต้องให้ LLM วิเคราะห์และตัดสินใจระหว่างการค้นหลายรอบ

สิ่งนี้อาจเพิ่ม

* เวลาในการตอบ
* ค่า Token
* ความซับซ้อนของระบบ
* ความไม่แน่นอนจากการตัดสินใจของโมเดล
* ภาระในการสร้างโครงสร้างเอกสารล่วงหน้า

ดังนั้นอนาคตของ RAG อาจไม่ได้เป็นการเลือกอย่างใดอย่างหนึ่งระหว่าง Vector Search กับ PageIndex

แต่มีแนวโน้มเป็นระบบ Hybrid มากกว่า

ตัวอย่างเช่น

ใช้ Metadata และ Vector Search เพื่อเลือกเอกสารที่เกี่ยวข้องจากเอกสารนับล้านฉบับ

จากนั้นใช้ Tree Index เพื่อเข้าไปอ่านภายในเอกสารที่ถูกเลือก

แล้วให้ Agent ตรวจสอบว่าหลักฐานครบหรือยัง ก่อนสร้างคำตอบสุดท้าย

แนวทางนี้อาจได้ทั้งความเร็วจาก Vector Search และความเข้าใจเชิงโครงสร้างจาก Reasoning-based Retrieval

# # จุดเปลี่ยนที่แท้จริงของ PageIndex

สิ่งที่น่าสนใจที่สุดของ PageIndex อาจไม่ใช่การประกาศว่า Vector Database กำลังตาย

แต่คือการตั้งคำถามกับความเชื่อเดิมว่า Retrieval จำเป็นต้องหมายถึง Similarity Search เท่านั้นหรือไม่

ในอดีต เราต้องพึ่ง Embedding และ Vector Search เพราะโมเดลภาษายังมีความสามารถจำกัดในการอ่านโครงสร้าง ใช้เครื่องมือ และวางแผนค้นข้อมูลหลายขั้นตอน

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

แทนที่จะให้ AI รับ Chunk ที่ระบบเลือกมาให้เพียงครั้งเดียว เราสามารถให้ AI ทำงานเป็นลำดับ

ดูสารบัญ
เลือกหัวข้อ
เปิดหน้า
อ่านเนื้อหา
ตามการอ้างอิง
ตรวจสอบหลักฐาน
และหยุดเมื่อมีข้อมูลเพียงพอ

นี่คือความเปลี่ยนแปลงจาก Retrieval แบบครั้งเดียว ไปสู่ Retrieval ที่มีลักษณะเป็นกระบวนการคิด

# # บทสรุป

PageIndex ยังไม่ได้พิสูจน์ว่า Vector Database จะหมดความสำคัญ

และยังไม่ควรสรุปว่า RAG แบบดั้งเดิมกำลังจะหายไปทั้งหมด

แต่โครงการนี้กำลังชี้ให้เห็นข้อจำกัดสำคัญของระบบที่พึ่งพาความคล้ายของข้อความเพียงอย่างเดียว

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

RAG อาจไม่ได้กำลังถูกเผาทิ้ง

แต่มันกำลังถูกปรุงใหม่

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

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

พิมพ์ "rag" รับ กราฟฟิกสรุปเข้าใจง่าย พร้อม link git โปรเจคนี้