ค้นหาหน้า Wikipedia หลายล้านหน้าด้วย ‘vibe’ แบบออฟไลน์

• สร้าง การค้นหา embedding แบบเรียลไทม์ออฟไลน์ ภายในเบราว์เซอร์โดยไม่ต้องมีเซิร์ฟเวอร์ ทำให้สำรวจเอกสาร English Wikipedia 6 ล้านรายการแบบโต้ตอบได้จากเครื่องโลคัล
• embedding ต้นฉบับขนาด 384 มิติแบบ float32 มีขนาดราว 9GB จึงไม่เหมาะกับแอปบนเบราว์เซอร์ จึงลดขนาดโดยใช้ all-minilm-l6-v2 และค่าเฉลี่ย embedding ของแต่ละชังก์ของหน้า
• ใช้ Product Quantization กับ subspace ขนาด 8 มิติ เพื่อลดขนาดชุดข้อมูลเหลือราว 288MB และสามารถเก็บ embedding ได้ประมาณ 2 ล้านรายการใน 96MB
• การค้นหาคำนวณระยะทางใน compressed domain โดยไม่ต้องคลายการบีบอัด และแก้การแปลงผลลัพธ์ด้วย opcode GatherElements ของ ONNX เพื่อให้คำนวณได้เร็วขึ้นราว 4 เท่า
• บนอุปกรณ์รุ่นใหม่ การอนุมาน MiniLM และการคำนวณระยะทางของ embedding 100k รายการเสร็จได้ในเวลาสั้นพอที่ React UI จะอัปเดตผลลัพธ์ทุก 100–300ms

---

การค้นหาเวกเตอร์ออฟไลน์ที่รันในเบราว์เซอร์

• เป้าหมายคือการแสดงให้เห็นว่าแม้ไม่มีโครงสร้างพื้นฐานการค้นหาฝั่งเซิร์ฟเวอร์ที่ซับซ้อน ก็ยังค้นหา หน้า Wikipedia หลายล้านหน้า แบบเรียลไทม์ในเบราว์เซอร์ได้
• แนวคิดหลักของการออกแบบสรุปได้เป็นสามข้อ
  • การค้นหาเวกเตอร์อาจเร็วพอได้ด้วยแค่ Product Quantization และ linear scan
  • ใช้ ONNX Runtime แต่ความไม่มีประสิทธิภาพที่เกิดจากการแปลงจาก PyTorch สามารถแก้ได้ในระดับ opcode
  • เบราว์เซอร์เร็วพอสำหรับการอนุมานแบบเรียลไทม์ด้วย WASM และ WebGPU ก็ยังเป็นความเป็นไปได้ในอนาคต
• เงื่อนไขการค้นหาใช้ทั้งความคล้ายเชิงเวกเตอร์ของ embedding เนื้อหา และเงื่อนไขความเท่ากันของอักษรตัวแรกของชื่อเรื่องร่วมกัน
  • ใกล้เคียงกับกรณี query ฐานข้อมูลที่บางคอลัมน์ค้นหาด้วยความคล้ายเชิงเวกเตอร์ และบางคอลัมน์ค้นหาด้วยเงื่อนไขความเท่ากัน
• เพราะมีข้อจำกัดว่าเป็นแอปเบราว์เซอร์ออฟไลน์ embedding จึงต้องมีขนาดเล็ก โมเดล embedding ต้องเป็นโอเพนซอร์ส และทั้งขนาดโมเดลกับปริมาณการคำนวณก็ต้องเบาด้วย
  • ณ ปี 2023 โมเดลขนาดเบามักหมายถึง ต่ำกว่า 100MB

ข้อมูล English Wikipedia และขนาดของ embedding

• ชุดข้อมูลคือ English Wikipedia และสร้าง embedding ด้วยโมเดล all-minilm-l6-v2
• มีเอกสารประมาณ 6 ล้านรายการ และสร้าง page embedding โดยแบ่งหน้าเป็นชังก์ก่อน แล้วนำ embedding ของแต่ละชังก์มาเฉลี่ย
• จัดเรียงหน้าโดยเอาหน้าที่ยาวกว่าขึ้นก่อน
  • เพื่อให้ตอนโหลดฐานข้อมูลแบบค่อยเป็นค่อยไป ผู้ใช้ได้เห็นหน้าที่ยาวซึ่งน่าจะมีการลงแรงเขียนมากกว่าก่อน
