Häufig gestellte Fragen

CIRMS hilft Teams, routinemäßige betriebliche Aufgaben auszuführen, den Zustand ihrer Systeme zu erkennen und die von diesen Systemen erzeugten Informationen für die KI-Nutzung vorzubereiten. Der Name steht für Centralized Intelligent Resource Management System.

Es verbindet Automatisierung und Transparenz, anstatt Menschen Informationen sammeln und dieselben Prüfungen manuell wiederholen zu lassen. CIRMS GL3 übernimmt den Betrieb, GL4 bereitet Wissen auf, und GL5 ist die geplante Erweiterung um KI-Intelligenz.

Stellen Sie sich ein Team vor, das viele Server betreut. Auf einem Server wird der Speicherplatz knapp.

GL3: Eine konfigurierte Prüfung erfasst den freien Speicherplatz, vergleicht ihn mit einem Schwellenwert und macht das Ergebnis für das Team sichtbar. GL4: Bereitet diese Information mit ihrer Quelle, Struktur und Version auf, damit sie als Teil einer Wissensgrundlage genutzt werden kann. Geplantes GL5: Könnte dieses aufbereitete Wissen nutzen, um einer Person bei Untersuchungen oder Fragen zu helfen.

CIRMS GL3 — Intelligente Automatisierung & Datenerfassung: Führt definierte betriebliche Aufgaben aus, überwacht Ressourcen und erfasst Daten.

CIRMS GL4 — AI Data Readiness: Wandelt ausgewählte Betriebsdaten in strukturierte, versionierte und validierte Wissensbestände um.

CIRMS GL5 — AI Intelligence: Ist eine geplante Entwicklung für KI-gestützte Analyse, dialogbasierten Zugriff und Entscheidungsunterstützung auf dieser Grundlage.

Denken Sie an: Arbeit ausführen → Wissen aufbereiten → Menschen bei der Nutzung unterstützen. Die drei Bezeichnungen beschreiben unterschiedliche Verantwortlichkeiten, nicht drei Namen für dieselbe Funktion.

GL bedeutet Global Layer. Es bezeichnet einen Verantwortungsbereich innerhalb von CIRMS: Betrieb, Wissensaufbereitung oder geplante Intelligenz.

Eine Softwareversion bezeichnet eine bestimmte Veröffentlichung oder einen Build. Eine GL-Bezeichnung ist weder eine Versionsnummer noch eine Hardwaregröße oder die Aussage, dass eine spätere Schicht die vorherige ersetzt.

Nein. CIRMS arbeitet mit den verbundenen Systemen der vereinbarten Bereitstellung. Ihre Datenbanken und Geschäftsanwendungen bleiben die Quellen der betrieblichen Informationen.

Ziel ist es, wiederkehrende Verwaltungsaufgaben zu reduzieren und Aktivitäten leichter überprüfbar zu machen. Menschen definieren weiterhin Aufgaben, genehmigen Zugriffe, untersuchen Ausnahmen und verantworten betriebliche Entscheidungen.

Zuverlässige Informationen aufzubereiten und Fragen dazu zu beantworten sind unterschiedliche Aufgaben. Eine hilfreiche Antwort benötigt die richtige Quelle, genügend Kontext und Klarheit darüber, welche Version aktuell ist.

GL4 widmet sich dieser Aufbereitung. Die geplante GL5-Schicht würde das daraus entstehende Wissen zur Unterstützung nutzen. Der Abschluss von GL4 erzeugt nicht automatisch einen Chatbot und macht nicht jede Antwort richtig.

CIRMS ist überall dort relevant, wo Teams wiederholbare digitale Abläufe und klarere Informationen benötigen: beispielsweise bei IT-Diensten, in Industriebetrieben, im Finanzwesen, bei Versorgern oder im öffentlichen Sektor.

Ausgangspunkt ist die tatsächliche Arbeitslast, nicht die Unternehmensgröße. Eine kleinere Umgebung kann mit einem begrenzten Umfang beginnen; eine größere benötigt möglicherweise mehrere koordinierte Bereitstellungen. Branchenspezifische Anforderungen und Kontrollen müssen geprüft statt vorausgesetzt werden.

Nein. Beginnen Sie mit den kurzen Erklärungen und Beispielen. Begriffe wie Dokument, Chunk und Vektor werden unten erklärt, bevor Sie sie verwenden müssen.

Ein Dashboard zu lesen ist etwas anderes, als eine Bereitstellung zu konfigurieren. Für Verbindungen, Berechtigungen, die Registrierung von Quellen, die Gestaltung von Workflows und die Fehlerbehebung werden weiterhin technische Administratoren benötigt.

GL3 vereint wiederverwendbare Automatisierungsaufgaben, Workflow-Ausführung, betriebliche Datenerfassung, Monitoring, Zustandsprüfungen und Berichterstattung.

Eine konfigurierte Aufgabe könnte einen Dienst prüfen, Datenbankinformationen erfassen oder eine genehmigte Verwaltungsoperation ausführen. Anschließend hilft das Dashboard dem Team, die Ausführung und Probleme zu prüfen, die Aufmerksamkeit benötigen. Die verfügbaren Aufgaben hängen von den in der Bereitstellung enthaltenen Modulen und Ressourcen ab.

HERCULES ist eine operative Ausführungseinheit von CIRMS. Sie arbeitet nahe an einer verwalteten Umgebung und führt die für diese Umgebung konfigurierten Aufgaben aus.

