Kategorie: Projekte

Internes Referenzprojekt

Status: Intern eingesetzte Anwendung mit dokumentiertem Weiterentwicklungsbedarf.

Fachlicher Schwerpunkt: Individuelle Python-Software, kontrollierte Datenverarbeitung und KI-gestützte Entwicklung.

eur_ledger unterstützt die Aufbereitung von Einnahmen, Ausgaben und weiteren Geschäftsvorgängen im Ingenieurbüro Marschner. Die Anwendung verbindet strukturierte Eingaben mit einer lokalen Datenbank, nachvollziehbaren Prüfungen und wiederholbar erzeugbaren Berichten.

Als internes Referenzprojekt zeigt sie, wie KGM fachliche Anforderungen in wartbare Software übersetzt: mit klaren Zuständigkeiten, überprüfbaren Verarbeitungsschritten und einer kontrollierten Weiterentwicklung. KI unterstützt die Entwicklungsarbeit; fachliche Entscheidungen und die Abnahme bleiben beim Menschen.

Eigenes Softwareprojekt besprechen

Ausgangslage

Zur Vorbereitung betrieblicher Auswertungen müssen Belege, Zahlungen und Zuordnungen zusammenpassen. Dabei reicht es nicht, Werte zu erfassen: Ein erneuter Import darf vorhandene Daten nicht unbemerkt verdoppeln. Änderungen an zusammengehörigen Daten müssen konsistent bleiben. Und ein Bericht muss erkennen lassen, auf welchem Datenbestand er beruht.

eur_ledger bearbeitet diese Anforderungen in einem begrenzten internen Anwendungsfall. Das Projekt bietet damit einen konkreten Rahmen, um Datenmodellierung, Importregeln und Qualitätssicherung zusammenzuführen.

Ziel

Ziel ist eine nachvollziehbare Verarbeitung von der strukturierten Eingabe bis zur Auswertung. Fachliche Regeln sollen verständlich dokumentiert, getrennt von der Bedienoberfläche umgesetzt und gezielt prüfbar sein.

Ein tragfähiges Ergebnis bedeutet für dieses Projekt:

• Eingaben werden nach definierten Regeln geprüft und zugeordnet.
• Bereits importierte Quellen bleiben identifizierbar.
• Zusammengehörige Datenänderungen besitzen eine ausdrücklich festgelegte Transaktionsgrenze.
• Berichte entstehen aus dem gespeicherten Datenbestand.
• Änderungen an Datenmodell und Anwendung werden versioniert und geprüft.

Lösungsansatz

Die Anwendung wird über eine Kommandozeile bedient. Geschäftsvorgänge lassen sich manuell erfassen oder aus einer strukturierten Excel-Datei importieren. Die Daten werden in einer lokalen SQLite-Datenbank gespeichert. Daraus erzeugt eur_ledger Monats-, Quartals- und Jahresberichte sowie XLSX-Dateien und Unterlagen zur Übergabe an die Steuerberatung.

Der Import unterscheidet zwischen einem Probelauf und einer tatsächlichen Übernahme. Importdiagnosen helfen, auffällige Datensätze zu erkennen und zu prüfen. Ein Probelauf schreibt keine importierten Buchungsdaten dauerhaft, bildet derzeit aber noch nicht alle Prüfungen gegen bereits vorhandene Daten ab. Er ersetzt deshalb nicht die Kontrolle des tatsächlichen Importergebnisses.

Architektur und Technologien

Das Architekturmodell zeigt die angestrebte Aufteilung von eur_ledger. Es unterscheidet vorhandene Bausteine, den geplanten Bankimport und optionale Erweiterungen. Die technische Trennung ist heute teilweise umgesetzt.

Heute umgesetzt

Kommandozeile und Excel-Import erschließen die fachlichen Abläufe. Anwendungsdienste koordinieren Verarbeitung und Validierung und legen Transaktionsgrenzen fest. Eine Unit of Work stellt die Datenbanksitzung bereit und führt das Speichern oder Zurücknehmen zusammengehöriger Änderungen aus. Berichte und Exporte machen die gespeicherten Daten auswertbar.

