Lesebibliothek
Die Entscheidung für oder gegen eine weitere Suchseite gestalten
Machen Sie eine weitere LocalLLaMA-Suchseite zur bewussten Wahl. Verbinden Sie offene Frage, Anfragekosten und Paginierungsgrenze, ohne den Wert ungesehener Antworten vorherzusagen.
Die offene Aufgabe benennen
Eine Schaltfläche für die nächste Seite lässt sich besser beurteilen, wenn der Leser die offene Frage benennen kann. In einer vorgeschlagenen Quantisierungssuche könnte es um eine Diskussion gehen, die die Bedingungen einer Speichermessung nennt. Fragen Sie nach der ersten Antwort, ob das verfügbare Material diese Bedingung behandelt. Die Antwort kann ja, nein oder wegen fehlenden Kontexts unklar sein. Das ist eine Leseentscheidung, keine Schlussfolgerung, die erste Seite enthalte die relevantesten Datensätze. Die API gibt keine solche Rangfolgezusage.
Lassen Sie Frage und kurze Notiz neben den geladenen Datensätzen sichtbar. Liefert die erste Seite bereits einen nützlichen Verweis, sollte der Leser ihn behalten und ohne weiteren Abruf gehen können. Andernfalls bewahren Sie die konkrete Unsicherheit, etwa „Hardware nicht angegeben“, statt bloß „mehr Ergebnisse nötig“. Das sind beispielhafte Oberflächenentscheidungen, keine beobachteten LocalLLaMA-Erkenntnisse. Automatisches Scrollen darf aus einer offenen Frage keine unbegrenzte Suche machen oder einen Verweis verdrängen, den der Leser noch prüft.
Eine weitere Anfrage abschätzen
Schätzen Sie konkrete Anfragekosten und Leseaufwand ab, nicht den Wert ungesehener Antworten. Der Wechsel von Seite 1 zu Seite 2 mit limit=3 fordert unter denselben Bedingungen bis zu drei weitere Datensätze an. Jeder erfolgreiche Abruf kostet einen Credit, auch bei leerer Antwort. Die reguläre Umrechnung beträgt $1 für 1000 bezahlte Credits; die Mindestaufladung von $50 ergibt 50000. Diese Kontofakten helfen beim Anfragebudget. Sie rechtfertigen nicht die Behauptung, eine bestimmte nächste Seite enthalte ein hilfreiches Experiment oder vielfältigere Ansichten.
Ihre Anwendung kann ein kleineres Lesebudget wählen als das Maximum des Dienstes. Erklären Sie es vor der nächsten Anfrage: eine weitere Seite, bis zu drei Datensätze, dieselben Filter. Schätzen Sie Relevanz weder aus der Vielfalt einer winzigen ersten Seite noch aus einer erfundenen Bewertungsverteilung. _doc-Reihenfolge erlaubt nicht die Annahme, nützliche Einträge kämen zuerst oder spätere Seiten verlören an Wert. Der Leser kann stattdessen einen Filter ändern oder aufhören. Das ist ehrlicher als eine Empfehlung auf Grundlage von Material, das die Anwendung nicht erhalten hat.
Grenzsignale prüfen
Prüfen Sie pagination.has_more vor dem Angebot einer weiteren Seite und halten Sie abgesendete Filter und limit beim Erhöhen von page konstant. Zulässig sind Seitenzahlen von 1 bis 100 und höchstens 100 Datensätze je Anfrage. Bei page=100 und limit=100 bietet eine volle letzte Seite keinen Platz für einen zusätzlichen Vorschau-Datensatz außerhalb des Fensters. pagination.window_exhausted kann deshalb zusammen mit has_more=false und einer unteren Grenze für die Gesamtzahl auftreten. Beenden Sie die Folge an dieser Grenze, ohne zu behaupten, alle passenden Archivdatensätze gelesen zu haben.
Zeigen Sie pagination.total zusammen mit pagination.relation. gte bedeutet, dass mindestens so viele Treffer angegeben werden, nicht ungefähr so viele; unknown kann mit null auftreten. Eine leere Seite nach der ersten kann eine unbekannte Gesamtzahl haben. Die Felder beschreiben die begrenzte Antwort, nicht die Vollständigkeit eines Themas. Wiederholte oder ähnliche Datensätze belegen auch nicht, dass spätere Seiten überflüssig sind. Entfernt Ihre lokale Liste Duplikate anhand tatsächlicher IDs, erklären Sie diese Entscheidung und bewahren Sie genügend Herkunftsdaten, um sie von den einzelnen Antworten zu unterscheiden.
Aufhören ermöglichen
Verwenden Sie eine ausdrückliche Aktion für die nächste Seite und machen Sie das Verlassen der aktuellen Seite einfach. Der Leser sollte einen nützlichen Verweis behalten, das Protokoll schließen oder zu den abgesendeten Bedingungen zurückkehren können, ohne weitere Aufrufe auszulösen. Verhindern Sie während einer Seitenanfrage wiederholte Aktivierungen derselben Aktion und halten Sie vorhandenen Text verfügbar. Bietet Ihre Anwendung „Stoppen“ an, sagen Sie genau, was endet: künftige automatische Anfragen oder das Warten in der Oberfläche. Bereits übermittelte Serverarbeit wird dadurch nicht garantiert abgebrochen oder kostenfrei.
Schlägt die nächste Anfrage fehl, trennen Sie bisherige Datensätze von der noch offenen Seitenzahl. Bieten Sie nur bei Bedarf eine bewusste Wiederholung an. Für Fehler der vorgelagerten Quelle gibt es eine Rückerstattungsbehandlung, gegebenenfalls mit ausstehendem Abgleich; bei einer unterwegs verlorenen Antwort bleibt der endgültige Abrechnungsstatus ungewiss. Springen Sie nicht still zur nächsten Seite und verbergen Sie den fehlgeschlagenen Versuch nicht. Ein guter Endzustand zeigt, was gelesen wurde, weshalb es weiterging oder endete und was offenbleibt. Das ist auch ohne vollständige Antwort ein vertretbarer Abschluss historischer Suche.