HERCULES übernimmt GL3-Automatisierung und Datenerfassung und kann auch die GL4-Aufbereitungspipeline ausführen. Der Name beschreibt seine CIRMS-Rolle; er bedeutet nicht, dass jede HERCULES-Bereitstellung identische Ressourcen, Module oder Kapazitäten besitzt.

ATLAS ist die Komponente für Koordination und Aufsicht mit einem übergreifenden Blick auf HERCULES-Umgebungen. HERCULES führt die lokale Arbeit aus; ATLAS verbindet die Umgebungen für Koordination und Transparenz.

Eine Architektur für eine einzelne Umgebung kann mit einem HERCULES beginnen. ATLAS ist relevant, wenn die Bereitstellung eine umfassendere Koordination benötigt. Es ist kein anderer Name für GL5, und seine Anwesenheit bedeutet nicht, dass ein Chatbot verfügbar ist.

Ein ATOM ist eine kleine, gezielte, wiederverwendbare Ausführungseinheit. CIRMS verwendet für diese Bausteine auch den Begriff atomisierter Bot. Ein Modul bündelt zusammengehörige Funktionen. Ein Workflow koordiniert Aufgaben zu einer sinnvollen Abfolge.

Ein Job ist eine ausführbare Arbeitseinheit. Die Zeitplanung bestimmt, wann sie ausgeführt wird. Die Orchestrierung koordiniert die Schritte, ihre Reihenfolge und ihre Abhängigkeiten.

Beispielsweise müssen Daten erfasst werden, bevor ein Bericht die neuen Ergebnisse nutzen kann. CIRMS protokolliert die Ausführungsaktivität, damit das Team einen abgeschlossenen Lauf von einem fehlgeschlagenen oder nicht ausgeführten Lauf unterscheiden kann.

Es bedeutet, Informationen aus einer autorisierten Quelle zu sammeln, damit sie überwacht, in Berichten verwendet oder weiter aufbereitet werden können.

Beispiele sind Hostkonfiguration, Dienststatus, Datenbankdetails und Speichernutzung. GL3 bildet die Grundlage der betrieblichen Erfassung. Welche Datenbanken, Anwendungen, Dateien oder Dienste angebunden werden können, hängt von der unterstützten Integration und dem für die Bereitstellung vereinbarten Zugriff ab.

Monitoring zeigt aufgezeichnete Aktivitäten oder Messwerte. Eine Zustandsprüfung prüft einen Zustand anhand einer Regel.

Berücksichtigen Sie immer den Messzeitpunkt und die Konfiguration der Prüfung, nicht nur ihre Farbe auf einem Dashboard.

Die CIRMS-Oberfläche bietet die Ansichten Automation, Healthcheck, Monitoring und AI Data sowie betriebliche, datenbankbezogene und geschäftliche Berichte. Datenbankberichte können mit RDBMS gekennzeichnet sein, der Abkürzung für relationales Datenbankmanagementsystem.

Je nach Ansicht können Sie verwaltete Ressourcen, Aufgabenergebnisse, fehlgeschlagene Prüfungen, die Dauer von Stufen und Zähler zur Datenbereitschaft untersuchen. Ein Dashboard bietet einen Überblick; Details zur Ausführung oder auf Objektebene erklären, warum ein bestimmtes Ergebnis Aufmerksamkeit erfordert.

CIRMS-Oberfläche ansehen →

Nein. Ein Problem zu erkennen und ein System zu verändern sind getrennte Handlungen.

Korrekturmaßnahmen müssen ausdrücklich konfiguriert, autorisiert und für die Umgebung unterstützt sein. Manche Zustände sollten eine Untersuchung oder Benachrichtigung statt einer automatischen Änderung auslösen. „Automatisierung“ bedeutet keine unbegrenzte Selbstreparatur und keine Erlaubnis, beliebige Systeme zu verändern.

In einer Hub-and-Spoke-Anordnung kommunizieren verbundene Ressourcen mit einer zentralen operativen Einheit. In einer größeren CIRMS-Hierarchie können mehrere HERCULES-Einheiten unter ATLAS-Koordination stehen.

Einige frühere Materialien verwendeten „Snowflake“, um eine verzweigte Anordnung zu beschreiben. Gemeint ist hier eine Bereitstellungshierarchie – kein Versprechen einer Integration mit der Snowflake-Datenplattform oder eines bestimmten Datenbankschemas.

Bereitstellungsmodelle vergleichen →

GL4 wandelt ausgewählte Betriebsdaten in strukturierte, nachvollziehbare Wissensbestände um. Es prüft die Quelle, bereitet Daten auf, erzeugt KI-Dokumente und Versionen, erstellt Chunks und Vektordarstellungen und validiert das Aufbereitungsergebnis.

Der Prozess ist als Stufen 0–7 sichtbar. Er ist eine Aufbereitungspipeline, keine Chat-Anwendung und keine Garantie dafür, dass die ursprünglichen Geschäftsinformationen wahr sind.

GL3 übernimmt die betriebliche Erfassung und Ausführung. GL4 übernimmt die Vorbereitung für die KI-Nutzung. GL4 besitzt weiterhin eine eigene Stufe zum Laden von Rohdaten für registrierte Eingaben; dadurch ist es nicht für die Reparatur von Infrastruktur oder die Verwaltung sämtlicher vorgelagerter Systeme verantwortlich.

Beispielsweise kann GL3 Speicherinformationen in einem betrieblichen Datenbestand sammeln. GL4 kann anschließend die geeignete Tabelle registrieren und diesen Datenbestand als Wissen aufbereiten. Fehlende Berechtigungen oder eine nicht unterstützte Quelle müssen auf der zuständigen Quell- oder Betriebsebene geklärt werden.