Python und Typer bilden die Grundlage der Kommandozeile. SQLModel und SQLAlchemy verbinden die Anwendung mit SQLite. Änderungen am Datenbankschema werden ausdrücklich über Alembic-Migrationen ausgeführt. Linux beziehungsweise WSL ist die primäre Entwicklungsumgebung.

Die Entkopplung ist noch nicht vollständig: Schnittstellenverträge sind teilweise vorhanden, fachliche Modelle teilweise mit SQLModel verbunden. Einzelne Berichte greifen direkt auf die Datenbanksitzung zu.

Zielbild und mögliche Weiterentwicklung

Der geplante Bankimport soll Bankdaten über einen Eingangsadapter in die vorhandenen Importabläufe einbringen. Für den direkten Abruf bei einer Bank kann zusätzlich ein ausgehender Bank-API-Client erforderlich werden. Die Einordnung richtet sich danach, wer einen Anwendungsfall startet und welche externe Schnittstelle die Anwendung dafür aufruft.

REST-API, zeitgesteuerte Aufgaben sowie weitere Ausgabe- und Speicheranbindungen sind Erweiterungsoptionen. Neue Adapter sollen vorhandene fachliche Abläufe nutzen können. Dazu gehört, die Schnittstellenverträge weiter auszubauen und die Fachlogik stärker von der technischen Umsetzung zu lösen.

Engineering und Qualität

Zusammengehörige Änderungen gemeinsam absichern

Ein dokumentiertes Testbeispiel verbindet zwei Schritte in einem gemeinsamen Ablauf: eine Eingangsrechnung anlegen und die zugehörige Zahlungsinformation erfassen. Es werden Zahlungsinformationen gespeichert; eine Banküberweisung wird nicht ausgelöst.

Beide Änderungen nutzen dieselbe Unit of Work – eine technische Einheit, die eine gemeinsame Datenbanksitzung bereitstellt und das Speichern oder Zurücknehmen ausführt. Bei erfolgreichem Abschluss werden beide Änderungen gemeinsam gespeichert. Der alternative Fehlerfall setzt nach beiden vorbereiteten Änderungen und vor dem gemeinsamen Speichern an: Nach erfolgreicher Rücknahme bleibt keine der beiden neuen Änderungen dauerhaft gespeichert.

Eine fehlgeschlagene Rücknahme darf nicht als erfolgreich gemeldet werden. Das abstrahierte Testbeispiel belegt diesen gemeinsam abgegrenzten Ablauf, keine allgemeine Fehlerfreiheit oder vollständige Atomarität aller Importmodi. Eigenständige öffentliche Serviceaufrufe besitzen jeweils eigene Transaktionen; ihre bloße Abfolge ergibt noch keine gemeinsame Transaktion.

Auch beim erneuten Excel-Import ist die Herkunft entscheidend. Eine unveränderte, bereits importierte Quellzeile wird übersprungen. Wird dieselbe Quellzeile verändert, meldet die Anwendung einen Konflikt, statt den vorhandenen Datensatz stillschweigend zu überschreiben. Gleiche Beträge oder ähnliche Belegangaben allein gelten dagegen nicht als sicherer Nachweis einer Dublette.

Automatisierte Tests werden durch Typprüfung, statische Codeprüfung und einheitliche Formatierung ergänzt. Architekturentscheidungen und Änderungen am Datenbankschema werden dokumentiert. Reviews prüfen den Zusammenhang zwischen Auftrag, Umsetzung, Tests und Dokumentation.

KI-gestützte Entwicklung mit klarer Verantwortung

Im Entwicklungsprozess unterstützt KI die Analyse, Umsetzung, Prüfung und Dokumentation. Die Arbeit beginnt mit einem abgegrenzten Auftrag und festgelegten Grenzen. Änderungen werden anschließend anhand ihres tatsächlichen Inhalts und der zugehörigen Prüfungen bewertet.

Über Architektur, fachliche Regeln und die Übernahme von Änderungen entscheidet KGM. Die hier beschriebene KI-Unterstützung betrifft den Entwicklungsprozess; sie ist keine KI-basierte Buchungsentscheidung innerhalb von eur_ledger.

Ergebnis und übertragbare Kompetenz

Der dokumentierte Projektstand umfasst strukturierte Importe, manuelle Erfassung, Berichte und Exporte. Der technische Kompetenznachweis liegt insbesondere in der Verbindung von Datenmodell, ausdrücklich geregelten Transaktionen, nachvollziehbarer Herkunft importierter Daten und automatisierten Fehlerfallprüfungen.

