การสร้างเสิร์ชเอนจินค้นหาอีบุ๊กแบบกระจายศูนย์โอเพนซอร์ส

 (github.com/j2qk3b)
1 คะแนน โดย GN⁺ 2024-03-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การสร้างเสิร์ชเอนจินค้นหาอีบุ๊กแบบกระจายศูนย์โอเพนซอร์ส

  • ได้รู้จักเว็บไซต์ค้นหาอีบุ๊กชื่อ Liber3 ที่ใช้ชื่อโดเมน ENS จากคำแนะนำของเพื่อน
  • Liber3 สร้างเว็บไซต์ค้นหาอีบุ๊กโดยใช้ ENS และ IPFS แต่ไม่ได้เปิดเผยซอร์สโค้ด
  • หลังจากตรวจสอบเอกสารและชุดข้อมูลของ Glitter แล้ว จึงตัดสินใจลงมือสร้างเวอร์ชันชุมชนโอเพนซอร์สขึ้นเอง

การเริ่มต้นโปรเจกต์

  • สร้างโปรเจกต์ใหม่และติดตั้ง Glitter SDK เพื่อให้เชื่อมต่อกับเครือข่าย Glitter และดึงเมทาดาทาของอีบุ๊กได้ง่าย

การเชื่อมต่อเครือข่าย

  • สร้างไคลเอนต์ที่สามารถโต้ตอบกับเครือข่าย Glitter ได้
  • เริ่มต้นอินสแตนซ์ LCDClient ผ่าน Glitter SDK และตั้งค่าพารามิเตอร์ที่เกี่ยวข้อง

การสร้างฟังก์ชันค้นหา

  • กำหนดฟังก์ชันค้นหาที่รับคีย์เวิร์ดจากคำค้นของผู้ใช้ สร้างข้อความคำค้น และส่งไปยังเครือข่าย Glitter

การแสดงผลลัพธ์การค้นหา

  • หลังจากสร้างฟังก์ชันค้นหาแล้ว ได้ออกแบบอินเทอร์เฟซที่แสดงข้อมูลพื้นฐานของอีบุ๊ก และมีองค์ประกอบแบบอินเทอร์แอกทีฟเพื่อให้ผู้ใช้เรียกดูและเลือกหนังสือได้ง่าย
  • ผ่าน 4 ขั้นตอนนี้ ก็สามารถสร้างเสิร์ชเอนจินค้นหาอีบุ๊กได้ และมอบแพลตฟอร์มที่มีประสิทธิภาพและสะดวกสำหรับการค้นหาทรัพยากรอีบุ๊กแก่ผู้ใช้
  • หากนำเว็บไซต์เวอร์ชันที่คอมไพล์แล้วไปเผยแพร่บนเครือข่าย IPFS ก็จะได้เสิร์ชเอนจินค้นหาอีบุ๊กแบบกระจายศูนย์ที่เข้าถึงได้ผ่าน IPFS gateway
  • สามารถดูซอร์สโค้ดทั้งหมดได้จากรีโพซิทอรีนี้

