Tool (Prototyp) zum Qualitätsmanagement automatischer Erschließung (Textmining) im Archiv, das auf Basis menschlicher Bewertungen unter Verwendung eines festzulegenden Fallprofils einen Prozentwert ("Recherchegüte") berechnet.
Achtung: Prüfstelle ist eine Alpha-Version.
 Fall ansehen |
 Recherchegüte wird abhängig vom Fallprofil berechnet |
 Visualisierung der Verteilung aller Bewertungen über einen Fall |
 Es wird möglichst wenig vorausgesetzt. Wo etwas vielleicht mal nicht klar ist, gibt's Hilfstexte. |
 Durchgängig modellierte/spezifizierte API (OpenAPI 3) |
 Neuen Fall anlegen |
Vorab: Repo klonen oder herunterladen
cd /pruefstelle/docker/docker-compose builddocker-compose up
Die genutzte Konfiguration kann über environment im docker-compose.yml angepasst werden.
Allerdings gilt das nur für das Backend, da die envvars während der Buildzeit des Frontends vorhanden sein müssen.
Daher ist die .env-Datei aus examples/ in frontend/ erforderlich -- Anpassungen sind dort möglich.
cdins Repocd pruefstelle/frontend/- Dort
.env-Datei nach dem Beispiel inpruefstelle/examplesanlegen npm inpm run dev
Prüfstelle ist zwar unter http://localhost:3000/ erreichbar, wird aber einen Fehler anzeigen. Schließlich läuft das Backend noch nicht.
cdins Repocd pruefstelle/backend/settings- Dort
.secrets.tomlnach dem Beispiel inexamples/example.secrets.tomlanlegen (mindestens die im Beispiel mit "???" markierten Werte müssen angepasst werden) cd pruefstelle/backendpython3 -m venv .venvsource .venv/bin/activatepip install .pruefstelle run(vgl.pruefstelle --helpfür Konfigurationsmöglichkeiten)
Die API ist unter http://localhost:8000 (Swagger UI unter: http://localhost:8000/docs) erreichbar.
Und prüfstelle wartet nun ohne Fehler unter http://localhost:3000.
Statt npm run dev (Schritt 6) npm run build ausführen. In pruefstelle/frontend/build finden sich nun Javascript-Dateien, die so von beliebigen Webservern statisch ausgeliefert werden können. Mehr Informationen dazu finden sich hier.
Mit npm run preview lässt sich die Produktivbuild ausprobieren.
Statt pruefstelle (Schritt 8) ENV_FOR_PRUEFSTELLE=production pruefstelle run ausführen und die mit ??? markierten Werte ersetzen.
Je nach Verwendungszweck empfiehlt sich in .secrets.toml unter [production.db] eine andere Datenbank als SQLite (z. B. PostgreSQL) einzusetzen sowie uvicorn in Verbindung mit z. B. guvicorn zu nutzen; Informationen zu Letzterem finden sich hier.
Zu der Konfigurationsdatei vgl. examples/example.secrets.toml und den Abschnitt zur Installation oben.
/pruefstelle/frontend/src/routes: Routing mit Pfaden, wie sie im Browser verwendet werden./pruefstelle/frontend/src/api: Der generierte und angepasste (zu Anpassungen vergleich in den Kommentaren im Kopf der Dateien) API-Client/pruefstelle/frontend/src/components: Svelte-Bausteine; je in Unterordner organisiert, wenn Komponenten enger zusammenhängen/pruefstelle/frontend/src/scripts: Skripte; wenn sie zu einer Komponente gehören, haben die Skripte die gleichen Namen wie die Bausteine incomponents/
pruefstelle/backend/pruefstelle/database: Alles was mit der Datenbank zu tun hat; inpruefstelle/backend/pruefstelle/database/tables.pywerden die Tabellen deklariert; incrud/finden sich die Datenbankoperationenpruefstelle/backend/pruefstelle/external: API-Clients für externes Services, die zur Interaktion mit diesen vonbase_api.py:Apierbenpruefstelle/backend/pruefstelle/routes: Endpunkte Prüfstellen-API; inrestrictions/finden sich ggf. vorhandene Bedingungen, die für die Durchführung einer Endpunkt-Aktion erfüllt sein müssen; vgl. dazu auchroutes/__init__.pypruefstelle/backend/pruefstelle/schemas: Serialisierungsschemata bzw. Modelle der Endpunktepruefstelle/backend/pruefstelle/security: JWT-Authentifzierungpruefstelle/backend/pruefstelle/tasks: Alle sonstigen Operationen, die nicht CRUD-Operationen sind (z. B.report/zur Generierung des Punktwerts auf Basis des Fallprofils)
Dabei gilt, dass z. B. routes/case.py sich auf z.B. die Schemata in schemas/case.py bezieht.
- Datenbank: SQLAlchemy-Dokumentation
- API: Fastapi-Dokumentation
Die Links in diesem Abschnitt verweisen direkt auf die API und sind nur zugänglich, wenn diese auf localhost:8000 läuft.
- User:in: Kann auf alle Endpunkte außer die unter admin/ zugreifen
- Superuser:in: Kann zusätzlich auf die Endpunkte unter admin/ zugreifen
Das ist nur über die Kommandozeile möglich (vgl. pruefstelle create-user --help).
Nutzer:innenaccounts lassen sich über die admin/user-Endpunkte anlegen/ändern.
Mit pruefstelle populate können die erforderlichen und Standard-Kategorien angelegt werden.
Kategorien lassen sich über die admin/category-Endpunkte anlegen/ändern
Wurde nichts geändert, ist prüfstelle nun unter http://localhost:3000 zu erreichen, die API unter http://localhost:8000 (API-Dokumentation unter: http://localhost:8000/docs).
Werden Anpassungen am Backend vorgenommen, muss ggf. der Frontend-Client aktualisiert werden. Es ist sinnvoll, die für das Frontend irrelevanten Adminrouten vorab auszukommentieren (unter backend/pruefstelle/routes/__init__.py).
Dazu ist unter http://localhost:8000/openapi.json die automatisch erzeugte API-Spezifikation verfügbar. Mit dieser kann per npx swagger-typescript-api -p openapi.json -o ./src --unwrap-response-data --single-http-client --modular ein Client erzeugt werden.
Nun bitte die in den Dateien in frontend/lib/api dokumentierten Änderungen vornehmen und die dort vorhandenen Dateien durch die generierten ersetzen.
prüfstelle hat einen begrenzten Einsatzzweck. Ziel ist nicht die Bewertung von Verfahren zur automatischen Klassifizierung ("Künstliche Intelligenz") an sich.
Vielmehr kann mit prüfstelle aus der Perspektive ausgewählter Beispielfälle exploriert werden, unter welchen Weiterverarbeitungsbedingungen was wie gut funktioniert. Der Blick geht dabei vom Besonderen auf das Allgemeine, was eine Verallgemeinerung nur unter bestimmten Bedingungen erlaubt. Statt also zu fragen "was kann die Maschine?" ist die Frageperspektive hier: "Wie gut funktioniert das für mein Archivgut?".
Viele Hilfstexte helfen dabei, sich automatischen Klassifizieren auch ohne Vorwissen zu nähern und so mithilfe von prüfstelle Einsatzzwecke in einer kontrollierten Umgebung zu erproben.
- Im jetzigen Zustand ist Prüfstelle nur nutzbar, wenn Zugriff auf interne Services besteht; Hinweise auf zu ersetzende Elemente bei Einsatz mit anderen Services geben die Dateien in
backend/settings/ - Die vorhandene Authentifizierung ist dazu gedacht, mehrere Bewertungen durch verschiedene Personen zu ermöglichen und dabei möglichst komfortabel zu sein. Sie ist nicht auf Sicherheit ausgelegt. Es ist keine gute Idee, Prüfstelle ohne weitere Maßnahmen außerhalb eines gesicherten, internen Netzes zu betreiben.
- Die Datenbankabfragen sind nicht optimiert.