Diese Arbeitsweise ist auch für andere individuelle Anwendungen relevant: beispielsweise wenn technische Büros oder kleine Unternehmen Daten aus Tabellen übernehmen, fachliche Prüfregeln abbilden oder wiederkehrende Auswertungen automatisieren möchten. Welche Teile übertragbar sind, wird für den jeweiligen Anwendungsfall gesondert geprüft.

Bewusste Grenzen

eur_ledger ist ein internes Referenzprojekt und wird nicht als öffentliches Buchhaltungsprodukt angeboten. Es besitzt keine steuerliche, rechtliche oder GoBD-Zertifizierung und ersetzt keine steuerliche Beratung.

Eine automatische Bankanbindung, ein automatischer Bankabgleich und die elektronische Abgabe von Steuererklärungen gehören nicht zum hier dargestellten Funktionsstand. Auch automatische Abschreibungsbuchungen sind nicht umgesetzt.

Die Darstellung zeigt abstrahierte Abläufe. Reale Buchhaltungsdaten, interne Betriebsinformationen und der vollständige Quellcode werden nicht veröffentlicht. Die vorhandenen Tests belegen konkrete geprüfte Fälle; sie sind keine Garantie für allgemeine Fehlerfreiheit.

Vom internen Projekt zur individuellen Lösung

Ein eigenes Softwareprojekt beginnt mit Ihren Daten, Abläufen und fachlichen Anforderungen. Gemeinsam lässt sich klären, welche Verarbeitungsschritte sinnvoll automatisiert werden können und woran ein belastbares Ergebnis erkennbar ist.

Die Leistung Individuelle Softwareentwicklung beschreibt den Rahmen für eine mögliche Zusammenarbeit.

Der Fachbeitrag Wartbare Software statt schneller Lösungen vertieft die Bedeutung einer durchdachten Struktur.

Eigenes Softwareprojekt besprechen

Eigenentwicklung · Referenzsystem

Status: Geführte Referenzdemo verfügbar; aktive Weiterentwicklung

Fachlicher Schwerpunkt: Kontrollierte lokale KI-Wissenssysteme mit nachvollziehbaren Quellen und systematischer Evaluation.

KGM Knowledge RAG ist ein eigenes Referenzsystem des Ingenieurbüros Marschner. Es zeigt, wie freigegebenes internes Wissen lokal erschlossen, für konkrete Fragen bereitgestellt und mit nachvollziehbaren Quellen verbunden werden kann.

Im Mittelpunkt steht nicht eine möglichst überzeugend formulierte KI-Antwort, sondern ein kontrollierter und überprüfbarer Gesamtprozess. Das Referenzsystem dient als technischer Kompetenznachweis und als Grundlage für die Planung abgegrenzter Kundenpiloten.

Geführte Demo anfragen

Architektur und Grenzen lesen

Was Sie in der geführten Demo sehen

Die geführte Referenzdemo ist verfügbar. An fünf synthetischen, ausdrücklich freigegebenen Markdown-Dokumenten lässt sich der Weg von der Suche zur Antwort mit zugeordneten Quellen nachvollziehen. Der Bestand enthält keine Kundendaten. Suche und Antwortverarbeitung laufen auf der lokalen Referenzworkstation, ohne Cloud-KI-Aufrufe im gezeigten Laufzeitpfad.

Eine lokale Browseroberfläche führt durch vier feste Fälle. Gemeinsam betrachten wir dabei vier Fragen:

1. Finden: Welches Dokument beziehungsweise welche Textstelle findet die Suche?
2. Belegen: Trägt die angezeigte Quelle die Antwortaussage?
3. Verbinden: Werden Informationen aus mehreren Quellen richtig zusammengeführt?
4. Grenzen erkennen: Wie reagiert das System, wenn die erforderliche Grundlage fehlt?

Das sind Beobachtungs- und Prüffragen, keine vorweggenommenen Erfolge. Der aktuelle Referenzstand kann unvollständige, unbelegte oder widersprüchliche Antworten liefern. Quellen machen Aussagen prüfbar; ob sie richtig und vollständig sind, bleibt fachlich zu bewerten. Fehlende Grundlage soll offen benannt werden, wird aber nicht zuverlässig erkannt.

