Hallo,
heute melde ich mich wohl zum letzten mal hier im Azubiblog.
Nachdem ich heute meine mündliche Prüfung ablegen und meine Projektarbeit vorstellen musste bin ich nun offiziell mit meiner Ausbildung fertig. Und was mich noch mehr freut ist, dass ich übernommen werde.
Heißt, dass ich weiterhin hier bei der CIB als Softwarentwickler arbeiten kann.
Hallo, nachdem ich den Prüfungsstress hinter mir habe, freue ich mich mal wieder Zeit zum Bloggen zu haben.
Nachdem ich die schriftliche Prüfung geschrieben habe, konnte ich mich meiner Projektarbeit widmen, die es war, ein neuronales Netz so anzupassen, dass es Schriftarten erkennt. Dazu habe ich die Texterkennung von DeepER um ein LSTM erweitert. Das LSTM erkennt in einer Zeile an mehreren Stellen die Schriftart.
Im Nachhinein wird der Output des LSTMs für die einzelnen Wörter überprüft und im Layout die Schriftart gespeichert.
Wofür eine Fonterkennung?
Zum einen lässt sich mit der erkannten Font aus einem Bild eine digital identisches Dokument erstellen, zum anderen kann man künftig die erkannte Font verwenden um anderen Text über den bisherigen zu rendern und somit Dokumente zu pseudonymisieren.
Nächste Woche Mittwoch habe ich meine mündliche Prüfung und je nach Ergebnis endet dann meine Ausbildung. Also lerne ich momentan abends und hoffe, dass ich bestehe. Update folgt.
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.
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.
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.
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 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 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
Hallo,
nachdem Ich jetzt seit grob einem viertel Jahr hier arbeite habe ich genug Erfahrungen und Einblicke bekommen um auch eine Blog-Artikel schreiben zu können.
Zu meiner Tätigkeit:
Ich bin von Anfang an beim DeepER-Team in der Entwicklung tätig.
Meine erste größere Aufgabe war es ein Programm zur Erstellung von künstlichen Trainingsdaten für die Segmentierung zu erstellen, was eine gute Möglichkeit war sich in die “Denkweise” des Netzes hinter der Segmentierung “einzufühlen”.
So gab es z.B Anfangs Probleme mit dem Erkennen von untereinander liegenden Zeilen, da diese in meinem Programm immer genau untereinander gesetzt wurden und Somit das Netz bei zwei eng aneinander liegenden Zeilen davon Ausging, das alle Zeilen mit dem gleichen Abstand von einander getrennt sind.
Die Lösung war es diese Abstände zu variieren
Die Wochen drauf habe ich einen internen KI-Workshop besucht indem ich viel über DeepER und die beiden Neuronalen Netze im Hintergrund lernen konnte.
Seit dem bearbeite seit dem bearbeite ich hauptsächlich die algorithmische Nachschärfung der Ergebnisse der Segmentierung.
