ทำความเข้าใจอัลกอริทึมค้นหาข้อความแบบเต็ม BM25

 (emschwartz.me)
1 คะแนน โดย GN⁺ 2024-11-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • BM25 ยังถูกใช้อย่างแพร่หลายในงานค้นหาข้อความแบบเต็มที่ต้องการการจับคู่คีย์เวิร์ดอย่างแม่นยำ และเป็นหนึ่งในแกนหลักของ hybrid search ที่ช่วยเสริมการค้นหาด้วย vector similarity
  • เพื่อจัดอันดับเอกสารโดยไม่ต้องคำนวณความน่าจะเป็นโดยตรง BM25 จะบวกน้ำหนักของแต่ละคำในคิวรี แล้วนำเอกสารที่ดูมีความเกี่ยวข้องสูงขึ้นมาไว้ด้านหน้า
  • คะแนนประกอบด้วย IDF, ความถี่ของคำในเอกสาร และการ normalize ตามความยาวเอกสาร โดยคำที่พบได้น้อยจะมีผลมากกว่า ส่วนการปรากฏซ้ำจะให้รางวัลเพิ่มขึ้นน้อยลงเรื่อย ๆ
  • k1 ใช้ควบคุมความเร็วในการลดผลตอบแทนของการปรากฏซ้ำ ส่วน b ใช้ควบคุมความแรงของการ normalize ตามความยาวเอกสาร โดยทั่วไปมักใช้ k1=1.2~2, b=0.75
  • คะแนน BM25 ไม่ใช่ความน่าจะเป็นของความเกี่ยวข้องจริง จึงใช้เป็นค่ามาตรฐานสำหรับเปรียบเทียบทั่วไปได้ยาก และจะมีความหมายเมื่อเปรียบเทียบภายใน คอลเลกชันเอกสารเดียวกัน

ปัญหาการค้นหาที่ BM25 พยายามแก้

  • BM25 หรือ Best Match 25 เป็นอัลกอริทึมที่ใช้กันอย่างแพร่หลายในงานค้นหาข้อความแบบเต็ม
    • ถูกใช้เป็นค่าเริ่มต้นใน Lucene/Elasticsearch และ SQLite เป็นต้น
    • ช่วงหลัง hybrid search ซึ่งผสานการค้นหาข้อความแบบเต็มกับการค้นหาด้วย vector similarity กลายเป็นเรื่องพบได้ทั่วไป
  • ในฟีดคอนเทนต์แบบปรับตามบุคคล การใช้เฉพาะการค้นหาด้วย vector similarity อาจยังจัดการคีย์เวิร์ดที่ต้องการความแม่นยำได้ไม่พอ
    • หากความสนใจคือ Solid.js การใช้เฉพาะการค้นหาด้วย vector similarity อาจทำให้คอนเทนต์เกี่ยวกับ React ปรากฏมากกว่า Solid
  • คำถามหลักคือ จะสามารถเปรียบเทียบคะแนน BM25 ของเอกสารหนึ่งข้ามหลายคิวรี เพื่อ判断ว่าเอกสารนั้นตรงกับคิวรีใดมากที่สุดได้หรือไม่

หลักการจัดอันดับตามความน่าจะเป็นและแนวทางของ BM25

  • เป้าหมายของการค้นหาข้อความแบบเต็มคือการหา เอกสารที่เกี่ยวข้องมากที่สุด จากชุดเอกสารที่เป็นไปได้ โดยอิงกับคิวรี
  • เนื่องจากไม่สามารถรู้ความเกี่ยวข้องจริงได้อย่างแน่ชัด การค้นหาจึงพยายามเรียงลำดับตาม ความน่าจะเป็น ที่เอกสารจะเกี่ยวข้องกับคิวรี
    • แนวคิดนี้เรียกว่า Probability Ranking Principle
  • การค้นหาแบบอิงคำศัพท์อย่าง BM25 ใช้เพียงคิวรีและคุณลักษณะของเอกสารภายในคอลเลกชันเอกสารเท่านั้น
    • การค้นหาด้วย vector similarity สามารถใช้โมเดล embedding ที่ฝึกจากคลังข้อความภายนอก เพื่อแทนความหมายของคิวรีและเอกสารได้

