บทความที่โพสต์กันที่นี่ โดยมากอาจอยู่ในสภาพแวดล้อมที่ค่อนข้างต่างจากมุมมองหรือประสบการณ์บางส่วนของตลาด SI ในประเทศที่ถึงขั้นมักเพิกเฉยต่อ OCP เสียด้วยซ้ำ

อย่างไรก็ตาม Linus Torvalds ก็ไม่ใช่มือใหม่อยู่ดี...

Gemini:
ใช่แล้ว การใช้ ฐานข้อมูลเวกเตอร์ (Vector Database) ใน RAG (Retrieval-Augmented Generation) มีรากฐานเชิงแนวคิดมาตั้งแต่มีการเผยแพร่งานวิจัยที่เกี่ยวข้องเป็นครั้งแรกในปี 2020
โดยพื้นฐานแล้ว RAG เป็นแนวทางที่ผสาน การค้นคืนข้อมูล (Retrieval) กับ การสร้างข้อความ (Generation) เข้าด้วยกัน และในขั้นตอนการค้นคืนนี้ เวกเตอร์เอ็มเบดดิงและฐานข้อมูลเวกเตอร์ที่ใช้เก็บและค้นหาเวกเตอร์เหล่านั้นอย่างมีประสิทธิภาพจึงมีบทบาทสำคัญอย่างยิ่ง
💡 จุดเริ่มต้นของ RAG และ Vector DB
แนวคิดที่ว่า RAG จำเป็นต้องมี Vector DB เริ่มต้นจากงานวิจัยและแนวคิดสำคัญดังต่อไปนี้

1. การกำเนิดของ RAG: งานวิจัยของ Lewis et al. (2020)

• ชื่องานวิจัย: "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (การสร้างข้อความแบบเสริมด้วยการค้นคืนข้อมูลสำหรับงานประมวลผลภาษาธรรมชาติที่ใช้ความรู้เข้มข้น)
• ประเด็นสำคัญ: งานวิจัยชิ้นนี้เป็นครั้งแรกที่มีการนำเสนอคำว่า RAG และกรอบการทำงานนี้อย่างเป็นทางการ
• บทบาทของ Retriever: โมเดล RAG ที่เสนอในงานวิจัยประกอบด้วย Retriever (ตัวค้นคืนข้อมูล) และ Generator (ตัวสร้างข้อความ) โดย Retriever จะค้นหา เอกสาร (latent documents) ที่เกี่ยวข้องกับคำค้นจากชุดข้อมูลขนาดใหญ่ เช่น Wikipedia
• การใช้ดัชนีเวกเตอร์: โมเดล RAG ยุคแรกนี้ใช้ ดัชนีเวกเตอร์ (Vector Index) กับชุดข้อมูลเพื่อค้นหาเอกสาร ทำให้ ตัวค้นคืนข้อมูลที่ผ่านการพรีเทรน (pretrained retriever) สามารถดึงเอกสารออกมาได้
• ข้อสรุป: เนื่องจากขั้นตอนสำคัญของ RAG อย่าง 'การค้นคืนข้อมูล' ทำงานโดยคำนวณความคล้ายคลึงจากการแทนค่าคำค้นและเอกสารในรูปเวกเตอร์ แนวคิดเรื่องที่เก็บเวกเตอร์อย่างมีประสิทธิภาพ เช่น Vector Store หรือ Vector Index จึงเป็นองค์ประกอบที่แฝงอยู่โดยจำเป็น

2. เวกเตอร์เอ็มเบดดิงและการค้นหาความคล้ายคลึง
   เหตุผลพื้นฐานที่ทำให้ฐานข้อมูลเวกเตอร์กลายเป็นองค์ประกอบสำคัญของ RAG มีดังนี้

• เอ็มเบดดิง (Embedding): ในระบบ RAG ทั้งความรู้ภายนอก (เอกสาร, ข้อความ) และคำค้นของผู้ใช้ (คำถาม) จะถูกแปลงเป็นการแทนค่าเชิงคณิตศาสตร์ในรูป เวกเตอร์ (Vector) ทั้งหมด เวกเตอร์เหล่านี้จะแสดงความหมายของข้อความเป็นอาร์เรย์ตัวเลขหนาแน่นในปริภูมิหลายมิติ
• การค้นหาความคล้ายคลึง (Similarity Search): การหาเวกเตอร์เอกสารที่อยู่ใกล้กับเวกเตอร์คำค้นมากที่สุดในปริภูมิเวกเตอร์ หมายถึงการหาเอกสารที่มีความเกี่ยวข้องเชิงความหมายมากที่สุดนั่นเอง
• บทบาทของ Vector DB: ฐานข้อมูลเวกเตอร์คือฐานข้อมูลที่ออกแบบมาโดยเฉพาะเพื่อเก็บเวกเตอร์ของเอกสารจำนวนมากเหล่านี้ และค้นหาเวกเตอร์ที่คล้ายกันที่สุดอย่างรวดเร็วและมีประสิทธิภาพสำหรับเวกเตอร์คำค้นที่กำหนด ดังนั้นจึงจำเป็นอย่างยิ่งต่อการเพิ่มประสิทธิภาพการค้นคืนข้อมูลของ RAG ให้สูงสุด
  สรุป: เหตุผลที่ต้องใช้ Vector DB
  หากต้องการให้ LLM เข้าถึงความรู้ล่าสุดหรือความรู้เฉพาะโดเมนที่ไม่ได้อยู่ในการฝึก ก็จำเป็นต้องค้นหาข้อมูลโดยอาศัยความคล้ายคลึงเชิงความหมาย ไม่ใช่เพียงการจับคู่คีย์เวิร์ดแบบง่าย ๆ (การค้นหาแบบดั้งเดิม) Vector DB คือเทคโนโลยีหลักที่ถูกผสานเข้ากับกรอบการทำงานของ RAG อย่างเป็นธรรมชาติเพื่อทำให้การค้นหาบนพื้นฐานของความคล้ายคลึงเชิงความหมายนี้ทำงานได้อย่างมีประสิทธิภาพ