• embedding มีขนาด 384 มิติ
  • ถ้าจัดเก็บเป็น float32 จะได้ 6M * 384 * 4 = 9GB
  • ใน 96MB จะเก็บได้เพียงประมาณ 64k embeddings
• การเข้ารหัส float32 แบบดิบมีขนาดใหญ่เกินไปสำหรับการค้นหาออฟไลน์บนเบราว์เซอร์

บีบอัด embedding ด้วย Product Quantization

• Product Quantization เป็นวิธีที่ไม่เก็บค่าทศนิยมโดยตรง แต่สร้าง palette หลายชุด แล้วแทนค่าข้อมูลด้วยดัชนีของ palette
• โดยทั่วไป palette มีค่าไม่เกิน 256 ค่า ดังนั้นแต่ละดัชนีจึงใช้ได้สูงสุด 1 ไบต์
  • implicit palette ใช้การเลื่อนและสเกลเส้นจำนวนแนวตั้ง เช่น -127~127 หรือ 0~255
  • explicit palette เก็บตัวเลข 256 ตัวเรียงไว้โดยตรง
  • Product Quantization ใช้การทำ palette แบบ explicit
• แม้ในรูปแบบต่ำสุด ถ้าแทน 384 มิติแต่ละมิติด้วยดัชนี 1 ไบต์ ชุดข้อมูลก็ยังมีขนาด 6M * 384 = 2.25GB
  • ใน 96MB จะเก็บได้ประมาณ 256k embeddings
  • วิธีนี้ก็ยังไม่มีประสิทธิภาพพอสำหรับเป้าหมาย
• หาก quantize เป็นจุดขนาด 2 มิติ จะสามารถแทน embedding 384 มิติด้วยดัชนี 192 ตัว และ ประหยัดพื้นที่ได้ 2 เท่า
• การตั้งค่าจริงใช้หน่วยเป็น จุด 8 มิติ
  • แทน 384 มิติด้วยดัชนี 48 ตัว
  • ขนาด palette คงอยู่ที่ประมาณ 384KB
  • ขนาดชุดข้อมูลเป็น 6M * 48 = 288M
  • ใน 96MB จะเก็บได้ประมาณ 2 ล้าน embeddings
• สามารถประเมิน precision และ recall ได้ในทุกระดับของการ quantize

ค้นหาได้ทันทีโดยไม่ต้องคลายการบีบอัด

• ข้อดีของ Product Quantization คือสามารถค้นหาใน สถานะที่ถูกบีบอัด ได้โดยไม่ต้องคลายการบีบอัด
• ถ้าจัดกลุ่ม n มิติเป็นจุด 2 มิติ จำนวน n/2 จุด ก็สามารถคำนวณระยะทางระหว่างจุดใน palette แต่ละจุดกับจุด 2 มิติที่สอดคล้องกันของ query ล่วงหน้าได้
• จากนั้น embedding แต่ละรายการก็เพียง lookup ค่าระยะทางจากดัชนี palette แล้วนำมาบวกกันเพื่อหาระยะทางรวม
  • ใช้งานน้อยกว่าวิธีที่ต้องสร้างจุด n มิติเต็มกลับคืนมาก่อน แล้วค่อยคำนวณระยะทางทีละมิติ
• ในโครงแบบจุด 8 มิติจริง สามารถคำนวณระยะทางได้ด้วยงานเพียง 1/8 ของการจัดการ embedding แบบไม่บีบอัด

ใช้ Arrow เป็นฟอร์แมตสำหรับแลกเปลี่ยนข้อมูล

• เนื่องจากต้นทุนของการย้ายและแปลงข้อมูลสูง จึงได้ประโยชน์จากการ serialize embedding ที่บีบอัดแล้วให้อยู่ในรูปแบบที่พร้อมใช้งานทันที
• Arrow เป็นฟอร์แมตแบบคอลัมน์ที่เหมาะกับงานลักษณะนี้
  • เก็บ embedding และชื่อหน้าลงใน Arrow table
  • ดัชนี palette จัดการเหมือนอาร์เรย์ 2 มิติ ส่วนชื่อเรื่องจัดการเหมือนอาร์เรย์สตริง 1 มิติ
  • จึงเน้นการคัดลอกบิตไปยังตำแหน่งที่ถูกต้อง มากกว่าการ parse หรือโหลดแบบซับซ้อน