องค์ประกอบของคะแนน BM25

  • BM25 คำนวณคะแนนโดยผสมผสานสัญญาณหลายอย่างจากคิวรีและคอลเลกชันเอกสาร

  • คำในคิวรี

    • หากคิวรีค้นหาประกอบด้วยหลายคำ จะคำนวณคะแนนของแต่ละคำแล้วนำมาบวกกัน

  • ความถี่เอกสารผกผัน (IDF)

    • แสดงว่าคำค้นหาหนึ่ง ๆ พบได้น้อยเพียงใดในคอลเลกชันเอกสารทั้งหมด
    • คำทั่วไปอย่าง the, and ถูกมองว่ามีปริมาณข้อมูลต่ำ และเพิ่มความสำคัญให้คำที่พบได้น้อย

  • ความถี่ของคำในเอกสาร

    • สะท้อนว่าคำค้นหาปรากฏในเอกสารเฉพาะหนึ่ง ๆ กี่ครั้ง
    • มองว่าหากคำเดียวกันปรากฏซ้ำมากขึ้น โอกาสเกี่ยวข้องก็สูงขึ้น แต่ BM25 จะใช้ ผลตอบแทนที่ลดลง กับการปรากฏซ้ำ

  • ความยาวเอกสาร

    • เอกสารยาวอาจมีคำค้นหาปรากฏมากกว่าเพียงเพราะยาวกว่า
    • BM25 เปรียบเทียบความยาวเอกสารกับความยาวเอกสารเฉลี่ย เพื่อ normalize ไม่ให้เอกสารยาวได้คะแนนสูงอย่างไม่เป็นธรรม

ส่วนต่าง ๆ ของสูตร BM25

  • คะแนนรวมของ BM25 สำหรับเอกสาร D และคิวรี Q เป็นการบวกคะแนนของแต่ละคำในคิวรี q_i
    • D: เอกสารเป้าหมาย
    • Q: คิวรีทั้งหมด
    • n: จำนวนคำในคิวรี
    • q_i: คำแต่ละคำในคิวรี

  • IDF: ให้ค่าน้ำหนักสูงขึ้นกับคำที่พบได้น้อยในคอลเลกชัน

    • ส่วน IDF คำนวณว่าคำในคิวรีพบได้น้อยเพียงใดในคอลเลกชันเอกสารทั้งหมด
    • N: จำนวนเอกสารทั้งหมดในคอลเลกชัน
    • n(q_i): จำนวนเอกสารที่มีคำในคิวรี
    • N - n(q_i): จำนวนเอกสารที่ไม่มีคำในคิวรี
    • คำทั่วไปปรากฏในเอกสารจำนวนมาก จึงมีผลต่อคะแนนน้อยลง
    • คำที่พบได้น้อยปรากฏในเอกสารเพียงจำนวนน้อย จึงถูกสะท้อนในคะแนนมากกว่า
    • ค่า 0.5 และ 1 ในสูตรมีบทบาทในการลดความผันผวนของผลลัพธ์เมื่อคำพบได้น้อยมากหรือพบได้บ่อยมาก

  • ความถี่ของคำ: สะท้อนการซ้ำ แต่ไม่ให้รางวัลอย่างไม่จำกัด

    • ความถี่ของคำในเอกสารสะท้อนว่าคำในคิวรีหนึ่ง ๆ ปรากฏในเอกสารเฉพาะหนึ่งบ่อยเพียงใด
    • f(q_i, D): ความถี่ที่คำในคิวรี q_i ปรากฏในเอกสาร D
    • k1: พารามิเตอร์สำหรับปรับจูน ซึ่งโดยทั่วไปตั้งไว้ระหว่าง 1.2 ถึง 2
    • BM25 สะท้อนการซ้ำของคำลงในคะแนน แต่ยิ่งซ้ำมาก การเพิ่มขึ้นของคะแนนเพิ่มเติมก็ยิ่งลดลง
    • k1 ควบคุมว่ารางวัลจากการซ้ำของคำจะลดลงเร็วเพียงใด

  • การ normalize ตามความยาวเอกสาร: ปรับความได้เปรียบของเอกสารยาว

    • การ normalize ตามความยาวเอกสารเปรียบเทียบความยาวของเอกสารเป้าหมายกับความยาวเฉลี่ยของเอกสารในคอลเลกชัน
    • |D|: ความยาวของเอกสารเป้าหมาย
    • avgdl: ความยาวเอกสารเฉลี่ยของคอลเลกชัน
    • b: พารามิเตอร์สำหรับปรับจูนที่ควบคุมความแรงของการ normalize ตามความยาวเอกสาร
    • เอกสารที่ยาวกว่าค่าเฉลี่ยมีโอกาสที่คำค้นหาจะปรากฏบ่อยกว่า จึงถูกลงโทษในตัวส่วนของสูตรสุดท้าย
    • หาก b=0 การ normalize ตามความยาวเอกสารจะถูกปิด และหาก b=1 จะถูกใช้เต็มที่
    • โดยทั่วไป b ตั้งไว้ที่ 0.75