Nicht automatisch. Der hier beschriebene aktuelle Aufbereitungspfad basiert auf geeigneten, registrierten Quelltabellen. Eine Quelle muss die jeweiligen Anforderungen an Schema, Identität, Zugriff und Extraktion erfüllen.

Der Begriff „KI-Dokument“ bedeutet nicht, dass GL4 jede hochgeladene Word- oder PDF-Datei akzeptiert. Zusätzliche Quellen und Formate benötigen eine ausdrücklich unterstützte Integration und einen vereinbarten Bereitstellungsumfang.

Die Registrierung teilt GL4 mit, welches Quellobjekt es aufbereiten darf und wie es damit umgehen soll. Ein technischer Administrator gibt Server, Datenbank, Schema und Tabelle sowie die relevanten Einstellungen für Identität und Änderungserkennung an.

CIRMS validiert die Registrierung, statt jede Tabelle als geeignet zu betrachten. Ein registriertes Objekt ist eine vereinbarte Eingabe, keine Erlaubnis, jede Datenbank oder Datei der Organisation zu kopieren.

Identität fragt: „Welcher Datensatz ist das?“ Änderungserkennung fragt: „Was hat sich seit dem letzten Lesen geändert?“

Diese Trennung hilft CIRMS, die Dokumenthistorie zu verfolgen, ohne einen geänderten Datensatz mit einem vollständig neuen zu verwechseln.

SOURCE_KEY verwendet einen geeigneten Quellschlüssel, beispielsweise einen passenden Primärschlüssel oder eindeutigen Schlüssel, um einen Datensatz zu erkennen. KEYLESS verwendet eine unterstützte Strategie, wenn kein nutzbarer Quellschlüssel vorhanden ist. AUTO überlässt dem Registrierungsprozess die Ermittlung einer unterstützten Auswahl.

KEYLESS bedeutet nicht, dass „Identität keine Rolle mehr spielt“. Ähnlich aussehende doppelte Zeilen und Aktualisierungen erfordern eine andere Behandlung, wenn die Quelle keinen stabilen Schlüssel besitzt. Auch AUTO umgeht die Validierung nicht.

Das sind Methoden, um Änderungen an der Quelle zu erkennen. Die geeignete Wahl hängt von der Quelle und der konfigurierten CIRMS-Strategie ab.

Change Tracking

Identifiziert geänderte Zeilen, damit ihre aktuellen Werte gelesen werden können. Es ist keine vollständige Historie aller Zwischenwerte.

CDC — Change Data Capture

Erfasst Informationen zu Einfügungen, Aktualisierungen und Löschungen für den konfigurierten Erfassungsumfang der Datenbank.

Rowversion

Ein von der Datenbank erzeugter Änderungswert für eingefügte oder aktualisierte Zeilen. Er ist keine Uhrzeit und protokolliert für sich allein keine gelöschten Zeilen.

Watermark

Eine gespeicherte Fortschrittsmarkierung, etwa ein geeigneter Änderungswert, anhand derer spätere Datensätze ausgewählt werden. Ihre Zuverlässigkeit hängt von den Regeln der Quelle ab.

Vollständiger Snapshot

Ein Lesen des aktuellen Datenbestands im festgelegten Umfang, der mit einem zuvor akzeptierten Zustand verglichen werden kann.

Eine Einstellung ist nur nutzbar, wenn ihre Voraussetzungen und ihr Erfassungsumfang gültig sind. Keine Methode sollte eine nicht lesbare Quelle stillschweigend als scheinbare Massenlöschung interpretieren.

Datenbankgrundlagen: Change Tracking, CDC und rowversion. Diese erläutern die Datenbankkonzepte, nicht eine universelle Quellenunterstützung durch CIRMS.

Metadaten sind Informationen über die Daten. Ein Schema beschreibt ihre Struktur: Spaltennamen, Typen, zulässige leere Werte und Schlüssel.

GL4 prüft die Struktur, damit eine veränderte Quelle nicht auf Grundlage einer veralteten Annahme aufbereitet wird. Eine Spaltenumbenennung und ein geänderter Wert innerhalb derselben Spalte sind unterschiedliche Arten von Änderungen.

Die Aktualisierungshäufigkeit wird durch den Zeitplan der Bereitstellung und die Quellenstrategie bestimmt. Ein Dashboard kann das zuletzt aufgezeichnete Ergebnis zeigen, ohne die Quelle in genau dieser Sekunde abzubilden.

Prüfen Sie den letzten erfolgreichen Scan, den Objektstatus und die Stufenlaufzeiten, wenn Aktualität wichtig ist. Die Quellgröße, die Änderungsmenge und die Verarbeitungskapazität beeinflussen, wie schnell ein Lauf endet; es gibt kein allgemeines Versprechen einer „sofortigen“ Aktualisierung.

Ein Scan ist ein Verarbeitungslauf für die ausgewählten registrierten Quellen. CIRMS beginnt die Nummerierung bei null, sodass die Stufen 0 bis 7 acht Stufen bilden.

Die Reihenfolge lautet Quellmetadaten → Rohdaten → Kuratierung → KI-Dokumente → Chunks → Vektor-Embeddings → semantische Validierung → Abschluss der Bereitschaftsprüfung. Ein Scan kann mehrere Quellobjekte umfassen; Ergebnisse werden sowohl auf Lauf- als auch auf Objektebene erfasst.

Ein Lauf ohne geeignete Aufgaben ist etwas anderes als ein fehlgeschlagener Lauf oder ein Lauf, der neues Wissen aufbereitet hat.

