Aufbau einer Open-Source-verteilten Suchmaschine für E-Books

 (github.com/j2qk3b)
1 Punkte von GN⁺ 2024-03-12 | 1 Kommentare | Auf WhatsApp teilen

Aufbau einer Open-Source-verteilten Suchmaschine für E-Books

  • Durch die Empfehlung eines Freundes wurde ich auf eine E-Book-Suchwebsite namens Liber3 aufmerksam, die ENS-Domainnamen verwendet.
  • Liber3 hat mit ENS und IPFS eine E-Book-Suchwebsite erstellt, den Quellcode jedoch nicht veröffentlicht.
  • Nach der Prüfung der Dokumentation und Datensätze von Glitter fiel die Entscheidung, selbst eine Open-Source-Community-Version zu implementieren.

Projektinitialisierung

  • Erstellen Sie ein neues Projekt und installieren Sie das Glitter SDK, um sich einfach mit dem Glitter-Netzwerk zu verbinden und Metadaten von E-Books abzurufen.

Netzwerkverbindung

  • Erstellen Sie einen Client, der mit dem Glitter-Netzwerk interagieren kann.
  • Initialisieren Sie über das Glitter SDK eine LCDClient-Instanz und setzen Sie die relevanten Parameter.

Aufbau der Suchfunktion

  • Definieren Sie eine Suchfunktion, die die Suchbegriffe des Nutzers entgegennimmt, eine Query erstellt und sie an das Glitter-Netzwerk sendet.

Anzeige der Suchergebnisse

  • Nach dem Aufbau der Suchfunktion wird eine Oberfläche gestaltet, die grundlegende Informationen zu den E-Books anzeigt und interaktive Elemente bietet, damit Nutzer Bücher leicht durchsuchen und auswählen können.
  • Mit diesen vier Schritten lässt sich eine E-Book-Suchmaschine aufbauen, die den Nutzern eine effiziente und komfortable Plattform zum Durchsuchen von E-Book-Ressourcen bietet.
  • Wenn die kompilierte Website-Version im IPFS-Netzwerk veröffentlicht wird, entsteht eine verteilte E-Book-Suchmaschine, die über ein IPFS-Gateway zugänglich ist.
  • Der vollständige Quellcode ist in diesem Repository verfügbar.

Meinung von GN⁺

  • Dieser Artikel kann für technikinteressierte Menschen spannend sein, da er erklärt, wie sich mit Open Source und verteilten Technologien eine E-Book-Suchmaschine aufbauen lässt.
  • Der Einsatz verteilter Datenbanken und von IPFS zeigt einen neuen Weg, Daten zu speichern und abzurufen, ohne auf zentrale Server angewiesen zu sein, und hat damit das Potenzial, Persistenz und Zugänglichkeit von Daten zu verbessern.
  • Bei der Einführung dieser Technologie sollten Netzwerkstabilität, Suchgeschwindigkeit und User Experience berücksichtigt werden; außerdem ist es wichtig, die Vor- und Nachteile im Vergleich zu bestehenden zentralisierten Suchmaschinen zu verstehen.
  • Andere Projekte mit ähnlichen Funktionen sind etwa Project Gutenberg oder die Google Books API, diese nutzen jedoch keine verteilten Technologien.
  • Durch den Einsatz verteilter Technologien können Eigentum und Kontrolle über Daten an die Nutzer zurückgegeben und zugleich die Zensurresistenz von Inhalten gestärkt werden.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-12