ความเห็นของ GN⁺

  • บทความนี้อธิบายวิธีสร้างเสิร์ชเอนจินค้นหาอีบุ๊กด้วยการใช้โอเพนซอร์สและเทคโนโลยีแบบกระจายศูนย์ จึงอาจดึงดูดความสนใจของผู้ที่สนใจเทคโนโลยีได้
  • การใช้ฐานข้อมูลแบบกระจายศูนย์และ IPFS นำเสนอแนวทางใหม่ในการจัดเก็บและค้นคืนข้อมูลโดยไม่ต้องพึ่งพาเซิร์ฟเวอร์ศูนย์กลาง จึงมีศักยภาพในการเพิ่มความคงทนและการเข้าถึงของข้อมูล
  • เมื่อนำเทคโนโลยีนี้มาใช้ ควรคำนึงถึงความเสถียรของเครือข่าย ความเร็วในการค้นหา และประสบการณ์ผู้ใช้ รวมถึงควรเข้าใจข้อดีข้อเสียเมื่อเทียบกับเสิร์ชเอนจินแบบรวมศูนย์เดิม
  • โปรเจกต์อื่นที่มีฟังก์ชันคล้ายกัน ได้แก่ Project Gutenberg หรือ Google Books API แต่สิ่งเหล่านี้ไม่ได้ใช้เทคโนโลยีแบบกระจายศูนย์
  • การใช้เทคโนโลยีแบบกระจายศูนย์ช่วยคืนความเป็นเจ้าของและการควบคุมข้อมูลให้ผู้ใช้ พร้อมทั้งเสริมความต้านทานต่อการเซ็นเซอร์ของเนื้อหา

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

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

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

  • นานมาแล้วเคยอยากลองทำอะไรคล้าย ๆ กันกับ ชุดข้อมูลและโมเดล AI บน IPFS
    ไม่รู้ว่าอนาคตของ IPFS จะเป็นอย่างไร แต่เมื่อจัดการกับชุดข้อมูลขนาดใหญ่ ก็อยากให้แก่นของ โครงสร้างพื้นฐานการแชร์ข้อมูลแบบ P2P ที่ช่วยให้คนทั่วไปแก้ปัญหาได้แม้มีฮาร์ดแวร์ไม่มาก เข้าถึงได้ง่ายขึ้น
    https://github.com/JakeKalstad/IPFSPytorchDataset
    https://github.com/JakeKalstad/load_ipfs_pytorch_model

  • เห็นหัวข้อแล้วนึกว่าจะเป็น การค้นหาแบบ full-text เลยคาดหวังมาก
    Zlib กับ Google Books ทำอยู่แล้วก็จริง แต่ถ้ามี เวอร์ชันโอเพนซอร์ส ที่ทุกคนร่วม योगदानได้และให้เข้าถึงการค้นหา full-text ได้ด้วย น่าจะเป็นโปรเจกต์ที่ยอดเยี่ยม

    • OpenLibrary ให้เข้าถึงการค้นหา full-text ได้
      ตัวอย่าง: https://openlibrary.org/search/inside?q=%22institutional+thi...
      เป็นโอเพนซอร์สและมองหาผู้ร่วม योगदानอยู่เสมอ โดยเฉพาะน่าจะยินดีมากถ้ามีคนช่วยปรับปรุงการค้นหา
      https://github.com/internetarchive/openlibrary/
    • ผมคิดว่าจำเป็นต้องมี โปรเจกต์ OCR แบบกระจายศูนย์
      ปัญหาคือหนังสือจำนวนมากเป็นไฟล์สแกน PDF จึงไม่มีข้อความต้นฉบับ และแม้ OcrMyPdf จะจัดการได้ค่อนข้างดี แต่ใช้ CPU มาก

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

    • กำลังทำ side project สำหรับจัดระเบียบคอลเลกชันไฮไลต์จากอีบุ๊กด้วย semantic search บนอุปกรณ์
      ตอนนี้ทำดัชนีเฉพาะคอนเทนต์ของตัวเอง แต่ภายหลังอยากเพิ่มโหมดแชร์คอลเลกชัน เพื่อให้คนอื่นค้นพบไอเดียที่เกี่ยวข้องจากหนังสือที่ผู้อื่นเจอได้ด้วย semantic search วิธีทำงานปัจจุบันดูได้ในโอเพนซอร์ส
      [1] https://emdash.ai/
      [2] https://github.com/dmotz/emdash
    • ขนาดของดัชนีขึ้นกับ ข้อความที่ใช้ค้นหา มากกว่าจำนวนรายการที่ค้นหาอย่างมาก
      จำได้ว่า Google เคยทำเอกสารเรื่องนี้ไว้ในยุคแรก ๆ โดยดัชนีค้นหาจะคืนเมทาดาทาที่เกี่ยวข้องซึ่งตรงกับคำค้นหนึ่ง ๆ พื้นที่ของคำค้นส่วนใหญ่อิงจากคีย์เวิร์ดดิบและ tuple และถ้าจำไม่ผิดคือ n-gram 2–3 คำ โดยอย่างหลังต้องผ่านเงื่อนไขความถี่ขั้นต่ำ คำค้นยาว ๆ สามารถประกอบขึ้นจาก n-gram ที่สั้นกว่าได้
      คำศัพท์ของเจ้าของภาษาอังกฤษระดับสูงมักอยู่ราว 40,000 คำ และแม้พจนานุกรมขนาดใหญ่ที่รวมคำเก่า ๆ ก็อาจมีน้อยกว่า 250,000 คำ
      การแมปคำศัพท์ไปยังงานเขียนที่อ้างถึงคำนั้นค่อนข้างตรงไปตรงมา ส่วน n-gram มีการระเบิดเชิงผสม แต่ก็ยังเป็นพื้นที่ที่ค่อนข้างจำกัด และเราก็มีประสบการณ์ทำดัชนีเอกสารระดับเว็บมานานกว่า 25 ปีแล้ว
      แล็ปท็อปก็น่าจะพอสร้างดัชนีที่ใช้งานได้สำหรับหนังสือหลายล้านเล่มในระดับหนึ่ง แต่ถ้าต้องการดัชนีที่ครอบคลุมกว่านั้น โดยเฉพาะ ดัชนีการจัดอันดับ ของพื้นที่ค้นหา อาจต้องใช้ระบบที่ใหญ่กว่านี้มาก นั่นน่าจะเป็นโจทย์ที่ยากกว่า
    • ขึ้นอยู่กับว่าแล็ปท็อปเครื่องนั้นแรงแค่ไหน
      งานล่าสุดของผมเกี่ยวกับ LLM ที่รันในเครื่อง และแม้ทุกวันนี้ quantization จะพัฒนาไปมาก งานแบบนี้บน ThinkPad ก็พอทำได้ แต่ก็ยังด้อยกว่าการเช่า VPS ที่มี 4090/H100 หลายใบสักไม่กี่ชั่วโมงมาก
      ปัญหาใหญ่ที่สุดในการสรุปคือโมเดล LLM ที่รันในเครื่องส่วนใหญ่มี context window ไม่ใหญ่มาก จึงลำบากแม้กับข้อความขนาดใหญ่อย่างนิยายสั้นของ Vonnegut ผมทดสอบกับการสรุป GitHub issue แล้ว แม้ context window 16k token ก็ยังมีสะดุดบ้างถ้าคอมเมนต์เยอะ
      แน่นอน คนที่ฉลาดกว่าผมอาจทำให้มันรันบน Raspberry Pi ได้ก็ได้
    • เท่าที่ทราบ เครื่องมือจัดการอีบุ๊กยอดนิยมและฟรีอย่าง Calibre ตอนนี้รองรับการทำดัชนี full-text ของหนังสือทั้งหมดที่มีแล้ว
    • การสร้างดัชนีครั้งแรกอาจทำได้ด้วยแล็ปท็อประดับทั่วไป แต่การอัปเดตดัชนีบ่อย ๆ และการรองรับคำขอน่าจะใช้การคำนวณค่อนข้างมาก
      ไม่มีหลักฐาน เป็นแค่การเดา เลยอยากรู้เพิ่มเติม

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

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

    • ได้ ลองใช้อันนี้ดู: https://anybt.eth.limo/
      ตั้งใจจะทำเวอร์ชันโอเพนซอร์สด้วย
    • https://news.ycombinator.com/item?id=39815170
      มีเวอร์ชันโอเพนซอร์สสำหรับค้นหา torrent ที่ใช้เทคโนโลยีเดียวกันอยู่ตรงนี้

  • สงสัยว่านี่เป็น เสิร์ชเอนจิน จริง ๆ หรือเป็นแค่ฟรอนต์เอนด์ที่สร้าง query แบบ select from ให้เท่านั้น

  • ไม่เข้าใจเลยว่านี่กำลังพูดเรื่องอะไร
    มีประโยคทำนองว่า “มีคนแนะนำ Liber3 มา ใช้ชื่อโดเมน ENS ทำงานบน ENS กับ IPFS ดูเหมือนใช้ Glitter และเป็นบริการที่สร้างด้วย Tendermint” ฟังเหมือนสัญญาณจากเอเลี่ยนที่พูดภาษาจากอีกกาแล็กซี
    ลอง Liber3 แล้ว แต่ทำอะไรก็ขึ้นแค่ “Oops! Something went wrong. Please refresh or try again later” ทั้งหมดนี้กำลังพูดถึงอะไรกันแน่?

    • ENS คือ Ethereum Name Service มองว่าเป็น DNS สำหรับบล็อกเชนก็ได้
      IPFS คือ InterPlanetary File System คล้าย ที่เก็บอ็อบเจ็กต์แบบกระจายศูนย์ ที่ไม่เปลี่ยนรูปและเป็น P2P เหมือน S3
      Glitter ฟังดูคุ้น ๆ แต่ผมนึกไม่ออกทันที
      Tendermint คือเอนจินฉันทามติสำหรับบล็อกเชน และเป็นส่วนหนึ่งของชุดเครื่องมือร่วมกับ Inter-Blockchain Communication(IBC) Protocol และ Cosmos SDK ที่พยายามทำให้บล็อกเชนต่าง ๆ ทำงานร่วมกันได้
      ระบบนิเวศบล็อกเชนนี่เป็นโลกเล็ก ๆ ของมันเองจริง ๆ ไม่ได้หมายความว่ากีดกัน แต่ค่อนข้างเป็นวงใน ถ้าไม่ตั้งใจไปค้นหาก็แทบไม่มีโอกาสได้เจอ
      เสริมว่า IPFS คุ้มค่าที่จะลองดูถ้าสนใจฐานข้อมูลหรือ ระบบไร้ศูนย์กลางแบบไม่ต้องอาศัยความไว้วางใจ แม้จะเป็นคนกังขาบล็อกเชนก็ตาม ข้างในมีงานที่น่าสนใจไม่น้อย และทีมก็ไม่ได้โหนกระแสตื่นทองเหมือนโปรเจกต์บล็อกเชนแทบทั้งหมด
    • หัวข้อคือเวอร์ชันที่ตัดศัพท์เฉพาะออกแล้ว
      มองได้ว่าเป็น คู่มือการนำไปใช้งานจริง เพื่อสร้างเสิร์ชเอนจินอีบุ๊กแบบโอเพนซอร์ส แน่นอนว่าคำอธิบายนั้นก็ยังมีศัพท์เฉพาะอยู่บ้าง แต่ไม่ถึงขั้นไล่รายชื่อไลบรารีเฉพาะเป็นชุด ๆ
      เนื้อหาส่วนใหญ่ของบทความคือรายละเอียดการนำไปใช้งานจริง และมีลิงก์ให้อย่างเป็นมิตร

  • แล้วก็รู้ตัวว่ามันมีอยู่มาเกือบ 15 ปีแล้ว และชื่อว่า libgen.rs

    • Anna's Archive ดีกว่า