Die Vorführung ist begleitet. Es gibt keinen frei zugänglichen Live-Zugang, keine freie Eingabe beliebiger Fragen und keine spontane Aufnahme von Kundendaten. Die begrenzte Demo ist mit diesen bekannten Grenzen angenommen; sie belegt noch keine Eignung für einen konkreten Kundenbestand.

Ausgangslage

Unternehmenswissen liegt häufig verteilt in Projektdokumentationen, Spezifikationen, Betriebshandbüchern, Runbooks oder internen Anleitungen. Klassische Stichwortsuchen erfassen sprachlich verwandte Inhalte nur eingeschränkt und machen nicht immer deutlich, welche Quelle eine gefundene Aussage tatsächlich trägt.

Allgemeine Sprachmodelle lösen dieses Problem nicht automatisch. Ohne kontrollierten Wissensbestand, nachvollziehbares Retrieval und überprüfbare Quellen können sprachlich plausible Antworten entstehen, deren fachliche Grundlage unklar bleibt.

Das Referenzsystem untersucht deshalb den gesamten Weg vom freigegebenen Dokument bis zur Antwort und ihrer fachlichen Prüfung – einschließlich der Frage, wie das Modell mit fehlender Grundlage umgeht.

Ziel des Referenzsystems

KGM Knowledge RAG soll die technische Machbarkeit eines kontrollierten lokalen RAG-Pfads nachvollziehbar belegen.

Ziel der Weiterentwicklung ist, dass

• ein abgegrenzter und versionierter Wissensbestand reproduzierbar verarbeitet wird,
• relevante Textabschnitte für eine Frage nachvollziehbar ausgewählt werden,
• Antworten auf den bereitgestellten Kontext begrenzt bleiben,
• verwendete Quellen eindeutig zugeordnet werden,
• unzureichende Evidenz offen benannt und eine nicht belegbare Antwort unterlassen wird,
• technische Prüfungen durch eine fachliche Bewertung ergänzt werden,
• bekannte Grenzen sichtbar dokumentiert bleiben.

Diese Ziele sind kein Nachweis, dass die aktuelle Demo sie in jedem Fall erfüllt. Angestrebt wird ein belastbarer Referenzstand für Architektur-, Qualitäts- und Pilotentscheidungen, kein fertiges Standardprodukt.

Kontrollierter Lösungsansatz

Die Verarbeitung beginnt mit einem versionierten synthetischen Referenzbestand ohne Kunden- oder personenbezogene Daten. Die Dokumente werden nach festgelegten Regeln aufbereitet und in reproduzierbare Textabschnitte zerlegt.

Für eine Anfrage werden semantisch passende Abschnitte aus einem lokalen Vektorindex ausgewählt. Nur eine begrenzte Auswahl dieser Abschnitte gelangt in den Antwortkontext. Die Anwendung ordnet gültige Quellenmarker im Antworttext den tatsächlich bereitgestellten Quellen zu und prüft definierte formale Regeln. Daraus folgt keine automatische inhaltliche Beweisprüfung jeder Aussage.

Reicht der bereitgestellte Kontext nicht aus, soll das Modell die fehlende Grundlage offen benennen und sich gegebenenfalls enthalten. Das ist gewünschtes Modellverhalten; eine zuverlässige automatische Erkennung fehlender Evidenz oder fachlich richtiger Enthaltung ist nicht gewährleistet.

Architektur und Technologien

Das Referenzsystem verbindet folgende Bausteine:

• Python-basierte Kommandozeilenwerkzeuge unter Linux beziehungsweise WSL,
• Markdown als kontrollierbares Dokumentformat,
• versionierte Manifeste und Prüfsummen für den Referenzbestand,
• deterministische Aufbereitung und Segmentierung der Dokumente,
• lokale Embeddings zur semantischen Repräsentation,
• einen lokalen FAISS-Vektorindex für das Retrieval,
• ein lokal ausgeführtes Antwortmodell mit begrenztem Kontext,
• formale Prüfung von Antwortformat und Quellenzuordnung,
• automatisierte Tests, versionierte Evaluationsfälle und Git-basierte Freigaben.