• เนื่องจากฟอร์แมตอาร์เรย์ของ Arrow เก็บข้อมูล 1 มิติเท่านั้น จึงใช้สองสคีมาเพื่อจัดการ embedding 48 มิติ
  • สคีมา metadata ใช้หน่วยละ 100,000 แถว
  • สคีมา embedding ใช้หน่วยละ 100,000 * 48 แถว
  • ตอนโหลดจึง reshape embedding กลับใหม่
• safetensors ก็ใช้หลักการออกแบบแบบเดียวกัน
• JSON จะ serialize อาร์เรย์ 48 องค์ประกอบเป็นอักขระ ASCII ความยาวแปรผัน ทำให้ขั้นตอนโหลดซับซ้อนขึ้น
• Protocol Buffers ใช้จำนวนเต็มแบบความกว้างแปรผัน base 128 สำหรับจำนวนเต็มที่เล็กกว่า 32 บิต ซึ่งฟอร์แมตจำนวนเต็มนี้ยังไม่รองรับได้ดีใน compute kernel ปัจจุบัน

การ parse Wikipedia และการสร้าง embedding

• ใช้ mediawiki parser from hell หรือ mwparserfromhell สำหรับ parse มาร์กอัปของ Wikipedia
• Wikipedia dataset ของ OLM จะดึง data dump ล่าสุดของ Wikipedia ในภาษาที่กำหนด แล้ว parse ออกมาเป็นแถวที่มีชื่อเรื่องและเนื้อหา
  • ชุดข้อมูลนี้ไม่ใช่ข้อมูล serialized ที่ไร้อันตราย แต่ใกล้เคียงกับโค้ดที่ต้องนำไปรัน จึงต้องอาศัยความเชื่อถือในการรัน
• การ parse ทำบนทุกคอร์ของเครื่องหนึ่งเครื่อง
  • เครื่องรุ่นใหม่มีหลายสิบคอร์ จึงเหมาะกับระบบที่มีเอกสารต่ำกว่า 100 ล้านชิ้น เช่น English Wikipedia ปัจจุบันที่มีขนาด 6 ล้านหน้า
• โมเดล embedding ใช้ all-minilm-l6-v2
  • เป็น sentence transformer สำหรับภาษาอังกฤษที่ประสิทธิภาพดีและน้ำหนักเบา
  • ฝัง query และเอกสารลงใน space เดียวกัน
  • มีเพียง 22 ล้านพารามิเตอร์ จึงเป็นโมเดลที่เบามาก
• สำหรับการรัน JavaScript ในเบราว์เซอร์ ยังใช้เวอร์ชัน quantize 8 บิตผ่าน ONNX และ transformers.js
• โมเดลถูกฝึกด้วยลำดับโทเค็น 128 โทเค็น ซึ่งมี context window สั้นกว่าความยาวเฉลี่ยของหน้ามาก
  • จึงแบ่งหน้าเป็นชังก์ แล้วเฉลี่ย embedding ของแต่ละชังก์เพื่อสร้าง page average embedding

pq.js และการค้นหาแบบ facet ที่อิง linear scan

• เมื่อค้นหาเอกสารหลายล้านชิ้นในเครื่องโลคัล อาจไม่จำเป็นต้องมีระบบ indexing ที่ซับซ้อน
• เป้าหมายคือการหาผลลัพธ์ใกล้ที่สุดไม่กี่รายการจากจุดหนึ่ง เช่น ระยะทาง top 12
• หากมีอาร์เรย์ระยะทาง 10 ล้านค่า คอลัมน์ facet 10 ล้านค่า และค่า facet หนึ่งค่า ก็สามารถกรองโดยบวก 0 หากตรงเงื่อนไข หรือบวก Infinity หากไม่ตรงเงื่อนไข แล้วจึงหา top-k
  • บนโทรศัพท์สมัยใหม่ สามารถหา top 100 ได้ในเวลา ต่ำกว่า 10ms
  • ตัวอย่างการทำงานอยู่ใน filtered-topk และ pq.js