Eingabe: Die registrierte Quelle und ihre aktuelle Definition. Arbeit: Struktur, Schlüssel und relevante Extraktionsannahmen prüfen, bevor die Quelle in den Aufbereitungsfluss eingelesen wird.

Ergebnis: Eine aktualisierte Quelldefinition und ein Validierungsergebnis. Im Speicherbeispiel prüft CIRMS, ob die erwarteten Spalten für Server und freien Speicherplatz weiterhin vorhanden sind und verarbeitet werden können. Eine fehlende Tabelle oder nicht unterstützte Struktur wird nicht stillschweigend als leerer Datenbestand akzeptiert.

Eingabe: Eine geeignete Quelle und eine unterstützte Erfassungsstrategie. Arbeit: Die für den Lauf benötigten Quelldaten in den Rohdatenbereich der Aufbereitung laden.

Ergebnis: Erfasste Eingaben für die nächste Stufe. „Roh“ bedeutet, dass sie erfasst wurden, nicht dass sie bereits jede Aufbereitungsprüfung bestanden haben. Ein Snapshot liest den aktuellen Zustand im festgelegten Umfang; eine inkrementelle Strategie verwendet ihren unterstützten Änderungsmechanismus.

Eingabe: Rohdaten und die erwartete Struktur. Arbeit: Das physische Schema validieren und die konfigurierten Aufbereitungsregeln anwenden, um einen konsistenten kuratierten Datenbestand zu erzeugen.

Ergebnis: Strukturierte Daten, die sich zur Dokumenterzeugung eignen. Ein Speicherwert braucht ein konsistentes Feld und einen konsistenten Typ; eine strukturelle Abweichung muss sichtbar werden. Kuratierung ist keine Erlaubnis, einen fehlenden Messwert zu erfinden oder die Originalquelle stillschweigend umzuschreiben.

Eingabe: Der kuratierte Datenbestand. Arbeit: Eine Dokumentdarstellung erstellen und mit dem Quelldatensatz, seiner Identität und Versionshistorie verknüpfen.

Ergebnis: KI-Dokumente und die jeweiligen aktuellen oder historischen Versionen. Beispielsweise kann ein aufbereiteter Datensatz APP-01 zusammen mit seinem erfassten Speicherwert beschreiben. Neue und unveränderte Inhalte sollten nicht als dieselbe Art von Ereignis gezählt werden.

Eingabe: Eine geeignete Dokumentversion. Arbeit: Mithilfe der konfigurierten Chunking-Regeln handhabbare Inhaltsteile erzeugen und ihre Verbindung zum Dokument erhalten.

Ergebnis: Chunks für die nächste Stufe, wobei neue und wiederverwendbare Inhalte unterschieden werden. Ein kurzes Dokument kann ein Teilstück ergeben, ein längeres mehrere. Die Anzahl hängt von Inhalt und Konfiguration ab, nicht von einer festen Regel „eine Zeile gleich ein Chunk“.

Eingabe: Geeignete Chunks und eine aktive Vektorisierungskonfiguration. Arbeit: Das konfigurierte Embedding-Verfahren anwenden, um numerische Darstellungen zu erzeugen.

Ergebnis: Vektoren, die ihren Chunks und ihrer Konfiguration zugeordnet sind. Eine kompatible Konfiguration muss verfügbar sein; eine fehlende Konfiguration ist kein Grund, Vektoren zu erfinden oder die Anforderung zu überspringen. Einen Vektor zu erzeugen ist auch nicht dasselbe wie die späteren Retrieval- und Bereitschaftsprüfungen zu bestehen.

Eingabe: Die aufbereiteten Bestände, genehmigte Vektorbeziehungen und der konfigurierte Retrieval-Umfang. Arbeit: Validieren, dass die erforderlichen Retrieval-Pfade die richtigen geeigneten Bestände nutzen und für die ausgeführten Prüfungen strukturell gültige, wiederholbare Ergebnisse liefern.

Ergebnis: Ein Ergebnis der semantischen Validierung, das in der abschließenden Bereitschaftsstufe verwendet wird. Entscheidend sind die Verknüpfungen zwischen Quelle, Dokument, Version, Chunk und Vektor – nicht nur, ob irgendein Vektor existiert.

Eingabe: Die erforderlichen vorherigen Ergebnisse und Freigaben. Arbeit: Die Abschlussanforderungen prüfen und das endgültige Aufbereitungsergebnis für den jeweiligen Umfang protokollieren.

Ergebnis: Ein abgeschlossener Bereitschaftsstatus, der in den Monitoring-Ansichten geprüft werden kann. Nur Stufe 5 oder Stufe 6 abzuschließen ist nicht dasselbe wie den gesamten Lauf abzuschließen. Nicht erfüllte oder fehlende Anforderungen dürfen nicht als erfolgreiche Bereitschaft dargestellt werden.

Ein KI-Dokument ist die aufbereitete Darstellung von Quellinformationen innerhalb der CIRMS-Wissenspipeline. Stellen Sie es sich als beschriftete Informationskarte mit Inhalt und Verknüpfungen zu ihrem Ursprung vor.

Es muss keine PDF- oder Word-Datei sein, und „KI-Dokument“ bedeutet nicht, dass ein Chatbot den Text erfunden hat. Es soll ausgewählte Quelldaten für die späteren Aufbereitungsstufen nutzbar machen.

Ein Dokument ist der fortbestehende Datensatz; eine Version hält seinen Inhalt in einem bestimmten Aufbereitungszustand fest.