Die Architektur trennt Dokumentaufbereitung, Retrieval, Antworterzeugung und Evaluation bewusst voneinander. Dadurch können einzelne Komponenten geändert und erneut geprüft werden, ohne den gesamten Prozess als undurchsichtige Einheit zu behandeln.

Die Grafik zeigt den vereinfachten Antwortpfad; die im Antwortvertrag vorgesehene Ablehnung bei unzureichendem Kontext ist nicht dargestellt. Technische Tests prüfen Aufbereitung und Index, formale Prüfungen Antwortformat und Quellenzuordnung. Die manuelle Fachbewertung ergänzt die Evaluation am Referenzstand und ist kein automatischer Schritt jeder Antwort.

Konkrete Modellnamen, Hardwarekonfigurationen und einzelne Leistungswerte werden nicht als dauerhafte Eigenschaften des Referenzsystems veröffentlicht.

Engineering und Qualitätssicherung

KGM Knowledge RAG wird als Engineering-Projekt entwickelt. Architekturentscheidungen, Konfigurationen, Testfälle und bekannte Grenzen werden versioniert und gegen einen definierten Referenzstand geprüft.

Zur Qualitätssicherung gehören insbesondere:

• automatisierte Prüfungen der Datenaufbereitung und Indexerstellung,
• reproduzierbare Retrieval- und Antwortläufe,
• formale Validierung der Quellenangaben,
• positive, dokumentenübergreifende und nicht beantwortbare Testfragen,
• getrennte Bewertung von Retrieval, Antwortformat und fachlicher Vollständigkeit,
• manuelle fachliche Prüfung, wo automatisierte Kriterien allein nicht ausreichen,
• dokumentierte Freigaben und erneute Prüfung nach relevanten Änderungen.

Freigaben beziehen sich auf einen ausdrücklich begrenzten Einsatz und dokumentieren die geprüften Kriterien sowie bekannte Abweichungen. Die geführte Referenzdemo ist mit bekannten Inhaltsgrenzen angenommen. Das bedeutet weder, dass alle fachlichen Qualitätsziele fehlerfrei erfüllt sind, noch eine allgemeine Modell- oder Produktionsfreigabe.

Belegbare Ergebnisse

Die Retrieval-Grundlage wurde mit einem versionierten Fragensatz geprüft. Kontrolliert wurden die erwarteten Quellen, ihre Rangfolge, die Wiederholbarkeit der Ergebnisse und der Umgang mit Fragen außerhalb des Referenzbestands. Die für den dokumentierten Referenzstand festgelegten Retrieval-Kriterien wurden erfüllt.

Diese Ergebnisse gelten ausschließlich für den jeweils geprüften Datenbestand und dessen Chunking-, Embedding-, Index- und Retrieval-Konfiguration. Sie sind weder ein allgemeiner Qualitäts- oder Skalierungsnachweis noch ein Leistungsversprechen für andere Datenbestände.

Als weiterer Meilenstein ist die begrenzte geführte Referenzdemo einschließlich ihres Kundenmedienpakets freigegeben. Einrichtung und ausgewerteter manueller Betrieb der getrennten Demo-Installation sind angenommen. Bekannte inhaltliche Fehler bleiben sichtbar; die Annahme ist kein allgemeiner Qualitätsnachweis.

Weiterführende Evaluationen berücksichtigen zusätzlich Antwortformat, Quellenbezug, fachliche Vollständigkeit und den Umgang mit fehlender Grundlage. Technische und formale Prüfungen werden dabei bewusst durch eine manuelle fachliche Bewertung ergänzt. Frühere Evaluations- und Laufzeitbefunde bleiben an ihren jeweiligen Daten-, Modell- und Konfigurationsstand gebunden; sie werden nicht als Ergebnisse der heutigen Demo ausgegeben.

Antwortqualität, Laufzeit und Ressourcenbedarf hängen vom Datenbestand, den eingesetzten Modellen, der Hardware und der Konfiguration ab. Einzelne Referenzmessungen werden deshalb nicht als dauerhaftes Leistungsversprechen veröffentlicht.

Übertragbare Anwendungsszenarien

Die mit dem Referenzsystem entwickelte Methodik kann als Ausgangspunkt für abgegrenzte Unternehmenssituationen dienen.

