Wie Redback seine Modelle und Werkzeuge wählt

Teilaufgaben, nicht ein Agent

Redback bearbeitet vier Arten von Aufgaben: eine Lücke (ein Wert ist zu finden), einen Widerspruch (ein Konflikt ist zu beurteilen), eine Verifizierung (ein Wert ist auf der Seite des Herstellers zu bestätigen) und eine Vokabular-Schreibweise (ein Wert ist einem bekannten Begriff zuzuordnen). Jede Art wird in Teilaufgaben zerlegt, und jede Teilaufgabe ist eine Anfrage an ein Modell mit einer Frage. Ein Modell plant nie eine Aufgabe: Code entscheidet, was in welcher Reihenfolge gelesen wird, und fragt ein Modell nur nach dem Teil, der Lesen oder Urteil verlangt.

Werkzeuge sind Funktionen, die ein Modell aufrufen darf, jede mit einer Beschreibung, nach der es wählt (die Staff-Konsole zeigt sie wörtlich), und jede gibt an, was sie erreicht: das Netz, unseren eigenen Katalog oder nichts außerhalb der Plattform. Werkzeuge erhalten nur ein Widerspruch und eine Lücke ohne Lesestoff. Ein Werkzeug lässt nie einen Lauf scheitern: Ein Fehler kommt als Satz zurück, mit dem das Modell arbeiten kann, sonst würde eine einzige tote Website einen Lauf beenden.

Die Werkzeuge: eine Websuche und die Suche auf einer Website; ein Seitenleser, ein PDF-Leser, eine Enzyklopädie-Suche und ein Artikelleser; eine Abfrage strukturierter Daten; drei Katalogleser (ein Datensatz, eine Suche, die Beziehungen eines Datensatzes); ein Einheitenumrechner; der Rang einer Quelle; und ein Notizblock.

Wie eine Teilaufgabe ihr Modell erhält

Jede Teilaufgabe bestimmt ihre Kette in fester Reihenfolge, und die Staff-Konsole zeigt, welcher Schritt entschieden hat. Zuerst eine Kette, die ein Betreiber dieser Teilaufgabe zugewiesen hat. Sonst jedes Modell im Pool, das mit der Fähigkeit markiert ist, die die Teilaufgabe angibt (Extraktion, Klassifikation, Schlussfolgern und so weiter), in der Pool-Reihenfolge des Betreibers. Sonst die eigene Standardkette der Teilaufgabe, und erst dann das eine Standardmodell der Plattform.

Die Reihenfolge ist immer die des Betreibers, nie abgeleitet. Anbieter melden ihre Grenzen unterschiedlich oder gar nicht, und eine Rangfolge nach scheinbarer Verfügbarkeit würde nach einer Zahl leiten, die wir erfunden haben. Ein Modell einmal für eine Fähigkeit zu markieren, konfiguriert jede Teilaufgabe, die sie angibt, auch später hinzugefügte.

Die Standardketten folgen drei Regeln. Kein Router, der je Aufruf ein Modell wählt, denn dann ist das Modell hinter einer Antwort nicht feststellbar. Kein kleines Modell, denn der Fehler, der zählt, ist eine plausible erfundene Zahl. Und die Glieder wechseln zwischen Anbietern und den Hosts dahinter, denn aufeinanderfolgende Glieder auf einem überlasteten Host scheitern gemeinsam.

Die Prüfung einer Lesart meidet den Anbieter, der sie erzeugt hat: Ihre Kette wird auf andere Anbieter gefiltert, und nur wenn keiner übrig bleibt, nutzt sie denselben. Ein Modell erkennt die Fehllesung eines anderen Modells besser als seine eigene.

flowchart TD
  job["A job inside a task"] --> assigned{"A chain assigned<br/>by an operator?"}
  assigned -->|"yes"| chain["The chain, in order"]
  assigned -->|"no"| tagged{"Models tagged for<br/>what the job needs?"}
  tagged -->|"yes"| chain
  tagged -->|"no"| own["The job's own default chain"]
  own --> chain
  chain --> hop["Next model"]
  hop --> key{"An available key for this<br/>model on its provider?"}
  key -->|"none"| hop
  key -->|"yes"| ask["Ask"]
  ask -->|"busy host or retired model"| hop
  ask -->|"timeout or unreadable"| stop["Stop the chain"]:::warn
  ask -->|"answer"| done["Answer, with its usage recorded"]:::ok

Wie ein Aufruf einen funktionierenden Schlüssel findet