• การคำนวณระยะทางของ embedding ที่ถูกบีบอัดด้วย Product Quantization สามารถเขียนใน PyTorch ได้
  • มี palette จำนวน subspaceCount ชุด และแต่ละ palette มีจุด subspaceDim มิติอยู่ codewordCount จุด
• การทำดัชนีของโมเดล ONNX ที่ export จาก PyTorch ออกมาจะมีรูปแบบที่ค่อนข้างแปลก
  • opcode GatherElements ของ ONNX สามารถทำงานที่ต้องการได้โดยตรง
  • เครื่องมืออย่าง ONNX-modifier สามารถเพิ่มหรือลบโหนดใน dataflow graph ของโมเดล ONNX ที่ export แล้วได้
• เมื่อเปลี่ยนการทำดัชนีหลายขั้นให้เป็น opcode เดียวที่ถูกต้อง จะทำให้ การคำนวณระยะทางเร็วขึ้นประมาณ 4 เท่า

การคำนวณแบบสตรีมและ UI เชิงโต้ตอบ

• จำนวน embedding ที่นำมาคำนวณระยะทางไม่จำเป็นต้องคงที่
  • สามารถคำนวณระยะทางระหว่าง query กับ embedding บางส่วนแบบสตรีมได้
  • เมื่อเวลาผ่านไปพอสมควร ก็ใช้ระยะทางที่คำนวณได้จนถึงตอนนั้นมารัน top-k เพื่ออัปเดตผลการค้นหา
• เพราะ embedding ทั้งหมดอยู่ในเครื่องโลคัล จึงแทบไม่มี latency ไปยังโครงสร้างพื้นฐานการค้นหา หรือเท่ากับ 0ms
• เป้าหมายด้าน responsiveness ของ UI คือหลังสั่งงานแล้วควรเห็นผลลัพธ์ภายใน 100–300ms
  • MiniLM รันได้ในเวลาต่ำกว่า 100ms
  • บนอุปกรณ์ edge บางรุ่นอาจต่ำกว่า 15ms
  • การคำนวณระยะทางของ embedding 100k รายการทำได้ในราว 10ms
• หากเรียงชุดข้อมูลจากบทความยาวไปสู่บทความสั้น ผลการค้นหาอันดับต้น ๆ ส่วนใหญ่จะปรากฏเร็วในผลลัพธ์สตรีมช่วงแรก
  • เพราะบทความยาวมักได้รับความใส่ใจและลงแรงมากกว่า และมักตรงกับ query ค้นหามากกว่าบทความ stub จำนวนมาก
• เนื่องจากคำนวณระยะทางแบบ global ก่อน แล้วจึงใช้ facet filter และ top-k ดังนั้นเมื่อใช้ query เดิมแล้วเปลี่ยนค่า facet หรือจำนวนผลลัพธ์ที่ต้องการ ก็เพียงรันการกรองใหม่
  • การกรองนี้ใช้เวลาต่ำกว่า 10ms จึงให้ความรู้สึกตอบสนองทันที

คอมโพเนนต์ pq.js ที่นำกลับมาใช้ซ้ำได้

• ฟังก์ชันไลบรารีจำนวนมากจาก Wikipedia search app ทั้งชุด สามารถย้ายมาเป็นคอมโพเนนต์ pq.js ที่นำกลับมาใช้ซ้ำได้
• ปัจจุบัน ONNX shape จำนวนมากยังถูกกำหนดตายตัวไว้ล่วงหน้า
• หากรองรับระดับการ quantize ที่หลากหลายและ embedding หลายขนาดมิติ ก็จะนำกลับไปใช้ซ้ำได้กว้างขึ้น

[GN⁺]

ความคิดเห็นจาก Hacker News