Projektdokumentationen und Spezifikationen

Technische Entscheidungen, Anforderungen und dokumentierte Zusammenhänge können semantisch erschlossen und mit ihren ursprünglichen Quellen verbunden werden.

Runbooks und Supportwissen

Betriebswissen, Fehlerbeschreibungen und dokumentierte Lösungswege können für wiederkehrende Supportfragen kontrolliert auffindbar gemacht werden.

Interne Anleitungen und FAQs

Freigegebene interne Anleitungen können als begrenzter Wissensbestand für nachvollziehbare Antworten auf wiederkehrende Fragen dienen.

Diese Szenarien beschreiben übertragbare Einsatzfelder. Sie sind keine Behauptung, dass sämtliche Datenquellen, Integrationen oder Betriebsvarianten bereits als fertige Standardlösung umgesetzt sind.

Bewusste Grenzen

Das Referenzsystem besitzt bewusst gesetzte Grenzen:

• Es arbeitet mit einem begrenzten synthetischen Referenzbestand und nicht mit realen Kundendaten.
• Ergebnisse lassen sich nicht automatisch auf andere Datenbestände übertragen.
• Quellenmarker belegen die Zuordnung zu bereitgestellten Quellen, nicht die fachliche Richtigkeit oder Vollständigkeit einer Antwort.
• Fehlende Grundlage kann übersehen werden; auch eine Enthaltung kann fachlich falsch sein.
• Unvollständige, unbelegte oder widersprüchliche Antworten sind bekannte Grenzen des aktuellen Referenzstands.
• Es besteht keine Garantie für fehlerfreie, vollständige oder rechtlich beziehungsweise fachlich konforme Antworten.
• Das System ist keine fertige SaaS-Plattform und kein allgemein verfügbares Standardprodukt.
• Es gibt keinen öffentlichen Live-Demo-Zugang.
• Benutzerverwaltung, Mandantenfähigkeit, öffentliche API, Hochverfügbarkeit und Enterprise-SLA sind nicht Bestandteil des Referenzsystems.
• Es besteht kein unbegrenztes Skalierungs- oder Leistungsversprechen.
• Der vollständige Quellcode, interne Prompts und sicherheitsrelevante Betriebsdetails werden nicht öffentlich bereitgestellt.

Diese Grenzen gehören zum Kompetenznachweis: Sie zeigen, unter welchen Bedingungen Ergebnisse belastbar eingeordnet werden können.

Vom Referenzsystem zum Kundenpilot

Ein Kundenpilot übernimmt nicht einfach die Referenzkonfiguration. Er beginnt mit einem eigenen Anwendungsfall, einem freigegebenen Wissensbestand und gemeinsam festgelegten Erfolgskriterien.

Dazu gehören typischerweise:

1. fachlichen Informationsbedarf und Nutzerfragen abgrenzen,
2. Datenbestand, Qualität und Zugriffsgrenzen prüfen,
3. geeignete Aufbereitung, Retrieval- und Betriebsannahmen festlegen,
4. einen begrenzten Pilot implementieren,
5. Retrieval, Quellen, Antworten und Ablehnungsfälle evaluieren,
6. auf Grundlage der Ergebnisse über Ausbau oder Beendigung entscheiden.

Die Leistungsseite zu KGM Knowledge RAG beschreibt den möglichen Einstieg über einen KI-Wissenscheck und einen begrenzten RAG-Pilot.

Die Artikelserie „Vom Dokument zum lokalen Wissensassistenten“ erklärt Suche, Quellenprüfung, Grenzen und die Vorbereitung eines Piloten an einem durchgängigen fiktiven Beispiel.

Die Artikelserie „Lokale KI-Infrastruktur für Unternehmen“ erläutert technische Grundlagen und Entscheidungswege für lokale Betriebsmodelle.

Geführte Referenzdemo kennenlernen

Lernen Sie den Ansatz an den vier festen Fällen kennen und besprechen Sie die beobachteten Antworten und Quellen. Für Ihren eigenen Anwendungsfall bleibt der KI-Wissenscheck der erste fachliche Schritt; ein Pilot folgt nur bei bestätigter Eignung.

Geführte Demo anfragen

KGM Knowledge RAG im Überblick (PDF, 1 Seite)