แนวคิดหลักของ BM25

  • BM25 อิงกับ Probability Ranking Principle แต่แทบเป็นไปไม่ได้ที่จะคำนวณ ความน่าจะเป็นจริง ของความเกี่ยวข้องของเอกสาร
  • สิ่งสำคัญในการค้นหาคือ ลำดับ ของเอกสารมากกว่าค่าความน่าจะเป็นที่แม่นยำ ดังนั้นจึงทำให้การคำนวณใช้งานได้จริงด้วยการตัดพจน์ที่ไม่ส่งผลต่อลำดับออกจากสูตร
  • ด้วยเหตุนี้ BM25 จึงคำนวณน้ำหนัก ไม่ใช่ความน่าจะเป็นโดยตรง
  • Robertson/Sparck Jones Weight เป็นวิธีประมาณความน่าจะเป็นโดยใช้จำนวนเอกสารที่เกี่ยวข้องและจำนวนเอกสารที่มีคำในคิวรี
    • r: จำนวนเอกสารที่เกี่ยวข้องซึ่งมีคำในคิวรี
    • N: จำนวนเอกสารทั้งหมดในคอลเลกชัน
    • R: จำนวนเอกสารที่เกี่ยวข้องในคอลเลกชัน
    • n: จำนวนเอกสารที่มีคำในคิวรี
  • ข้อจำกัดใหญ่ของวิธีนี้คือ ต้องรู้ก่อนว่าเอกสารใดเกี่ยวข้อง

สมมติฐานว่า “เอกสารส่วนใหญ่ไม่เกี่ยวข้อง”

  • ผู้พัฒนา BM25 ตั้งสมมติฐานว่า สำหรับคิวรีใด ๆ เอกสารส่วนใหญ่ไม่เกี่ยวข้อง
  • หากมองว่าจำนวนเอกสารที่เกี่ยวข้องน้อยจนละเลยได้ ก็สามารถตั้ง R = r = 0 ได้
  • เมื่อนำค่านี้ไปแทนในสูตร Robertson/Sparck Jones Weight จะได้รูปแบบที่แทบเหมือนกับพจน์ IDF ที่ใช้ใน BM25
  • เพราะยังคงพื้นฐานเชิงทฤษฎีเดียวกันไว้ได้โดยไม่ต้องขอข้อมูลความเกี่ยวข้องล่วงหน้า BM25 จึงใช้งานได้จริงกว่ามาก
  • Victor Lavrenko เรียกสิ่งนี้ว่า "very impressive leap of faith"

ขอบเขตของการเปรียบเทียบคะแนน BM25

  • โดยทั่วไปคะแนน BM25 เปรียบเทียบโดยตรงได้ยาก
    • ไม่ได้สร้างคะแนนความน่าจะเป็นระหว่าง 0 ถึง 1
    • ไม่ใช่อัลกอริทึมที่พยายามประมาณความน่าจะเป็นจริงว่าเอกสารเกี่ยวข้องหรือไม่
    • มุ่งเน้นการประมาณลำดับความเป็นไปได้ของความเกี่ยวข้องต่อคิวรีภายในคอลเลกชันเฉพาะ
  • คะแนน BM25 ที่สูงกว่าสื่อว่าเอกสารมีแนวโน้มเกี่ยวข้องมากกว่า แต่ไม่ใช่ความน่าจะเป็นของความเกี่ยวข้องจริง
  • สำหรับเอกสารเดียวกันภายในคอลเลกชันเอกสารเดียวกัน สามารถเปรียบเทียบคะแนน BM25 ของหลายคิวรีได้
    • เนื่องจาก BM25 บวกคะแนนของแต่ละคำในคิวรี จึงอาจถือได้ว่าในเชิงความหมายไม่มีความแตกต่างระหว่างการเปรียบเทียบคะแนนของคำในคิวรีสองคำกับการเปรียบเทียบคะแนนของคิวรีเต็มสองชุด
  • ข้อจำกัดสำคัญคือ เอกสารเดียวกัน คอลเลกชันเดียวกัน
    • BM25 ใช้ IDF และความยาวเอกสารเฉลี่ยภายในคอลเลกชัน
    • หากคอลเลกชันเปลี่ยน คะแนนก็อาจเปลี่ยนได้ จึงไม่รับประกันการเปรียบเทียบคะแนนข้ามเวลา
  • ในฟีดคอนเทนต์แบบปรับตามบุคคล สามารถใช้โดยรันการค้นหาข้อความแบบเต็มสำหรับความสนใจแต่ละอย่างของผู้ใช้ แล้วเปรียบเทียบคะแนน BM25 เพื่อ判断ว่าคอนเทนต์ใดตรงกับความสนใจใดมากกว่า

