Wie Redback eine Aufgabe bearbeitet

Was Redback ist, und was nicht

Die Prüfungen der Datenqualität finden Fehler: einen erfundenen und entfernten Wert, zwei Datensätze, die sich widersprechen, eine Schreibweise, die kein Vokabular kennt, einen Wert, den keine Seite belegt. Jeder Befund wird eine Aufgabe. Redback ist der Agent, der diese Aufgaben bearbeitet, und zwar vier Arten: 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).

Redback schreibt nie in den Katalog. Seine Arbeit endet in einem Vorschlag: ein Wert, die Seite, von der er stammt, die Worte auf dieser Seite, die ihn nennen, und die Begründung. Eine Person liest den Vorschlag und nimmt ihn an oder lehnt ihn ab, und nur ein angenommener Vorschlag kann einen Datensatz erreichen, über einen Pull Request, den eine Person zusammenführt. Eine Aufgabe, die Redback als erledigt schließt, bedeutet, dass ein Vorschlag abgelegt wurde, nie, dass sich der Datensatz geändert hat.

Der Weg eines Befunds

Das Diagramm verfolgt einen Befund. Was automatisch geschieht und was beurteilt wird, bleibt getrennt: Alles bis zum Vorschlag sind Code und Modelle, alles danach ist eine Person.

flowchart TD
  check["A quality check<br/>finds a fault"] --> task["A task in the queue"]
  task --> run["A run claims it,<br/>with its record's other tasks"]
  run --> research["Research: pages read,<br/>excerpts cut in code"]
  research --> read["A model reads the excerpts"]
  read --> held{"Held to the evidence"}
  held -->|"refused"| discarded["Discarded, with the reason"]:::fail
  held -->|"in doubt"| doubt["Filed, marked doubtful"]:::warn
  held -->|"passes"| filed["Filed as a proposal"]:::ok
  doubt --> review{"A person reviews"}
  filed --> review
  review -->|"accepted"| catalogue["Proposed to the catalogue<br/>and merged by a person"]:::ok
  review -->|"rejected"| task

Ein Lauf

Redback arbeitet in Läufen. Ein Lauf wird vom Zeitplan gestartet, von einer Person, die in der Staff-Konsole auf Ausführen drückt, oder von einer Aufgabe, deren Wartezeit abgelaufen ist. Er übernimmt einen Stapel Aufgaben in der Reihenfolge, die seine Zuweisung festlegt, und jede Übernahme ist bedingt, sodass zwei Läufe nie dieselbe Aufgabe bearbeiten.

Übernimmt ein Lauf eine Aufgabe zu einem Datensatz, nimmt er auch die übrigen offenen Aufgaben dieses Datensatzes (bis zu sechs) und bearbeitet sie als ein Dossier. Der Datensatz wird einmal gelesen: seine zitierten Seiten mit ihrem Rang, die Seite seines Herstellers, seine offenen Befunde und was eine Person zuletzt zu ihm bestätigt hat. Jede Seite und jede Suche des Laufs bleibt für den Rest des Laufs erhalten, sodass die für eine Länge gelesene Herstellerseite für ein Gewicht nicht erneut geladen wird. Jede Aufgabe erhält trotzdem ihre eigene Antwort und ihre eigene Prüfung, denn eine prüfende Person beurteilt einen Wert nach dem anderen.

Eine Aufgabe, die ein Anbieter nicht bedienen konnte (ein ausgelasteter Dienst, ruhende Schlüssel, ein aufgebrauchtes Kontingent), wird zurückgestellt statt fehlzuschlagen: Sie wird mit einem Zeitpunkt für den nächsten Versuch freigegeben, nach der Wartezeit des Anbieters oder einer sich verdoppelnden Wartezeit bis zu einer Stunde, und nach sechs Rückstellungen schlägt sie fehl. Eine Aufgabe, die so, wie sie erzeugt wurde, nicht bearbeitet werden kann, wird übersprungen; eine fehlerhafte Aufgabe hält nie die Warteschlange dahinter auf.

Recherche ist Code

Bei einer Lücke erledigt Code die Recherche, nicht ein Modell. Ein Modell mit Suchwerkzeug und dem Auftrag, einen Wert zu finden, plante nachweislich schlecht, suchte dreimal dasselbe und las ganze Seiten, die es nicht erfassen konnte; die Arbeitsteilung behebt jeden dieser Fehler.

