Author: Lukas Marquitan

Da sich meine Ausbildung dem Ende zuneigt muss ich als Teil des IHK-Abschlusses ein eigenes Projekt ausführen und dokumentieren. Hierzu habe ich nun mit meinen Ausbildern gesprochen, welche Projekte momentan anstehen und interessant für mich sind. Dabei ist als Projekt die Erweiterung Deepers um die Erkennung von Schriftarten entstanden. Das Projekt muss selbstständig geplant und implementiert werden und währenddessen dokumentiert werden.
Zunächst muss ein Antrag an die IHK gestellt werden, in dem das Projekt detailliert beschrieben wird. Dabei muss die aktuelle Situation, der Grund für die Änderung als auch die Mittel, mit denen Gearbeitet wird genau beschrieben werden.
Außerdem muss eine vorläufige Zeitplanung erstellt werden.

Ich werde mein Projekt im April fertig stellen und werde dann nochmal genauer berichten.

Bei der Segmentierung der Zeilen für Deeper erkennt das neuronale Netz, das der Segmentierung zu Grunde liegt, immer wieder falsche Zeilen. Allerdings werden diese falsch gefundenen Zeilen mit einer geringen Confidence (Sicherheit der Erkennung) versehen, weshalb sie zum größten Teil rausgefiltert werden können indem man ab einem gewissen Schwellwert diese Zeilen nicht in das Segmentierungsergebnis übernimmt. Bisher wurde dieser Schwellwert bei einem neu trainierten Netz händisch ermittelt. Das soll jetzt automatisch passieren.

Vorbereitung

Um den Trashhold bestimmen zu können werden teile des Produkts Cibtextcompare verwendet um die Positionen der erkannten Boxen mit einer Ground Trouth zu vergleichen. Dadurch, dass die Zeilen anders erkannt werden, als sie in unserer Testmenge hinterlegt sind müssen die Referenzdokumente erst auf das Gleiche Format geändert werden bis man die Zeilen miteinander Vergleichen kann.

Außerdem müssen auch die erkannten Zeilen unbearbeitet gespeichert werden, sodass das Ergebnis nicht verfälscht wird.

Vergleich

Sobald die zu vergleichenden erkannten Ergebnisse vorbereitet sind wird überprüft wie weit sich die Boxen überschneiden, und sobald eine Genügend große Überschneidung vorliegt werden die erkannten Zeilen, die nicht aus der Groundtrouth stammen, als valide markiert. Die Zeilen, die nicht für valide erklärt wurden werden daraufhin auf ihre Confidence überprüft. Übersteigt die größte Confidence der als falsch markierten Zeilen keine einzige Confidence der validen Zeilen wird ein Trashhold minimal höher als die höchste Confidence der falsch erkannten Zeilen eingestellt und die falschen Zeilen werden künftig rausgefiltert.

Nachdem ein Fehler in einem Tool zum vergleichen von OCR-Ergebnissen entstanden ist musste dieser Fehler aus dem Code entfernt werden.

Zuerst musste der Fehler reproduziert werden. Als das getan war musste die Ursache für den Fehler erkannt werden.

Dazu habe ich den in PyCharm eingebetteten Debugger verwendet. Ein Debugger ist ein Programm, dass Code ausführt und den Status an einer bestimmten stelle des Codes zurückgeben kann.

Um den Fehler verstehen zu können habe ich einen Breakpoint vor der Stelle mit dem auftretenden Fehler gesetzt und mir den Inhalt des Dicts, bei dem ein Key-Error auftritt angeschaut. Dabei ist aufgefallen, dass ein Element aufgerufen wird obwohl es vorher gelöscht wurde.

Als Lösung werden Elemente, die bereits gelöscht sind aus der Liste der zu Löschenden Elemente gelöscht.

Meine Aufgabe besteht momentan darin Zeilen mit zu geringer Confidence (Selbstsicherheit der Erkennung) in der Texterkennung von Deeper auszusortieren.

An sich besteht unsere Texterkennung aus zwei Komponenten. Im ersten Schritt werden Zeilen erkannt und im zweiten in den erkannten Zeilen Text erkannt. Der Stand bisher ist, dass in falsch erkannten Zeilen auch Text erkannt und in das Dokument übernommen wird.