Die Historie hilft zu erklären, was sich geändert hat. Historische Versionen sind nicht automatisch die für aktuelles Retrieval geeigneten Versionen.

Ein Chunk ist ein kleinerer Teil eines Dokuments. Ein hilfreicher Vergleich ist ein Absatz aus einem längeren Bericht, dessen Kennzeichnung und Quellenverweis erhalten bleiben.

Kleinere Teile ermöglichen einem Retrieval-Prozess, mit einem relevanten Ausschnitt statt mit einem ganzen langen Dokument zu arbeiten. In CIRMS bleibt ein Chunk mit seiner Dokumentversion verknüpft; er ist kein losgelöster Textteil.

Allgemeine Grundlagen: Microsoft Learn zum Dokument-Chunking ↗.

Nein. Sehr kleine Chunks können Kontext verlieren; sehr große können nicht zusammengehörige Themen vermischen. Die geeignete Größe hängt von den Informationen und dem vorgesehenen Retrieval-Prozess ab.

Overlap bedeutet, etwas Text an den Grenzen benachbarter Chunks zu wiederholen, um Kontext zu bewahren. Das ist eine allgemeine Chunking-Technik, kein Versprechen, dass jede CIRMS-Konfiguration sie nutzt. Mehr Chunks oder mehr Überlappung sind für sich allein kein Beleg für besseres Wissen.

Ein Token ist eine kleine Texteinheit, die ein Sprachmodell verarbeitet. Je nach Tokenizer kann es ein Wort, einen Wortteil, ein Satzzeichen oder eine andere Texteinheit darstellen.

Ein Chunk kann viele Tokens enthalten. Eine Tokenanzahl ist daher keine Anzahl von Dokumenten oder Chunks. Eingabegrenzen des Modells und konfigurierte Textverarbeitungsregeln sind bei der Wahl der Chunkgrößen wichtig.

Ein Vektor ist eine geordnete Liste von Zahlen. Ein Embedding ist eine aus Inhalt erzeugte numerische Darstellung, in einem KI-Retrieval-System üblicherweise durch ein Embedding-Modell.

Denken Sie an Koordinaten auf einer Karte: Sie ermöglichen es einem System, Positionen zu vergleichen. Bei geeigneten semantischen Embeddings können verwandte Inhalte ähnliche Darstellungen besitzen. Die Zahlen sind keine lesbare Antwort, und ihr Nutzen hängt vom konfigurierten Prozess ab.

Allgemeine Grundlagen: Microsoft Learn zu Embeddings ↗.

Nein. Ein Embedding-Modell stellt Inhalte für Aufgaben wie Vergleich und Retrieval als Zahlen dar. Ein dialogorientiertes Sprachmodell erzeugt eine Antwort.

GL4 kann im Rahmen der Aufbereitung konfigurierte Vektor-Embeddings erstellen, ohne eine Chat-Oberfläche bereitzustellen. Dialogbasierte Unterstützung und weitergehende KI-Analysen gehören zur geplanten GL5-Ausrichtung. „KI-bereit“ und „Chatbot verfügbar“ sind unterschiedliche Aussagen.

Semantisch bedeutet: auf Bedeutung bezogen. „Wenig Speicherplatz“ und „Speicher fast voll“ verwenden unterschiedliche Wörter, beschreiben aber verwandte Sachverhalte.

Ein bedeutungsorientiertes Retrieval-Verfahren sucht relevante Inhalte über den exakten Wortlaut hinaus. Ähnlichkeit ist kein Beweis für Wahrheit oder identische Bedeutung. Die semantische Validierung von CIRMS prüft die konfigurierte Retrieval-Vorbereitung; sie darf nicht mit einer menschlichen Faktenprüfung jeder Quellaussage verwechselt werden.

Retrieval bedeutet, relevante aufbereitete Informationen zu finden. Vektor-Retrieval vergleicht numerische Darstellungen; andere Retrieval-Verfahren können Wörter oder strukturierte Filter verwenden.

In CIRMS definiert eine konfigurierte Route den Umfang und die Konfiguration, über die aufbereitetes Wissen ausgewählt und validiert wird. Sie ist kein Netzwerkkabel. Korrekte Quellbeziehungen, geeignete Versionen und genehmigte Vektoren müssen zu diesem Umfang passen.

Allgemeine Grundlagen: Microsoft Learn zum Vektor-Retrieval ↗.

Die Datenherkunft dokumentiert, wo Informationen entstanden sind und wie sie aufbereitet wurden. Nachvollziehbarkeit ist die Fähigkeit, diesen Verknüpfungen zu folgen.

Ein Herkunftsnachweis ist ein nützlicher Beleg, ersetzt aber nicht die Prüfung von Zugriff, Aktualität oder Richtigkeit der Originaldaten.

Anreicherung ergänzt nützlichen Kontext wie Quellidentität, Einheiten oder eine Kategorie. Semantische Kennzeichnung fügt bedeutungsbezogene Labels hinzu. Ein kanonisches Modell ist eine gemeinsame Struktur, die unterschiedlich organisierte Daten konsistent macht.

Beispielsweise verhindert die Festlegung, ob ein Speicherwert in Bytes oder Gigabytes angegeben ist, eine mehrdeutige Zahl. In CIRMS ergibt sich das tatsächliche Ergebnis aus konfigurierten Metadaten und Aufbereitungsregeln. Diese Begriffe bedeuten nicht, dass GL4 automatisch jede Abteilung versteht oder ein universelles Unternehmensdatenmodell erfindet.