• น่าสนใจจริง ๆ แต่ตอนลองอธิบายคำศัพท์ด้านปรัชญาและจิตวิทยาอยู่ไม่กี่คำ รายการที่หาอยู่ทั้งหมดโผล่มาแค่แถว ๆ อันดับ 20
  รายการที่ดังมากกว่าแต่แม่นน้อยกว่าถูกดันขึ้นมาก่อน เช่น ไม่ว่าจะพิมพ์อะไรเพื่อจะนิยามแนวทางจิตบำบัดแบบหนึ่ง “psychotherapy” ก็ขึ้นอันดับ 1 เสมอ
  ในทางกลับกัน เคยใช้ ChatGPT หา สาขาย่อยแคบ ๆ ที่จำชื่อไม่ได้ และมันทายถูกทุกครั้ง
  ไอเดียของบริการ AI ที่ช่วยหาชื่อของสิ่งต่าง ๆ จากคำอธิบายนั้นดี แต่ไม่แน่ใจว่าการจำกัดไว้ที่ Wikipedia หรือชื่อบทความใน Wikipedia เป็นวิธีที่ถูกไหม และดูเหมือนโมเดลภาษาขนาดใหญ่แบบทั่วไปก็ทำได้ค่อนข้างดีอยู่แล้ว
  ถึงอย่างนั้น ในฐานะ proof of concept และการที่รันในเครื่องผ่านเบราว์เซอร์ได้ก็น่าทึ่งมาก

  • เป้าหมายคือการโชว์ เอนจินฐานข้อมูล และเดโมว่าหลังจากเบราว์เซอร์ดาวน์โหลดทุกอย่างแล้ว มันยังทำงานได้แม้ในสภาพแวดล้อมที่แยกขาดอย่างสมบูรณ์
    ดูเหมือนมีพารามิเตอร์ให้ปรับได้เยอะ เช่น จะใช้แค่ย่อหน้าแรกของเอกสารหรือใช้ทั้งเอกสาร จะค้นหาเฉพาะในขอบเขตที่ใกล้กับเอกสารใดเอกสารหนึ่งหรือไม่ แต่ยังไม่ได้ไปปรับแต่ง
    Wikipedia เป็นชุดข้อมูลเดโมที่ยอดเยี่ยม และอยากลองเพิ่มชุดข้อมูลอื่นด้วย เช่น ถ้าค้นหา “mountain” ใน iPhoto แล้วได้รูปที่มีภูเขา การค้นหาหลายชุดข้อมูลด้วย โมเดลมัลติโมดัล อย่าง CLIP ก็น่าจะสนุก
  • เคยใช้ในลักษณะอธิบายไอเดียและเป้าหมาย แล้วให้มันส่งชื่อสาขาหรือคีย์เวิร์ดที่น่าค้นหากลับมา
    โมเดลภาษาขนาดใหญ่ดูเหมือน เอนจินค้นหาแบบ fuzzy ที่ดีที่สุด และทำงานในแบบที่ค่อนข้างเฉพาะตัวแต่เสริมกันได้ดีกับเสิร์ชเอนจินแบบดั้งเดิม

• ชอบคอนเซปต์ แต่ผลลัพธ์ออกมาไม่ค่อยดี
  พิมพ์ “weird looking monkey” โดยคาดหวังผลลัพธ์อย่างลิงจมูกยาวหรือลิงจมูกเชิดสีทอง แต่ได้แค่บทความอย่าง “Pet monkey”, “List of individual monkeys”, “Ethnoprimatology”, “Monkey”
  น่าเสียดายที่ถ้าใส่คำค้นเดียวกันใน Google จะได้ผลลัพธ์ตรงตามที่คาด และอยากลองค้นหาลิงหน้าตาประหลาด ๆ ที่ไม่รู้จัก

  • ใช้ โมเดล sentence-transformer สำเร็จรูปที่มีอายุมากกว่า 1 ปีตามเดิม
    จุดโฟกัสของเดโมคือการโชว์ฐานข้อมูล embeddings แต่ตัว embeddings เองก็ยังมีประโยชน์อยู่บ้าง
    ไม่ได้เก็บข้อมูลวิเคราะห์เลยว่าผู้ใช้ค้นหาอะไรเจอหรือไม่เจอในหน้าเว็บ จึงยังไม่พร้อมจะปรับปรุงผลการค้นหา
  • โดยทั่วไป บรรณาธิการและแนวทางของ Wikipedia ไม่ค่อยชอบ คำคุณศัพท์เชิงอัตวิสัย และคำว่า “weird looking” ในคำค้นฟังดูเป็นสำนวนที่บทความ Wikipedia น่าจะหลีกเลี่ยง
    เลยทำให้ดึงผลลัพธ์ที่ดีจากคลังความรู้นี้ยากขึ้น

