Autor: Lukas Marquitan

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