อ่านเพิ่มเติม

  • หากต้องการเจาะลึกทฤษฎีและประวัติของ BM25 สามารถดูงานนำเสนอปี 2016 ของ Britta Weber วิศวกร Elastic เรื่อง Improved Text Scoring with BM25
  • The Probabilistic Relevance Framework: BM25 and Beyond โดย Stephen Robertson และ Hugo Zaragoza กล่าวถึงกรอบความเกี่ยวข้องเชิงความน่าจะเป็นของ BM25
  • การเปรียบเทียบ BM25 กับอัลกอริทึมค้นหาข้อความแบบเต็มอื่น ๆ ดูได้ที่ Comparing full text search algorithms: BM25, TF-IDF, and Postgres

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

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

 
GN⁺ 2024-11-21
ความคิดเห็นจาก Hacker News

  • ปกติใช้ https://typesense.org/ สำหรับการค้นหาทั่วไป ตอนนี้รองรับ การค้นหาแบบไฮบริด แล้วเลยสงสัยว่ามีใครเคยใช้บ้างไหม

    • เคยใช้กับการค้นหาแบบไฮบริดแล้ว และทำงานได้ค่อนข้างดี
      ดีใจที่เห็น Typesense ถูกพูดถึงที่นี่ สำหรับ โปรเจ็กต์ RAG ขนาดเล็กมักจะเหมาะมาก แต่แปลกที่ยังไม่ค่อยเป็นที่รู้จัก
      ดีพลอยง่าย ค่าตั้งต้นก็สมเหตุสมผล เอกสารก็ดี และทำคลัสเตอร์ก็ไม่ยาก แต่ถ้าต้องลงลึกมากขึ้นก็ยังทรงพลังและให้ประสิทธิภาพได้ดีพอ
    • เราก็ใช้อยู่และโดยรวมพอใจ
      แต่ถ้าใช้โมเดล embedding จากผู้ให้บริการภายนอก latency จะสูงถึง 500ms+ แบบเกินรับได้ ดังนั้นโฮสต์เองในคลัสเตอร์จะดีกว่า
      คุณภาพของการค้นหาแบบไฮบริดดี แต่ตัวเลือกในการปรับจูนมีจำกัดมาก และคะแนนก็ค่อนข้างไม่โปร่งใส นอกจากใช้สำหรับจัดอันดับภายในชุดผลลัพธ์

  • ในช่วงที่ การค้นหาเชิงความหมายแบบเวกเตอร์ พัฒนาไปมาก อยากรู้ว่าตอนนี้ search stack สมัยใหม่ที่ใช้กับไฮบริดระหว่างคีย์เวิร์ด + ความหมายคืออะไร

    • กลยุทธ์การค้นหาแบบใช้งานทั่วไปจริง ๆ แล้วต่างกันโดยสิ้นเชิงตามงานที่ต้องการทำ
      ไม่นานมานี้ผมได้รับแบบสำรวจราว 3 ล้านรายการที่แต่ละรายการมีฟิลด์คำตอบอิสระ 10 ฟิลด์ และต้องหาสิ่งที่บริษัทควรลงมือจัดการ
      ใช้โมเดลจำแนกขนาดเล็กอยู่ไม่กี่ตัว ดู noise ที่โผล่มาใน 10,000 รายการแรก แล้วลบคำที่พบบ่อยออกด้วยมือ จากนั้นให้น้ำหนักกับคำตอบของโมเดล ก็ทำงานได้แทบสมบูรณ์แบบ
      งานแบบนี้ใกล้เคียงกับการปรับแต่ง ผลลัพธ์กล่องดำ จากหลายเครื่องมือไปเรื่อย ๆ จนดูดีสำหรับ test case และลูกค้า มากกว่าจะเรียกว่า “การเขียนโปรแกรม”
      อ้างอิงไว้ว่า ผมประมวลผลโดยเชื่อมโมเดลขนาดเล็กหลายตัวจาก Hugging Face ด้วย Node.js บนเซิร์ฟเวอร์ขนาดเล็ก
    • ผลิตภัณฑ์ค้นหาแบบไฮบริดทั้งเชิงพาณิชย์และโอเพนซอร์สส่วนใหญ่ดูเหมือนจะใช้ BM25 + การค้นหาความคล้ายคลึงแบบเวกเตอร์ที่อิง embedding
      โดยปกติจะรวมผลลัพธ์ด้วย Reciprocal Rank Fusion (RRF)
      งานวิจัยของ RRF เรียบง่ายจนน่าประทับใจ และตัวงานมีแค่ 2 หน้า: https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf
    • อย่าไปโฟกัสกับสแตกเดียว ควรพร้อมเลือกเครื่องมือที่เหมาะที่สุดสำหรับแต่ละงาน
      งานแนว BM25 ใช้ Elasticsearch, งานค้นหาเวกเตอร์ที่เรียบง่ายและเร็วใช้ Turbopuffer, และสำหรับการคำนวณผลลัพธ์ของบางคำค้นล่วงหน้าหรือคุณสมบัติแบบไดนามิกที่เปลี่ยนบ่อยอย่างราคา ก็อาจใช้ Redis ได้
      ผมคิดว่าควรรวมสิ่งเหล่านี้ด้วย แนวทาง scatter/gather
      ภายนอก search stack แทบจะมีชั้นบริการ inference สำหรับ reranking อยู่เสมอ และในอุดมคติมันควรเป็นบริการเรียบง่ายคล้ายกับโครงสร้างพื้นฐานแมชชีนเลิร์นนิงอื่น ๆ
      เกือบตลอดเวลายังต้องมีการ routing เพื่อทำความเข้าใจคำค้นของผู้ใช้ เช่น ส่ง “ค้นจาก ID” ไปยังระบบหนึ่ง และส่ง “การค้นหาเชิงความหมายแบบ fuzzy” ไปอีกระบบหนึ่ง
      พวกมันมีโครงสร้างข้อมูลที่ต่างกันมาก และการค้นหาก็มักครอบคลุม use case ที่แตกต่างกันอย่างกว้างขวาง
      การยัดทุกอย่างเข้าไปในระบบเดียวเป็น anti-pattern ในมุมมองของผม
      แต่ละระบบเหมาะกับภาระงานคนละแบบ และความสามารถด้าน inference ที่ฝังมาในตัวก็มักตามความเร็วของเครื่องมือแมชชีนเลิร์นนิงทั่วไปที่วิศวกร ML คุ้นเคยไม่ทัน
      ผมเคยลองกับ Elasticsearch Learning to Rank แล้ว แต่เป็นงานที่ไร้หวัง
      ถึงอย่างนั้น หากจะพยายามรองรับ use case ที่กว้างด้วยสแตกเดียว Vespa น่าจะดีที่สุด
    • เป็นบทความที่ยอดเยี่ยมเกี่ยวกับ BM25
      ในฐานะผู้เขียน txtai, txtai implements ดัชนี BM25 ที่มีประสิทธิภาพใน Python ผ่านแพ็กเกจ arrays และเก็บเวกเตอร์ความถี่ของคำไว้ใน SQLite
      วิธีทำดัชนีแบบไฮบริดของ txtai รองรับการรวมแบบเชิงนูนเมื่อคะแนน BM25 ถูกทำ normalization แล้ว และรองรับ Reciprocal Rank Fusion (RRF) เมื่อยังไม่ได้ทำ normalization
      [1] https://github.com/neuml/txtai
      [2] https://neuml.hashnode.dev/building-an-efficient-sparse-keyw...
      [3] https://neuml.hashnode.dev/benefits-of-hybrid-search
      [4] https://github.com/neuml/txtai/blob/master/src/python/txtai/...
    • ไลบรารี LLM อย่าง Langroid[1] มี การทำ RAG ที่สะอาดและขยายต่อได้อยู่ใน DocChatAgent[2]
      ใช้เทคนิคการค้นหาหลายแบบ เช่น การค้นหาเชิงศัพท์ (bm25, fuzzy search), การค้นหาเชิงความหมาย (embedding), reranking (cross-encoder, Reciprocal Rank Fusion) รวมถึงการ rerank เพื่อเพิ่มความหลากหลายและบรรเทาปัญหา lost-in-the-middle
      [1] Langroid - เฟรมเวิร์ก LLM แบบมัลติเอเจนต์ที่สร้างโดยนักวิจัยจาก CMU/UW-Madison https://github.com/langroid/langroid
      [2] การใช้งาน DocChatAgent -
      https://github.com/langroid/langroid/blob/main/langroid/agen...
      เริ่มจากเมธอด answer_from_docs แล้วไล่ตามไปได้เลย
      เสริมอีกนิดว่า ถ้าเป็นผู้ก่อตั้ง Kadoa, Kadoa-snack คือหนึ่งในเครื่องมือที่ผมใช้ทุกวันอย่างเพลิดเพลินเพื่อหากระทู้ HN เกี่ยวกับ LLM

  • เป็นบทความที่ดี
    ถ้าจะเสริมพื้นหลังที่หาข้อมูลได้ยากขึ้นอีกหน่อย BM25 ย่อมาจาก “Best Matching 25” และ “best matching” หมายถึงสูตรที่จับคู่คำในคำค้นกับคำในเอกสารเพื่อจัดอันดับและให้น้ำหนักคำ
    ส่วน 25 เป็นเพียงหมายเลขลำดับ โดยก่อนหน้านั้นมีสูตรดัดแปลงมาแล้ว 24 แบบ และหลังจากนั้นก็ยังมีแบบดัดแปลงต่อมาอีก แต่หมายเลข 25 ทำงานได้ดีที่สุดจึงถูกเผยแพร่ออกมา
    แนวคิดนี้ออกแบบโดย Stephen Robertson และ Karen Spärck Jones (ผู้มีชื่อเสียงจาก IDF) และถูกนำไปใช้งานครั้งแรกในระบบวิจัยการค้นคืนสารสนเทศ OKAPI ของ Robertson
    ระบบ OKAPI ถูกใช้เป็นเบนช์มาร์กอยู่หลายปีในงานประจำปี TREC (Text Retrieval Conference) ของ NIST สหรัฐฯ ซึ่งใกล้เคียงกับ “ชิงแชมป์โลก” ด้านระเบียบวิธีของเสิร์ชเอนจินในระดับนานาชาติ
    อย่างไรก็ตาม งานนี้มีเป้าหมายเพื่อการเปรียบเทียบและการเรียนรู้ร่วมกันมากกว่าการหาผู้ชนะ และเป็นงานที่น่าแนะนำซึ่งจัดขึ้นทุกเดือนพฤศจิกายนที่เมือง Gaithersburg รัฐ Maryland
    นอกจากโมเดลเวกเตอร์สเปซแบบ “ถุงคำ” (สปาร์สเวกเตอร์ของคำ) และโมเดลเชิงความน่าจะเป็นที่ BM25 อยู่ในกลุ่มเดียวกันแล้ว กรอบทฤษฎีสำหรับการจัดอันดับชุดเอกสารเมื่อมีคำค้นกำหนดให้ยังมีอีกมากอย่างน่าทึ่ง และเพิ่มขึ้นอย่างต่อเนื่อง
    ตัวอย่างเช่น divergence from randomness, statistical language modeling, Learning to Rank, quantum information retrieval และ neural ranking
    ในงานประชุมอย่าง ICTIR หรือ SIGIR ทุกวันนี้ก็ยังมีพาราไดม์การค้นหาแบบใหม่อย่างสิ้นเชิงโผล่มาเป็นครั้งคราว
    โดย “statistical language modeling” ในที่นี้ไม่ได้หมายถึง large language models ที่กำลังนิยมกันตอนนี้ เพราะฝั่งนั้นจะอยู่ในหมวด “neural search”
    อีกอย่าง ถ้าค้นหา “Quantum IR” คุณอาจเจออินฟราเรดสเปกโทรสโกปีหรือบริษัทซีเมนต์ชื่อเดียวกัน แทนที่จะเป็นบทเรียนเรื่อง quantum information retrieval
    แม้ในศตวรรษที่ 21 เทคโนโลยีการค้นหาก็ยังมีความละเอียดอ่อนแบบนี้อยู่
    ถ้าอยากลองเปรียบเทียบ BM25 กับทางเลือกอื่นด้วยตัวเอง ขอแนะนำ Terrier ซึ่งเป็นทั้งเสิร์ชเอนจินโอเพนซอร์สและแพลตฟอร์มวิจัยที่พัฒนาโดย University of Glasgow
    BM25 มีอายุมากกว่า 25 ปีแล้ว แต่ก็ยังพิสูจน์ตัวเองว่าเป็น baseline ที่เอาชนะได้ยาก และมักถูกใช้เป็นจุดอ้างอิงเมื่อเปรียบเทียบวิธีใหม่ ๆ
    ส่วน BM24F ซึ่งเป็นรุ่นดัดแปลงที่ใหม่กว่า สามารถจัดการหลายฟิลด์และไฮเปอร์เท็กซ์ต์ได้ เช่น ชื่อเรื่อง เนื้อหา และไฮเปอร์ลิงก์
    งานวิจัยที่แนะนำคือ Spärck Jones, K.; Walker, S.; Robertson, S. E. (2000). “A probabilistic model of information retrieval: Development and comparative experiments: Part 1”. Information Processing & Management 36(6): 779–808 และ Part 2 ที่ตามมา
    น่าเสียดายที่ไม่ใช่โอเพนแอ็กเซส

    • บังเอิญว่า US NIST TREC กำลังจัดอยู่พอดี
      เริ่มวันที่ 18 และจบวันที่ 22
      รายละเอียด: https://trec.nist.gov/
    • สงสัยว่ามีข้อมูลเกี่ยวกับ BM24F เพิ่มเติมอีกไหม
      ลองหาทั้งใน Google และ Google Scholar แล้วก็ยังไม่เจอข้อมูลที่เกี่ยวข้อง

  • ขอโปรโมตแบบเขิน ๆ: https://github.com/jankovicsandras/plpgsql_bm25
    https://github.com/jankovicsandras/bm25opt

    • ถ้ากระแสตอนนี้คือโปรโมตโปรเจกต์งานอดิเรกกันแบบไม่เขิน SearchArray คือส่วนขยายของ pandas สำหรับการค้นหาแบบ full-text (BM25) เวลาเอาไปลองเล่นโน่นนี่บน Google Colab
      https://github.com/softwaredoug/searcharray
      ขอโปรโมต BM25S ของ Xing Han Lu ที่มีเป้าหมายคล้ายกันและได้รับความนิยมมากเช่นกัน
      https://github.com/xhluca/bm25s
    • เมื่อวานกำลังคิดจะเพิ่ม BM25 เข้าไปในไซด์โปรเจกต์เล็ก ๆ พอดี เลยเป็นการโปรโมตที่จังหวะดีมาก
      สงสัยว่ามี โปรเจกต์ wrapper แบบ Python ล้วน สำหรับจัดการข้อความจำนวนมากและเอกสาร PDF หรือเปล่า
      เคยนึกถึง Solr กับ ElasticSearch แต่ดูหนักเกินไปสำหรับสิ่งที่กำลังจะทำตอนนี้
      เนื่องจาก SQLite ใช้ BM25 อยู่ เลยกำลังพิจารณาทางเลือกที่จะใช้ pysqlite3 ร่วมกับ PyPDF2
      แม้จะออกนอกประเด็นไปนิด แต่คิดว่าน่าจะมีคนจำนวนมากที่กำลังมองหาเครื่องมือสำหรับสร้างแอปพลิเคชันแบบไฮบริด BM25 / vector store / LLM

  • สงสัยว่าความยาวเอกสารเฉลี่ยที่พูดถึงใน document length normalization นั้นเป็น ค่ามัธยฐาน หรือเปล่า
    เพราะถ้าจะลดน้ำหนักเอกสารที่ยาวเกินไปให้เหมาะสม มันก็น่าจะควรเป็นค่ามัธยฐาน ไม่อย่างนั้นเอกสารที่ยาวมาก ๆ จะไม่ดันค่าเฉลี่ยขึ้นอย่างไม่เป็นธรรมหรือ?

    • ถ้าอิงตาม Lucene จะเป็น ค่าเฉลี่ยเลขคณิต
      การลองใช้ค่ามัธยฐานก็น่าจะเป็นการทดลองที่น่าสนใจ
      สงสัยว่าคุณรู้จักชุดข้อมูลค้นหาที่ความยาวเอกสารต่างกันมาก ๆ ไหม
      ตัวอย่างเช่น MSMarco มีความยาวค่อนข้างสม่ำเสมอ

  • เป็นบทความที่ดี
    อยากเรียนรู้อย่างจริงจังว่าควรคิดปัญหาแบบนี้ในรูปแบบ คณิตศาสตร์ อย่างไร และควรทดสอบมันอย่างไร มีแหล่งข้อมูลอะไรที่น่าอ้างอิงบ้างไหม?

  • การค้นหาแบบไฮบริด ช่วยแก้โจทย์เก่าแก่เรื่องความเกี่ยวข้องของผลลัพธ์การค้นหา
    ถ้าใช้ rank fusion ระหว่างคีย์เวิร์ดกับเวกเตอร์ ก็สามารถสร้างการค้นหาแบบไฮบริดที่ใช้ได้ในแทบทุกสถานการณ์

  • BM25 เป็นอัลกอริทึมเก่าที่พัฒนาขึ้นในช่วงทศวรรษ 1970
    โดยพื้นฐานแล้วมันเป็นแบบจำลองเชิงสถิติที่ค่อนข้างหยาบ และนักสถิติยุคนี้น่าจะทำได้ดีกว่านี้มาก
    มองว่าการค้นหาถูกครอบงำอย่างเด็ดขาดด้วยวิธีการที่อิงการเรียนรู้
    แน่นอนว่าการเรียนรู้เองก็สามารถใช้การค้นหาเป็นอินพุตได้
    หลายคนยังไม่ตระหนักถึงเรื่องนี้ หรือมีแรงจูงใจที่จะยื้อเทคโนโลยีเก่าไว้ให้นานที่สุดเท่าที่จะทำได้ แต่แรงกดดันจากตลาดจะเปลี่ยนสิ่งนี้ในที่สุด

    • แรงกดดันจากตลาดที่ว่าคือแรงกดดันเดียวกับที่ทำให้ Google ทิ้งหรือดัดแปลงเทคโนโลยีค้นหาแบบเก่าที่เคยทำงานได้ดี แล้วหันไปหา การค้นหาที่ขับเคลื่อนด้วยแมชชีนเลิร์นนิง แบบใหม่แวววาวใช่ไหม?
      ก็เทคโนโลยีนั้นไม่ใช่หรือที่ทำให้คนต้องเติม “+reddit” ต่อท้ายคำค้นทุกครั้งเพื่อเลี่ยงสงคราม SEO เชิงปฏิปักษ์?
      ของเก่าไม่ได้แปลว่าแย่
      สิ่งที่ควรมองคือประโยชน์ใช้สอย ไม่ใช่อายุของสิ่งประดิษฐ์ การค้นพบ หรือเทคนิค และทัศนะแบบคลั่งไคล้เทคโนโลยีใหม่เพราะมันใหม่อย่างเดียวก็น่ากังวล
    • จริงอยู่ว่า BM25 มีรากมาจากงานวิจัยยุคต้นในช่วงทศวรรษ 1970–80 โดยเฉพาะ หลักการจัดอันดับเชิงความน่าจะเป็น แต่ก็มีบางอย่างที่ผมสงสัย
      แนวทางเชิงสถิติสมัยใหม่แบบใดบ้างที่เหนือกว่าจนสามารถแทนที่ BM25 ในแอปพลิเคชันจริงได้?
      โดยเฉพาะอยากรู้ว่ามันจัดการกรณีขอบอย่างคำที่พบไม่บ่อยและการทำ normalization ตามความยาวเอกสาร ซึ่งเป็นสิ่งที่ BM25 พยายามจัดการอย่างชัดเจนไว้อย่างไร
      ผมเห็นด้วยว่าวิธีแบบอิงการเรียนรู้ให้ผลลัพธ์ที่น่าประทับใจ แต่ก็อยากฟังเพิ่มด้วยว่าคำพูดที่ว่าการค้นหา “ถูกครอบงำอย่างเด็ดขาด” โดยวิธีการเรียนรู้นั้นหมายถึงอะไรกันแน่
      หมายถึง benchmark บางตัว หรือหมายถึงกรณีใช้งานจริงในการปฏิบัติงาน?
    • เป็นความเห็นที่ค่อนข้างแรงทีเดียว
      คิดว่าผู้เชี่ยวชาญด้านการค้นหาหลายคนคงไม่เห็นด้วย
      ชื่อพอดแคสต์ที่ยอดเยี่ยมของ David Tippet (อดีต OpenSearch ปัจจุบันอยู่ที่ Github) และ Nicolay Gerold คือ:
      “BM25 is the workhorse of search; vectors are its visionary cousin”
      https://www.youtube.com/watch?v=ENFW1uHsrLM
    • แน่นอนว่าก็มีแรงจูงใจในการขาย “ของใหม่” อยู่ด้วย
      ในวงการค้นหา มีทั้งกระแสและเทคโนโลยีที่เกี่ยวกับ AIนับไม่ถ้วนตลอดช่วงเวลาที่ผมทำงานมา
      ตอนนี้บริษัทด้าน vector search ที่ได้รับเงินลงทุนจาก VC มหาศาล กำลังผลักดันมุมมองบางแบบผ่านกองทัพนักเผยแพร่เทคโนโลยี
      ในทางกลับกัน ปริมาณงานคัดสรรด้วยมือและระบบจัดหมวดหมู่แบบพื้นฐานที่น่าเบื่อแต่จำเป็น ซึ่งเป็นตัวขับเคลื่อน “semantic search” จริง ๆ ในที่อย่าง Google นั้นมีมหาศาล
      เพียงแต่เรื่องพวกนี้ไม่เซ็กซี่พอ จึงไม่ค่อยถูกพูดถึงในงานคอนเฟอเรนซ์เท่านั้นเอง