1. Mit den eigenen zitierten Seiten des Datensatzes beginnen, stärkste Quelle zuerst: eine Herstellerseite vor einem Nachschlagewerk vor der Presse vor einem Shop.
2. Suchen, mit dem Namen des Datensatzes und dem Feld in Worten, zuerst auf der Website des Herstellers.
3. Die stärksten Ergebnisse lesen, bis zu sechs Seiten je Aufgabe, wobei ein Hersteller, eine Normungsstelle, eine Behörde oder ein Nachschlagewerk vor Presse, Shops und Foren kommt. Die Quellenangaben eines Nachschlagewerks werden bis zu den zitierten Seiten verfolgt.
4. Jede Seite auf die wenigen Ausschnitte kürzen, die das Feld nennen: Fenster um die Worte, die eine Seite dafür verwendet, mit einer Zahl darin, bis zu sechzehn Ausschnitte je Aufgabe. Jeder Ausschnitt ist ein Stück der Seite, nur mit zusammengefasstem Leerraum, sodass ein daraus kopiertes Zitat auf der Seite wiedergefunden werden kann.

Das Modell liest

Das Modell sieht den Datensatz (ohne den gesuchten Wert), den Befund der Prüfung und die Ausschnitte. Es wird nur eines gefragt: Welcher Ausschnitt nennt den Wert, mit welchen Worten, und wie lautet der Wert so, wie er dort steht. Es erhält keine Werkzeuge, es sucht nicht, und es rechnet keine Einheiten um; die Rechnung übernimmt Code.

Nur wenn die Recherche überhaupt nichts zu lesen fand, läuft ein Ersatzweg mit Werkzeugen, in dem ein Modell innerhalb eines festen Budgets von zwanzig Werkzeugaufrufen suchen und laden darf. Widersprüche werden von Anfang an so bearbeitet, denn um zu beurteilen, welcher von zwei Datensätzen falsch ist, muss man sich umsehen; eine Verifizierung liest nur die Herstellerseite, die der Code auswählt.

sequenceDiagram
  participant R as Research (code)
  participant S as Search chain
  participant P as Pages
  participant A as Reader model
  participant V as Second model
  participant G as Evidence rules
  R->>P: The record's own cited pages, strongest first
  R->>S: Queries, the maker's site first, off-topic results dropped
  R->>P: The strongest results
  R->>A: Excerpts only, cut around the field
  A-->>R: Excerpt, quote, stated value
  R->>V: Does this excerpt state it?
  V-->>R: yes, no or unsure
  R->>G: Source, quote, identity, bounds
  Note over R,G: a doubt goes to a stronger model,<br/>then to a person

Geprüft, bevor es abgelegt wird

Eine Lesart wird zuerst von Code festgehalten: Der genannte Ausschnitt muss einer der gezeigten sein, das Zitat muss auf der Seite stehen, so wie sie geladen wurde, und die Zahl, die das Modell gelesen haben will, muss im Zitat stehen. Ein echtes Zitat neben einer erfundenen Zahl bleibt eine erfundene Zahl.

Dann folgen drei unabhängige Prüfungen. Code sucht denselben Wert auf einer anderen gelesenen Website, was die Konfidenz erhöht und einen Beleg hinzufügt. Ein zweites Modell bei einem anderen Anbieter sieht den Ausschnitt und wird nur gefragt, ob er den Wert nennt: ja, nein oder unsicher. Und die Belegregeln (nächste Seite) entscheiden, ob der Wert überhaupt geschrieben werden darf.

Eine zweifelhafte Lesart geht an ein stärkeres Modell: ein Nein des zweiten Modells, ein Unsicher ohne Bestätigung, eine Konfidenz unter 0,6, eine von einer Versandkarton-Angabe gelesene Größe, eine verworfene oder nicht auswertbare Lesart. Das stärkere Modell liest dieselben Ausschnitte und antwortet unabhängig. Ein schlichtes Keiner nennt es wird nicht eskaliert; es ist die häufigste ehrliche Antwort, und sie zu eskalieren würde die Kosten der Ehrlichkeit verdoppeln.

Abgelegt für eine Person

Was abgelegt wird, trägt seinen Beleg: den Wert in der gespeicherten Einheit, die Worte, wie die Seite sie schrieb, das Zitat, jede Seite, die ihn nannte, die Konfidenz, was jede Prüfung sagte, und die vollständige Spur dessen, was gelesen und gefragt wurde. Ein zweifelhafter Wert wird mit seinem Zweifel an erster Stelle abgelegt, seine Konfidenz auf 0,3 begrenzt.

Eine Person prüft ihn in der Staff-Konsole. Ein angenommenes Ergebnis wird im nächsten Pull Request für den Katalog vorgeschlagen; ein abgelehntes bleibt erhalten, und die Ablehnung mit ihrer Notiz steht am Anfang der Frage an den nächsten Versuch, mit der Anweisung, dieselbe Antwort nicht erneut zu geben, es sei denn, sie beantwortet den Einwand.