RAG bedeutet Retrieval-Augmented Generation. Bei diesem allgemeinen KI-Muster findet ein System relevantes Material und stellt es einem Modell als Kontext bereit, bevor das Modell eine Antwort erzeugt.

GL4 bereitet Wissensbestände auf, die eine solche nachgelagerte Nutzung unterstützen können. Ein vollständiger Assistent benötigt außerdem Retrieval-Integration, ein Modell, Berechtigungen und Kontrollen für die Antworten. RAG ist kein Synonym für GL4 und bedeutet nicht, dass ein CIRMS-GL5-Assistent bereits veröffentlicht wurde.

Allgemeine Grundlagen: Microsoft Learn zu RAG ↗. Externe Beispiele sind keine Aussagen über eine eingebaute CIRMS-Integration.

Diese Begriffe beschreiben den Vergleich akzeptierter Quelldaten mit dem relevanten früheren Zustand: eingefügt bedeutet neu vorhanden, aktualisiert bedeutet geändert, gelöscht bedeutet als entfernt erkannt, und unverändert bedeutet, dass nach den konfigurierten Regeln keine Inhaltsänderung festgestellt wurde.

Die mögliche Interpretation hängt von Zeilenidentität und Änderungserkennung ab. Ohne stabilen Schlüssel muss eine scheinbare Bearbeitung möglicherweise als entfernter und neu vorhandener Inhalt statt als Aktualisierung eines stabilen Datensatzes dargestellt werden.

Weil sich ein bestehendes Dokument ändern kann, ohne eine neue Dokumentidentität zu erhalten. Bei stabiler Quellidentität erzeugt eine Aktualisierung neuen aufbereiteten Inhalt für denselben fortbestehenden Datensatz.

Neue Chunks sind neu erzeugte Inhaltsteile. Wiederverwendete Chunks sind bestehende Teile, die nach den jeweiligen Inhalts- und Konfigurationsprüfungen weiterhin geeignet sind.

Wiederverwendung vermeidet unnötige Wiederholung derselben Arbeit. Sie bedeutet nicht, dass alte Inhalte immer wiederverwendet werden: Ein geändertes Dokument, eine Chunking-Regel oder eine andere Abhängigkeit kann eine Neuerzeugung erfordern. Betrachten Sie die Zähler für neue und wiederverwendete Chunks zusammen mit dem Verarbeitungsumfang.

Sie zählen unterschiedliche Dinge. Eine Dokumentversion kann mehrere Chunks erzeugen. Historische Versionen und unterschiedliche Konfigurationen können die Gesamtzahlen ebenfalls beeinflussen. Daher sollten Quellzeilen, Dokumente, Chunks und Vektoren nicht mit gleicher Anzahl erwartet werden.

Erzeugt bedeutet, dass eine numerische Darstellung existiert. Freigegeben bedeutet, dass sie die für ihre vorgesehene Nutzung geltenden Eignungs- und Validierungsregeln bestanden hat.

Ein Vektor kann existieren, ohne aktuell, freigegeben oder korrekt mit der erforderlichen Route verknüpft zu sein. Deshalb ist die Gesamtzahl der Vektoren nicht gleich der Anzahl einsatzbereiter Vektoren. Ältere Versionen können außerdem als Historie erhalten bleiben, ohne für aktuelles Retrieval geeignet zu sein.

Ein wiederholter Lauf kann den aktuellen Zustand validieren, ohne neue Dokumentinhalte, Chunks oder Vektoren zu erzeugen, sofern die bestehenden Bestände weiterhin geeignet sind.

„Keine neuen Inhalte“ kann ein einwandfreies Ergebnis sein. Es ist kein Grund, notwendige Prüfungen zu überspringen. Eine geänderte Konfiguration oder ungültig gewordene Freigaben können weiterhin Verarbeitung erfordern, auch wenn die Quellwerte unverändert sind.

GL4 aktualisiert Quellmetadaten und prüft die erwartete Aufbereitungsstruktur. Eine unterstützte Änderung kann nach den geltenden Regeln verarbeitet werden; eine nicht unterstützte oder inkonsistente Struktur muss gemeldet statt stillschweigend als gültig behandelt werden.

Ein entfernter Schlüssel kann die Identität beeinflussen, während ein geänderter Spaltentyp die Extraktion oder Kuratierung betreffen kann. Der Administrator sollte vor dem erneuten Lauf das fehlerhafte Objekt und die Regel prüfen. Diese FAQ verspricht keine automatische Akzeptanz jeder Schemaänderung.

Nein. Eine leere Quelle wurde erfolgreich gelesen und enthält keine Zeilen im festgelegten Umfang. Eine fehlende Tabelle, ein nicht verfügbarer Server oder eine verweigerte Berechtigung bedeutet, dass der Quellzustand nicht festgestellt werden konnte.

Ein Lesefehler darf nicht als Bestätigung interpretiert werden, dass alle Zeilen gelöscht wurden. Auch tatsächlich leere Eingaben unterliegen den geltenden Verarbeitungs- und Bereitschaftsregeln; sie erfüllen nicht automatisch jede Retrieval-Anforderung. „Keine registrierten Aufgaben“ ist eine dritte, eigenständige Situation.

AI_READY ist ein CIRMS-Aufbereitungsstatus für einen definierten Umfang. Er zeigt an, dass die geltenden Aufbereitungs- und Validierungsanforderungen erfüllt wurden.

Es ist keine offizielle Zertifizierung, keine Garantie sachlicher Richtigkeit und kein Versprechen, dass ein KI-Modell immer richtig antwortet. Prüfen Sie zur Beurteilung der Nutzbarkeit auch die Aktualität der Quelle, das letzte Ausführungsergebnis und mögliche Zustandsprobleme.