• การทำงานดีมาก และเจ๋งที่ทำสิ่งนี้ได้แบบ ออฟไลน์ แต่คุณภาพของ embeddings ยังดูไม่พอ
  เคล็ดลับหนึ่งที่อาจช่วยได้คือไม่ต้อง embed บทความ Wikipedia ทั้งหมด แต่ embed เฉพาะประโยคที่ใกล้เคียงกับคำนิยาม หรือโดยปกติคือประโยคแรก/ย่อหน้าแรก ตอนนี้ไม่ค่อยแน่ใจว่าใช้ส่วนไหนอยู่
  เว็บไซต์ของผม OneLook ก็ให้ฟีเจอร์คล้ายกันในการค้นหาคำและแนวคิดจากคำอธิบายมาตั้งแต่ปี 2003 ที่ https://onelook.com/thesaurus/
  ตอนแรกเป็นการค้นหาพจนานุกรมย้อนกลับล้วน ๆ แต่ตลอด 20 ปีที่ผ่านมาได้ลองทั้ง word embeddings, sentence embeddings และล่าสุดรวมถึงโมเดลภาษาขนาดใหญ่ ปัจจุบัน GPT จะสร้างตัวเลือกสำหรับอินพุตที่ระบบตอบเองไม่ได้
  ในงานนี้ โมเดลภาษาขนาดใหญ่ ทำได้ดีกว่าวิธีเก่ามาก จนทำให้แรงจูงใจที่จะปรับปรุงส่วนนี้ของ OneLook ลดลงเล็กน้อย ผมเจอคนบ่อย ๆ ที่บอกว่าการค้นหา reverse definition คือเหตุผลหลักที่ใช้ ChatGPT

• เห็นช้าไปหน่อย แต่ text embeddings อย่างน้อยก็ในบรรดาที่ใช้ในบทความนี้ โดยทั่วไปไม่ได้ดีนักสำหรับการ ค้นหาตามบรรยากาศ
  ส่วนใหญ่จะใกล้เคียงกับการเปรียบเทียบคำที่ซ้ำกัน หรือค้นหาเนื้อหาที่คล้ายกับคำค้นมากกว่า
  อย่างไรก็ดี มีงานวิจัยล่าสุดที่ลองแก้ปัญหานี้จริง ๆ: “Retrieving Texts based on Abstract Descriptions” (Ravfogel et al., 2023) https://arxiv.org/abs/2305.12517
  ในบทความมีตัวอย่างการค้นหาด้วยคำอธิบายเชิงนามธรรมมากมาย เช่น “สถาปนิกที่ออกแบบอาคาร”, “บริษัทที่เป็นส่วนหนึ่งของบริษัทอื่น”, “หนังสือที่มีอิทธิพลต่อการพัฒนาของแนวเพลง”
  embeddings ดังกล่าวดูเหมือนจะรองรับการค้นหาแบบนี้ได้ดีกว่ามาก ดังนั้นถ้าลองทำการค้นหา Wikipedia แบบออฟไลน์ในบทความที่ลิงก์ไว้ใหม่ด้วย embeddings ประเภทใหม่นี้ ก็น่าจะน่าสนใจ

• ตอนนี้หน้าเว็บไม่ทำงานในสภาพแวดล้อมของผม เพราะ model_quantized.onnx ไม่โหลด
  ระหว่างที่พิมพ์ มันดาวน์โหลดไปถึง 19.2MB แล้ว ความเร็วราว 50KB/s ถ้าผู้เข้าชมทุกคนทำให้เกิดแบบนี้ อาจกำลังทำเรื่องเลวร้ายกับ ค่าแบนด์วิดท์ของ Lee Butterman อยู่ก็ได้

  • กำลังเสิร์ฟเป็นไฟล์สแตติกจาก t2.nano เครื่องเดียว อยู่ เลยไม่รู้ว่าจะเป็นยังไง