Hacker-News-Kommentare

  • Vor langer Zeit wollte ich AI-Datensätze und -Modelle auf IPFS auf ähnliche Weise behandeln.
    Ich weiß nicht, wie die Zukunft von IPFS aussieht, aber ich fände es gut, wenn der Kern einer P2P-Infrastruktur zum Teilen von Daten, die es Einzelpersonen ermöglicht, Probleme mit wenig Hardware zu lösen, wenn sie mit großen Datensätzen arbeiten, leichter zugänglich würde.
    https://github.com/JakeKalstad/IPFSPytorchDataset
    https://github.com/JakeKalstad/load_ipfs_pytorch_model

  • Beim Titel dachte ich, es ginge um Volltextsuche, und war wirklich gespannt.
    Zlib und Google Books machen das zwar schon, aber eine Open-Source-Version, zu der alle beitragen können und die auch Volltextzugriff bietet, wäre ein großartiges Projekt.

  • Wenn man nur nach Buchtiteln oder Autoren sucht, gibt es bereits jede Menge Suchmaschinen.
    Was fehlt, ist ein Suchindex für den Inhalt von E-Books, und im Zeitalter generativer AI wird das bald enorm wichtig werden.
    Jemand auf HN meinte, man könne den Volltext von Millionen Büchern auf einem einzigen Laptop indexieren, während andere sagen, der Umfang sei praktisch unmöglich. Ich frage mich, ob es ein Projekt gibt, das das macht.

    • Ich arbeite an einem Nebenprojekt, das Sammlungen von E-Book-Highlights per semantischer Suche auf dem Gerät organisiert.
      Derzeit indexiert es nur die eigenen Inhalte, aber später möchte ich einen Modus hinzufügen, in dem man Sammlungen teilen kann, sodass andere per semantischer Suche verwandte Ideen entdecken können, die Menschen in Büchern gefunden haben. Wie es aktuell funktioniert, kann man im Open Source sehen.
      [1] https://emdash.ai/
      [2] https://github.com/dmotz/emdash
    • Die Größe des Index hängt viel stärker vom Suchtext ab als von der Anzahl der durchsuchten Objekte.
      Ich erinnere mich, dass Google in seiner Anfangszeit so etwas dokumentiert hatte: Ein Suchindex gibt relevante Metadaten zurück, die zu einer bestimmten Anfrage passen. Der Suchraum basiert hauptsächlich auf rohen Keywords und Tupeln sowie, wenn ich mich richtig erinnere, auf 2- bis 3-Wort-n-Grammen; Letztere müssen eine Mindesthäufigkeit erfüllen. Längere Suchbegriffe lassen sich aus kürzeren n-Grammen zusammensetzen.
      Der fortgeschrittene Wortschatz englischer Muttersprachler umfasst normalerweise etwa 40.000 Wörter, und selbst ein großes Wörterbuch einschließlich veralteter Wörter kann unter 250.000 Wörtern bleiben.
      Wörter auf Werke abzubilden, die sie zitieren, ist relativ einfach. Bei n-Grammen gibt es zwar eine kombinatorische Explosion, aber der Raum ist trotzdem recht begrenzt, und wir haben inzwischen mehr als 25 Jahre Erfahrung damit, Dokumente im Web-Maßstab zu indexieren.
      Ein Laptop dürfte für Millionen Bücher vermutlich zumindest einen brauchbaren Index erstellen können, aber für einen umfassenderen Index, insbesondere einen Ranking-Index des Suchraums, braucht man wahrscheinlich ein etwas größeres System. Das ist vermutlich die größere Herausforderung.
    • Es hängt davon ab, wie leistungsfähig dieser Laptop ist.
      Ich habe mich bei der Arbeit zuletzt mit lokalen LLMs beschäftigt, und obwohl Quantisierung heutzutage große Fortschritte gemacht hat, ist diese Art von Arbeit auf einem ThinkPad zwar möglich, aber immer noch deutlich schlechter, als für ein paar Stunden einen VPS mit ein paar 4090/H100 zu mieten.
      Das größte Problem bei Zusammenfassungen ist, dass die meisten lokalen LLM-Modelle kein besonders großes Kontextfenster haben und sich selbst mit großen Texten wie einer kurzen Vonnegut-Novelle schwertun. Ich habe es mit Zusammenfassungen von GitHub-Issues getestet, und selbst bei einem Kontextfenster von 16k Tokens wird es manchmal schwierig, wenn es viele Kommentare gibt.
      Natürlich könnte jemand, der klüger ist als ich, es vielleicht sogar auf einem Raspberry Pi zum Laufen bringen.
    • Soweit ich weiß, unterstützt das beliebte und kostenlose E-Book-Verwaltungstool Calibre inzwischen die Volltextindexierung aller Bücher, die man besitzt.
    • Die erstmalige Erstellung des Index könnte mit einem durchschnittlichen Laptop möglich sein, aber den Index häufig zu aktualisieren und Anfragen zu bedienen dürfte rechnerisch ziemlich aufwendig sein.
      Das ist unbelegt und nur eine Vermutung; ich würde gern mehr darüber wissen.

  • Kannst du genauer erklären, wie der Suchindex befüllt wird und wo die erwarteten Speichergrenzen liegen?

  • Cool. Könnte man das auch für die Torrent-Suche nutzen?
    Also zusammen mit Web-Torrents, die Videostreaming ermöglichen, und einer dezentralen Suchmaschine.

  • Ich frage mich, ob das tatsächlich eine Suchmaschine ist oder nur ein Frontend, das select from-Abfragen erzeugt.

  • Ich habe keine Ahnung, wovon hier überhaupt die Rede ist.
    Da stehen Sätze wie: „Mir wurde Liber3 empfohlen, es verwendet ENS-Domainnamen, läuft auf ENS und IPFS, scheint Glitter zu nutzen und ist ein mit Tendermint gebauter Dienst“ — das klingt für mich wie ein außerirdisches Signal in der Sprache einer anderen Galaxie.
    Ich habe auch dieses Liber3 ausprobiert, aber egal was ich mache, es kommt nur „Oops! Something went wrong. Please refresh or try again later“. Worum geht es hier überhaupt?

    • ENS ist der Ethereum Name Service, im Grunde DNS für die Blockchain.
      IPFS ist das InterPlanetary File System, eher ein verteilter Objektspeicher wie ein unveränderliches P2P-S3.
      Glitter kommt mir bekannt vor, aber ich kann es gerade nicht einordnen.
      Tendermint ist eine Konsens-Engine für Blockchains und Teil einer Toolchain, die zusammen mit dem Inter-Blockchain Communication (IBC) Protocol und dem Cosmos SDK Interoperabilität zwischen Blockchains ermöglichen soll.
      Das Blockchain-Ökosystem ist wirklich eine kleine Welt für sich. Nicht unbedingt exklusiv, aber ziemlich in sich geschlossen, sodass man kaum damit in Berührung kommt, wenn man nicht aktiv danach sucht.
      Nebenbei: IPFS ist einen Blick wert, wenn man sich für Datenbanken oder dezentrale trustless Systeme interessiert, selbst wenn man Blockchain-Skeptiker ist. Intern passiert dort ziemlich interessante Arbeit, und das Team ist nicht auf die Goldrausch-Stimmung aufgesprungen wie fast alle Blockchain-Projekte.
    • Der Titel ist die entjargonisierte Version.
      Man kann es als Implementierungsanleitung zum Bau einer Open-Source-E-Book-Suchmaschine sehen. Natürlich bleibt auch in dieser Beschreibung etwas Fachjargon übrig, aber es ist nicht nur eine Aneinanderreihung bestimmter Bibliotheksnamen.
      Der Großteil des Beitrags besteht aus Implementierungsdetails, die freundlicherweise verlinkt sind.

  • Und dann merkt man, dass es das seit fast 15 Jahren gibt und es libgen.rs hieß.

    • Anna's Archive ist besser.