Um falschen Ergebnissen vorzubeugen wird künftig die Confidence der Texterkennung überprüft und wenn sie kleiner als ein Schwellenwert ist wird die Zeile, mit der schlechten Confidence, aussortiert. Dabei ist es Wichtig den Schwellenwert so anzupassen, dass möglichst keine richtige Zeile gestrichen wird und möglichst viele Falsche aussortiert werden.

Nachdem ich jetzt ca. ein Jahr in der KI-Abteilung gearbeitet habe bekomme ich im Rahmen meiner Ausbildung jetzt die Möglichkeit die Abteilung zu wechseln um auch andere Aspekte des Berufs kennen zu lernen.

Dabei wurde ich im Mitarbeitergespräch gefragt, was mich interessiert und womit ich gerne arbeiten würde. Als ich gesagt habe, dass ich gerne mit Datenbanken zu tun hätte um auch dieses Gebiet kennen zu lernen, wurde mir angeboten mich mit NoSQL zu beschäftigen.

Wozu braucht man NoSQL?

Durch die immer Größere Datenmenge und die immer unstrukturierteren Daten stoßen relationale Datenbanken immer öfter an ihre Grenzen. Um dem Problem der unstrukturierten Daten entgegen zu wirken speichern nicht relationale Datenbanken ihre Daten nicht nach einem festen Schema sondern Beispielsweise in “Dict-Ähnlichen” Strukturen oder als Graphen. Das bietet den Vorteil, dass man die Daten nicht an die Datenbank anpassen muss und flexibler bleibt. Die Datenbank kann dadurch organisch wachsen.

Große Datenmengen stellen klassische Datenbanken vor ein Problem, da diese nur vertikal skalierbar (Steigerung der Leistung durch die Steigerung eines Rechners (HW-Limitiert)) sind. Um das zu umgehen sind NoSQL Datenbanken wie CouchDB, MongoDB, Neo4J durch ihre Art zu speichern und ihre Implementierung meist horizontal skalierbar(unendlich weit durch hinzufügen von neuen Knotenpunkten) . Dadurch wird keine spezielle, sehr teure Hardware für große Datenbanken benötigt

Leider bringt dieser Ansatz auch Nachteile mit sich. So sind die Daten meistens nicht normalisiert und mehr Speicherplatz wird belegt. Außerdem bringt ein organisch wachsendes System zwar Vorteile, doch kann es schnell zu einem nicht durchschaubaren Chaos an verschiedenartigen Einträgen kommen. Deshalb sollte trotz der Variabilität von NoSQL-Datenbanken stets eine Ordnung oder eine grobe Vorlage der Datenstruktur gelten um weiterhin die Funktion der DB garantieren zu können.

Zwei der NoSQL-Ansätze möchte ich Grob vorstellen:

Graphendatenbanken

Graphendatenbanken speichern die Daten als Graph bestehend aus Knotenpunkten, die Gegenstände repräsentieren und Kanten, die die Beziehungen zwischen zwei Knoten darstellen. Dabei sind die Kanten gerichtet und ein Knoten kann beliebig viele Kanten haben. Diese Art der Speicherung eignet sich besonders bei Einträgen, bei denen die Beziehung der Knoten zueinander wichtig ist.

Bekannte Vertreter: Neo4J, Amazon Neptune

Dokumentenorientierte Datenbank

Dokumentenorientierte Datenbanken speichern die übergebenen Daten in JSON-ähnlichen Formaten. Die größte Stärke dokumentenorentierter Datenbanken liegt in unstrukturierten Daten, da ein Dokument mit beliebigem Inhalt gefüllt werden kann. Das geht sogar so weit, dass man teilweise nicht auf ein anderes Dokument referenziert sondern das Dokument einfach in ein anderes schreibt. Mit dieser Methode der “Referenzierung” kann man die Zugriffszeiten bei häufig gewählten Kombinationen zweier Dokumente deutlich verringern. Der größte Nachteil dieser Methode ist der zusätzliche Speicherplatz, der durch fehlende Normalisierung verloren geht.

Bekannte Vertreter: CouchDB, MongoDB