• สิ่งที่ทำอยู่น่าประทับใจมาก แต่ คุณภาพผลการค้นหา ดูไม่ดี
  จากประสบการณ์ ผมรู้ว่าการประเมินคุณภาพผลการค้นหาด้วยมือยากจริง ๆ อาจอยู่ใกล้มากกับผลลัพธ์ที่ดีเยี่ยม แต่ก็ยังคืนการจับคู่ที่แย่กว่านั้นมากได้

  • ใช่ คุณภาพน่าจะยังไม่ดีเท่า Similar Website Finder https://explore2.marginalia.nu/ ;)
    คิดว่าถ้าใช้ sentence embeddings ที่ใหม่กว่านี้ ผลลัพธ์น่าจะดีขึ้น และคงต้องเก็บข้อมูลเพิ่ม

• เทคโนโลยีน่าประทับใจมาก แต่ผลลัพธ์กลับไม่เป็นเช่นนั้น
  พอลองค้นหา “pointy building in Paris” ก็ได้ผลลัพธ์เป็น Tourism in Paris, Bourse de commerce (Paris), Grands Projets of François Mitterrand, List of tallest buildings and structures in the Paris region, List of tourist attractions in Paris, Palais des congrès de Paris, Landmarks in Paris, Palais de la Bourse, Lyon, Outline of Paris, Architecture of Paris
  ไม่เห็นอาคารปลายแหลมที่มีชื่อเสียงที่สุดในปารีสเลย
  สำหรับแอปพลิเคชันแบบนี้ sentence embedding ของทั้งเอกสาร อาจไม่ใช่วิธีที่ดีที่สุดก็ได้

  • อย่างน้อย 5 รายการในนั้นก็น่าจะมีคำตอบที่กำลังหาอยู่
  • ถ้าหมายถึง Eiffel Tower ละก็ นั่นไม่ใช่ อาคาร
    เมื่อกี้ลองตรวจเอกสารดูแล้ว คำว่า “building” ปรากฏ 19 ครั้ง แต่ส่วนใหญ่เป็นคำกริยา และถัดมาก็คือ “Chrysler Building”
    หมายความว่าอย่างนั้น เว้นแต่ว่าจะมีอาคารปลายแหลมชื่อดังอื่นที่ผมนึกไม่ออก

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

• อยากจะชอบอยู่หรอก แต่ในการค้นหาที่ผมลอง แทบไม่ได้ผลลัพธ์ที่เกี่ยวข้องเลย
  “The wizard in The Lord of the Rings” ไม่มี Gandalf หรือ Saruman มีแต่หนังสือที่เกี่ยวกับ LOTR
  “Protagonist of Scorsese's Taxi Driver” ไม่มี Travis Bickle
  “A person that plants trees for a living” ไม่รู้ทำไมถึงไม่มี gardener อยู่ในรายการ
  “Curly-haired painter on TV” ไม่มี Bob Ross เลย
  “Unusually shaped modern art museum in Spain” มี Bilbao โผล่มาอันดับ 4 ก็จริง แต่ที่เหลือไม่ได้มีรูปทรงแปลก
  ถ้าเป็น “Dog shaped like a sausage” ก็ควรมี dachshund อยู่ในผลลัพธ์อันดับต้น ๆ

  • น่าสังเกตว่าผลลัพธ์ที่ต้องการในที่นี้ทั้งหมดมี บทความ Wikipedia อยู่
    ถ้าไม่มีบทความอยู่แล้ว การที่มันหลุดไปก็คงแปลกน้อยกว่านี้ แต่ในความเป็นจริงมีอยู่ทั้งหมด

• “Vibes” เป็นคำที่เข้าถึงความรู้สึกได้ดีกว่า “sentence embeddings” มาก ผมเองก็อาจต้องเริ่มใช้คำนี้บ้างแล้ว :)

  • เป็นคำที่ยอมเสีย ความแม่นยำ ไปมาก แทนที่จะ “เข้าถึงความรู้สึก”
    ผู้เขียนต้นฉบับไม่ได้อธิบายว่าทำไมถึงเลือกคำนั้น และมันก็ไม่ตรงกับการใช้คำว่า “vibe” แบบไหนที่ผมรู้จักเลย
    สงสัยว่า “gist” ยังเป็นคำฮิตไม่พอหรือเปล่า