Sie beantworten unterschiedliche Fragen. Bereitschaft: Gibt es einen akzeptierten aufbereiteten Wissensstand? Letzte Ausführung: War der jüngste Lauf erfolgreich? Systemzustand: Gibt es ein Problem, das Aufmerksamkeit erfordert?

Lesen Sie diese Signale gemeinsam, statt sich auf einen einzelnen grünen Status zu verlassen.

Beginnen Sie beim betroffenen Quellobjekt, der Stufennummer und dem protokollierten Fehler. Prüfen Sie Zugriff, Quellstruktur, Registrierungsoptionen und die für diese Stufe erforderliche Konfiguration.

Beheben Sie die Ursache und verwenden Sie das unterstützte Verfahren für einen erneuten Lauf. Spätere Stufen, die von fehlerhaften Ausgaben abhängen, dürfen keinen Erfolg vortäuschen. Ob andere Objekte weiterverarbeitet und welche Bestände erhalten werden, hängt von den Verarbeitungsregeln ab; ein Fehler ist kein Grund, jede intakte Quelle blind neu aufzubauen.

Einen Datensatz aus dem aktuellen Wissensstand zu entfernen und jede historische Kopie zu löschen sind unterschiedliche Vorgänge. Eine Quelllöschung kann aufbereitete Inhalte inaktiv oder für die aktuelle Nutzung ungeeignet machen, während historische Datensätze nach den konfigurierten Lebenszyklusregeln erhalten bleiben.

Ein separater Aufbewahrungs- oder Entfernungsprozess ist erforderlich, wenn Historie, abgeleitete Bestände und Backups berücksichtigt werden müssen. Ein „inaktiv“-Label ist kein Beweis dafür, dass jede Kopie physisch gelöscht wurde.

Die Architektur ist für modulare Integration mit bestehenden operativen Systemen ausgelegt. Eine Bereitstellungsanalyse klärt die tatsächlich unterstützten Schnittstellen, Authentifizierung, Berechtigungen, Datenstrukturen und Aufgaben.

Bringen Sie eine Liste der relevanten Datenbanken, Betriebssysteme, Anwendungen und gewünschten Aktionen mit. Ein Diagramm mit „Datenbanken“ oder „Anwendungen“ bedeutet nicht, dass jeder Anbieter, jede Version oder API automatisch unterstützt wird.

Ja, die Architektur unterstützt einen klar abgegrenzten Einstieg. Beginnen Sie mit vereinbarten Ressourcen und Aufgaben und prüfen Sie bei wachsendem Bedarf zusätzliche Module, Datenquellen oder HERCULES-Umgebungen.

Eine umfassendere Koordination kann das HERCULES–ATLAS-Modell nutzen. Erweiterung erfordert weiterhin Kapazitätsplanung, Zugriffsprüfung und Tests; „skalierbar“ ist kein Versprechen unbegrenzter Arbeitslast auf unveränderter Hardware.

Jede Extraktions- oder Aufbereitungsarbeitslast kann Ressourcen beanspruchen. Die Auswirkungen hängen von Datenvolumen, gewählter Änderungsstrategie, Abfragedesign, Zeitplanung und verfügbarer Kapazität ab.

Vereinbaren Sie einen kleinen Anfangsumfang, messen Sie ihn und wählen Sie vor der Erweiterung einen passenden Zeitplan. Inkrementelle Verarbeitung kann dort, wo sie unterstützt wird, wiederholte Arbeit reduzieren, aber es gibt keine allgemeine Garantie für keinerlei Auswirkungen.

Menschen entscheiden, welche Ressourcen verbunden werden, welche Arbeit autorisiert ist und wie Ergebnisse geprüft werden. CIRMS liefert Ausführungsergebnisse, Prüfungen, Stufen und Berichte, um diese Arbeit nachvollziehbar zu machen.

Automatisierung überträgt die Verantwortung nicht von der Organisation weg. Bei geplanter KI-Unterstützung müssen Menschen außerdem zulässige Nutzungen definieren und folgenreiche Empfehlungen vor dem Handeln prüfen.

Nein. Der Zugriff sollte der vereinbarten Aufgabe entsprechen. Quelldaten zu lesen, einen Dienst zu prüfen und ein System zu verändern erfordert unterschiedliche Berechtigungen.

Die Bereitstellung muss Dienstkonten, erlaubte Aktionen, Netzwerkzugriff und die Zuständigkeit für Konfiguration oder Ausführung definieren. Eine fehlgeschlagene Zugriffsprüfung sollte gezielt behoben werden; sie rechtfertigt keine ungeprüfte Vergabe umfassender Administratorrechte.

Keine Produktfunktion ist eine pauschale Garantie. CIRMS-Zustandsprüfungen, Ausführungsprotokolle und Berichte können Teams helfen, Bedingungen zu untersuchen und Nachweise zu sammeln.

Zugriffskontrollen, Verbindungssicherheit, Protokollierungsumfang, Aufbewahrung und Betriebsabläufe müssen weiterhin für die Bereitstellung konfiguriert und geprüft werden. Ein Dashboard-Status ist keine Sicherheitszertifizierung, und diese FAQ behauptet weder universelle Anomalieerkennung noch eine vollständige Aufzeichnung jeder Benutzeraktion.

Die Dokumenthistorie ersetzt keinen Sicherungs- und Wiederherstellungsplan. Eine ältere Dokumentversion aufzubewahren beweist nicht, dass Datenbanken, Konfiguration oder Dienst nach einem Vorfall wiederhergestellt werden können.