Ein Modell wird zusammen mit seinem Anbieter genannt, denn dasselbe offene Modell wird von mehreren Anbietern mit verschiedenen Grenzen und verschiedenen Rechnungen angeboten. Jeder Anbieter hat einen Schlüsselring, versiegelt in der Staff-Konsole und nur von der Plattform geöffnet; kein Aufrufer hält je einen Schlüssel.

1. Schlüssel werden in der Reihenfolge ihrer letzten Nutzung versucht, der am längsten ungenutzte zuerst, damit sich fünf Schlüssel die Last teilen, statt dass einer arbeitet und vier warten.
2. Nur ein eigener Fehler des Schlüssels führt zum nächsten Schlüssel. Ein Ratenlimit lässt den Schlüssel ruhen, ein leeres Guthaben markiert ihn als verbraucht, und ein abgewiesener Schlüssel wird abgeschaltet. Eine Zeitüberschreitung oder eine unlesbare Antwort würde mit jedem Schlüssel gleich scheitern, sie ist also eine Antwort und kein Grund, vier weitere Anfragen auszugeben, um bei ihr anzukommen.
3. Ein Ratenlimit, das ein Modell nennt, sperrt nur dieses Modell auf diesem Schlüssel, bis zu dem Zeitpunkt, den der Anbieter nennt; ein Tageslimit lässt den ganzen Schlüssel ruhen. Sind alle Schlüssel gesperrt, meldet der Aufruf die Wartezeit, und die Aufgabe wird bis dahin zurückgestellt statt fehlzuschlagen.
4. Ein Anbieter ohne nutzbaren Schlüssel wird für den nächsten in der Kette übersprungen. Ein ausgelasteter Host oder ein zurückgezogenes Modell führt zum nächsten Glied. Eine Zeitüberschreitung oder eine unlesbare Antwort beendet die Kette, denn das nächste Modell bekäme dasselbe geschickt.
5. Die Nutzung wird je Anbieter gezählt und einmal je Antwort reserviert, nicht je Versuch: Ein abgewiesener Schlüssel hat nichts verbraucht, und ein Anbieter, der seine Grenze erreicht, sperrt nie die Anbieter hinter ihm in der Kette.

Jeder Aufruf wird mit Anbieter, Schlüssel, Modell, Tokens, Kosten, Dauer und Ergebnis protokolliert, und jeder Schritt in der Spur einer Aufgabe nennt Anbieter und Modell, die ihn beantwortet haben, sodass sich ein Wert immer bis zu dem Modell zurückverfolgen lässt, das ihn gelesen hat.

Die Suchkette

Die Suche läuft über eine eigene Kette von Anbietern, in einer Reihenfolge, die der Betreiber festlegt, mit Schlüsselringen nach denselben Regeln wie bei den Modellen.

Das Kontingent jedes Anbieters wird so gelesen, wie der Anbieter es veröffentlicht. Gehört das Kontingent zu jedem Schlüssel, werden die Schlüssel nacheinander verbraucht. Gehört es zum Konto, wird nur der erste Schlüssel gesendet, denn ein zweiter Schlüssel desselben Kontos kauft nichts dazu. Ein Schlüssel, der auf ein Ratenlimit trifft oder kein Guthaben mehr hat, ruht, und der nächste wird versucht; ein abgewiesener Schlüssel wird abgeschaltet.

Ein Anbieter ohne nutzbaren Schlüssel gibt die Anfrage weiter. Eine Antwort über etwas anderes (Ergebnisse, die die prägenden Worte der Anfrage nie nennen) gibt sie ebenfalls weiter und wird aufbewahrt, falls nichts Besseres kommt. Keine Suche wird verweigert, um Kontingent zu sparen.

flowchart LR
  query["A query"] --> memory{"Asked today<br/>already?"}
  memory -->|"yes"| cached["The saved answer, no new request"]:::ok
  memory -->|"no"| provider["Next provider in the chain"]
  provider --> ring{"A key with allowance<br/>left and not resting?"}
  ring -->|"none"| provider
  ring -->|"yes"| ask["Ask, paced"]
  ask --> fault{"The key's own fault?"}
  fault -->|"rate limit or no credit"| rest["Rest that key"]:::warn
  rest --> ring
  fault -->|"answered"| topic{"On topic?"}
  topic -->|"no"| provider
  topic -->|"yes"| hits["Results, and the spend recorded"]:::ok

Was behalten wird, und wie lange

Jede Suche und jede Seite, die Redback lädt, wird so lange behalten, dass sie wiederverwendet werden kann, und nicht länger. Eine behaltene Kopie erspart nur eine Wiederholung: Sie wird nie allein zum Beleg, und was fehlschlug, wird nie behalten.