มีแต่เรื่องไร้สาระทั้งนั้น..เรื่องโค้ดแย่หรือโค้ดดีนี่ พวกจูเนียร์ชอบพูดกัน แต่สิ่งที่สำคัญกว่าคือ มีหรือไม่มีซีเนียร์ที่ออกแบบซอฟต์แวร์ให้เหมาะกับอุตสาหกรรมนั้นได้ดี..

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

ไม่รู้เลยว่าไอเดียที่ว่า RAG ต้องมี vector DB นี่มันเริ่มมาจากไหนกันแน่...

อ่านเพลินมากครับ หวังว่าจะมีออกมาเรื่อย ๆ นะครับ 555

ก็ดูน่าจะมีประโยชน์เวลาจะทำฟีเจอร์คล้าย ๆ processor แบบใน filebeat นะครับ..
https://www.elastic.co/docs/reference/beats/filebeat/processor-script

งบประมาณมีเพียงพอจึงพลาดที่ยกเลิกค่าสมัครแล้ว แต่คนที่ไม่มา (no-show) ยังมากกว่าครึ่งคนเลยนะ ผู้ที่สมัครโดยไม่คิดอะไรแล้วไม่มาแบบนี้น่าเสียดายจริง ๆ ...

> ไม่ใช่นักพัฒนาเลยไม่รู้รายละเอียดภายใน แต่รู้สึกว่าเมื่อก่อนซอฟต์แวร์ไม่ได้ถูกสร้างหรือดำเนินงานกันแบบนี้ เหมือนเมื่อก่อนจะมี "ผู้ใหญ่" ที่ระมัดระวังและพยายามหลีกเลี่ยงปัญหามากกว่านี้

ดูเหมือนจะไม่ใช่นักพัฒนาด้วยซ้ำ..

> เมื่อคำนึงว่าข้อถกเถียงพวกนี้ทั้งหมดถูกพูดถึงมานับครั้งไม่ถ้วนมาตั้งแต่ก่อนแล้ว ก็ไม่อยากมองโลกในแง่ร้ายเกินไปนัก
การเปลี่ยนจากแอสเซมบลีไปสู่ภาษาระดับสูง, การนำ OOP มาใช้, สถาปัตยกรรมคอมโพเนนต์/COM/CORBA, การมาถึงของเว็บเบราว์เซอร์, การนำ Java มาใช้ ฯลฯ ปี 2018 ไม่ได้เป็น "จุดเริ่มต้นของความเสื่อมถอย" แต่เป็นเพียงหนึ่งในจุดข้อมูลที่ต่อเนื่องมายาวนานจากอดีต

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

คำแนะนำที่สำคัญที่สุดตรงท้ายสุดนี่สุดยอดจริง ๆ ครับ

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

ไปต่อไป Naver Cloud!

ตัวบทความเองให้ความรู้สึกแรงมากว่าเขียนแบบตั้งข้อสรุปไว้ล่วงหน้าแล้ว ปัญหาที่ความเป็นเจ้าของงานของนักพัฒนาถูกลดทอนลงนั้น ต่อให้ไม่เกี่ยวกับ LLM ก็อ่านได้ว่าเป็นเรื่องของ "ยุคช่างฝีมือ vs ยุคอุตสาหกรรม"

สุดยอดเลย

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

เพิ่งติดตั้งแล้วลองใช้เมื่อกี้ แต่การแยกอักขระย่อยยังไม่ทำงานครับ ตอนนี้กำลังใช้เวอร์ชัน Tahoe(26.0.1) อยู่

วิจารณ์มันน่ะง่าย เอาสิ่งที่แตกต่างจริง ๆ มาแล้วพิสูจน์มันให้ได้สิ

ได้ลองแปลบทความฉบับเต็มแล้ว
https://blogbyash.com/translation/…

กำลังจะกลายเป็น Nx ไหม