Unterstützte betriebliche Aufgaben können Arbeiten und Prüfungen rund um Backups einschließen. Wiederherstellungsverfahren, Wiederherstellungsziele und Kontinuitätsmaßnahmen müssen jedoch vereinbart und getestet werden. Das Multi-ATLAS-Modell bleibt eine geplante Architekturrichtung, kein garantierter Failover-Dienst für den Produktivbetrieb.

Aufbereitete Daten gehören in die für die Bereitstellung konfigurierte Umgebung und die zugehörigen Dienste. Eine Quelle zu registrieren bedeutet für sich allein nicht, dass sie im Internet veröffentlicht wird.

Prüfen Sie, wo Rohdaten, Dokumente, Chunks und Vektoren gespeichert werden, wer darauf zugreifen kann und welche Embedding-Dienste Inhalte erhalten. Nehmen Sie weder an, dass sämtliche Verarbeitung lokal erfolgt, noch dass alle Daten an einen Cloud-Dienst gesendet werden: Diese Entscheidungen müssen für die tatsächliche Installation festgelegt werden.

Nein. Inhalt als Vektor zu codieren ist keine Verschlüsselung und kein zuverlässiger Weg, sensible Informationen zu anonymisieren.

Dokumente, Chunks, Metadaten und abgeleitete Darstellungen sollten gleichermaßen in Zugriffs- und Lebenszyklusentscheidungen einbezogen werden. Behandeln Sie die Wissenspipeline als Teil der Informationsumgebung der Organisation, nicht als einen Ort, an dem Daten automatisch ihre Sensibilität verlieren.

Gehen Sie nicht von universeller Kompatibilität aus. Unterstützte Laufzeitumgebungen, Module, Datenbankplattformen und Integrationspfade hängen von der Installation und der bereitgestellten Funktionalität ab.

CIRMS besitzt eigene Dashboard- und Berichtsansichten. Anforderungen mit Python, Java, .NET, Power BI, Tableau oder anderen Werkzeugen sollten ausdrücklich geprüft werden, einschließlich erforderlicher Schnittstelle und Sicherheitskontrollen, statt sie aus einer älteren Marketingliste abzuleiten.

CIRMS GL5 ist geplante Entwicklung. Die aktuelle Website stellt GL3-Automatisierung und GL4 AI Data Readiness getrennt von dieser geplanten Intelligenzerweiterung dar.

Illustrationen zur KI-Unterstützung sind Konzepte, keine Screenshots eines veröffentlichten GL5-Chatbots. Verfügbarkeit, Umfang und Lieferzusagen müssen im Rahmen eines konkreten Produktgesprächs bestätigt werden.

Geplant ist, KI-Modelle und dialogbasierte Unterstützung mit dem durch GL3 und GL4 aufbereiteten Wissen zu verbinden.

Vorgesehene Anwendungen umfassen Hilfe beim Finden von Informationen, Untersuchen betrieblicher Fragen, Prüfen abteilungsübergreifender Erkenntnisse und Abwägen von Empfehlungen. Das sind Roadmap-Ziele mit menschlicher Aufsicht, kein Versprechen, dass jede dargestellte Funktion bereits umgesetzt ist.

Nein. CIRMS sollte weder als künstliche allgemeine Intelligenz noch als autonomes System dargestellt werden, das alles versteht und kontrolliert.

Die aktuellen GL3- und GL4-Verantwortlichkeiten sind definierte betriebliche Arbeit und Wissensaufbereitung. Der geplante GL5-Umfang ist KI-Unterstützung auf dieser Grundlage. Ältere Verweise auf einen automatischen Übergang zu AGI dürfen nicht als aktuelle Funktion oder garantierte künftige Fähigkeit verstanden werden.

Nicht für sich allein. Das Erstellen von Embeddings wendet einen konfigurierten Prozess auf Inhalte an, um Darstellungen zu erzeugen. Das unterscheidet sich vom Training oder Fine-Tuning eines Modells.

Ein zukünftiger Assistent benötigt eigene Modell- und Integrationsentscheidungen. Auch der Umgang des Anbieters mit übermittelten Inhalten muss separat geprüft werden; diese FAQ verspricht nicht, dass alle möglichen Anbieter identische Trainings- oder Aufbewahrungsrichtlinien haben.

Wählen Sie ein eng umrissenes, wiederholbares Problem: beispielsweise vereinbarte betriebliche Prüfungen und einen klar identifizierten Datenbestand, den das Team derzeit manuell zusammenstellt.

Definieren Sie die erwartete Ausgabe, verbinden Sie nur den genehmigten Umfang und validieren Sie die GL3-Ergebnisse. Wo KI-Datenaufbereitung relevant ist, registrieren Sie geeignete Quellen in GL4 und prüfen Sie den vollständigen Lauf. Erweitern Sie erst, wenn das Team die Ausgabe und ihre Betriebsanforderungen versteht.

Nutzen Sie die Kontaktseite oder senden Sie eine E-Mail an office@tohol.org mit einer kurzen Beschreibung Ihrer Umgebung, des betrieblichen Problems und der Angabe, ob Sie GL3, GL4 oder die geplante GL5-Roadmap erkunden.

Eine hilfreiche Vorführung verfolgt eine Aufgabe und eine Quelle durch die relevanten Ansichten. Fragen Sie, was bereits verfügbar ist, was konfiguriert werden muss und was noch geplant ist. Senden Sie bei einer ersten Anfrage keine Passwörter, privaten Schlüssel oder vertraulichen Produktivdatenbestände.