Eine behaltene Seite kann kein Zitat erzeugen, das nie da war: Das Zitat wird gegen den Text geprüft, den dieser Lauf erhalten hat, eine behaltene Seite wird also gegen sich selbst geprüft, und der Vorschlag trägt die Adresse, von der sie gelesen wurde, damit eine Person sie öffnen kann.

Eine Seite lesen

Eine Seite wird höflich geladen: Die Robots-Regeln ihrer Website werden beachtet, Anfragen an eine Website werden verteilt, und was extrahiert wurde, bleibt einen Tag erhalten. Der Leser trennt, was eine Seite in ihren eigenen Tabellen und strukturierten Daten angibt, von ihrem Fließtext, und nennt die Angaben zuerst. Eine Tabelle mit Kopfzeile wird Zeile für Zeile mit den Beschriftungen dieser Zeile gelesen, sodass der Lauf aus einer Datentabelle das Kaliber behält, zu dem er gehört; eine Tabelle ohne Kopfzeile bleibt unberührt, denn einen Vergleich zu verflachen erfindet Beziehungen.

PDFs werden als PDFs gelesen, bis zwölf Megabyte; ein gescanntes PDF ohne Text wird gemeldet, nie erraten. Seiten, die nur im Browser aufgebaut werden, und Prüfwände kann Redback nicht lesen: Eine Prüfwand wird erkannt und nie umgangen, und solche Websites werden im Gedächtnis markiert (Was Redback lernt), damit die Recherche stattdessen nach einem PDF des Herstellers oder einer archivierten Kopie sucht.

Reading a PDF

Makers publish their specifications as PDFs more often than as pages: spec sheets, owner's manuals, datasheets and product catalogues. Redback reads them as documents, in our own Worker, rather than as a page, because a PDF read as a page comes back as noise that a model would treat as read.

The hard part is the tables. A PDF has no table in it, only words placed at points on a page, so reading it in the order the file stores them runs a table's labels into one line and its figures into another, and which figure belongs to which label is lost. Redback rebuilds the table from where each word sits instead.

1. Words on one baseline become a line, and a wide gap within a line starts a new column.
2. A run of label lines above a line of figures is read as the table's header.
3. Each figure is placed under the label whose column it sits in, and the row is written out as a fact: "Barrel length: 4.7 in, Weight: 710 g", the same shape a table on a web page gives.
4. This is done on every page of the document, not only the first few, because a catalogue's specification table is often forty pages in. The document's prose is read separately, in order, so a two-column paragraph still reads the way it was written.

A figure Redback takes from a PDF is held to the same rule as one from a page: it must be quoted, and before it can reach a record the quote is checked again against the document, read the same way. A quote taken from a rebuilt table is checked against that table, so the figure and its label have to agree a second time.

Nachschlagewerke

Ein Enzyklopädie-Artikel ist ein Hinweis, nie ein Zitat. Seine Infobox wird als Felder gelesen, gruppiert wie im Artikel, und seine Quellenangaben werden nach der Quellenhierarchie geordnet und bis zu den zitierten Seiten verfolgt. Eine Abfrage strukturierter Daten liefert eine zweite Meinung auf dieselbe Weise: einen Hinweis auf eine Seite, keinen Wert.

Der Katalog selbst

Ein Widerspruch ist ein Konflikt zwischen zwei Datensätzen, und eine Aufgabe trägt einen davon; um zu beurteilen, ob eine Waffe älter ist als ihr Hersteller, braucht man den Hersteller. Die Katalogwerkzeuge lesen einen Datensatz, durchsuchen den Katalog und folgen den Beziehungen eines Datensatzes, jeweils gegen eine Positivliste, denn ein Tabellenname kann kein gebundener Parameter sein. Der Rang einer Quelle nennt einem Modell Art, Rang und Zitierhäufigkeit einer Website sowie, wie sie sich für ein Skript lesen lässt, bevor es sie zitiert.

Der Notizblock

Ein Modell im Werkzeugweg hat einen Notizblock mit zwölf Notizen zu je 240 Zeichen, der in jeder Runde von außerhalb des Gesprächs erneut gezeigt wird, sodass das Kürzen des Verlaufs keine Schlussfolgerung entfernen kann. Er ist für das Ausgeschlossene gedacht: Der gemessene Fehler waren drei fast gleiche Suchen, weil nichts festhielt, dass die ersten beiden nichts gefunden hatten. Eine Notiz ist kein Beleg; ein Wert in einer Notiz hat keine Quelle.