Prompts

Was Sie hier erledigen

1 2 3 4

Marker	Element	Bedeutung
1	Datenanalyse	Promptgruppe für Extraktion, Fakten und Dokumentanalyse.
2	Promptliste	Wählt einen Eintrag; die Liste ist nach LLM-Prompts, Texten und Strukturdaten gruppiert.
3	Editor	Bearbeitet je nach Typ Prompttext, Text-Bundle oder JSON-Daten.
4	Validieren, Speichern, Reset	Prüft je nach Typ Platzhalter, Textabschnitte oder JSON und verwaltet Änderungen.

Abb. P-01 zeigt die Datenanalyse-Sicht vor der Erklärung der Promptpflege. Die Liste wählt den Eintrag, der Editor rechts zeigt je nach Ressourcentyp System- und User-Nachrichten, Textinhalt oder JSON-Daten sowie Validierungsaktionen.

• Datenanalyse-Prompts, Ablauf-Prompts, Text-Bundles und Strukturdaten auswählen und bearbeiten.
• Bei LLM-Prompts System-Nachricht, User-Nachricht und Laufzeitparameter pflegen.
• Bei Texten und Strukturdaten nur den fachlichen Inhalt bearbeiten; LLM-Parameter sind dort nicht sichtbar.
• Prompt-Änderungen speichern, auf Standard zurücksetzen oder als neuen Standard sichern.
• Warnhinweise prüfen und Änderungen immer testen.

Aufbau

1 2 3 4

Marker	Element	Bedeutung
1	Ablauf-Sicht	Wechselt zu Prompts, die Dialogschritte steuern.
2	Ressourcenauswahl	Öffnet den relevanten Ablaufprompt, Text oder Datensatz.
3	Inhalt	Beschreibt Verhalten, Stil, benötigte Platzhalter, Textabschnitte oder JSON-Struktur.
4	Aktionen	Validiert typgerecht, speichert oder setzt auf Standard zurück.

Abb. P-02 steht vor der Beschreibung der Ablauf-Ressourcen. Diese Sicht betrifft die Chatführung und sollte immer mit Testen und Debug gegengeprüft werden.

• Datenanalyse enthält Prompts für Auswertungen aus Quellen und Fachinhalten. Die Liste ist zusätzlich nach Ressourcentypen gruppiert.
• Ablauf enthält LLM-Prompts, strukturierte Texte und Strukturdaten für den Beratungsdialog.
• Der Flow-Selector steht aktuell auf Startberatung oder Serviceberatung & Formularassistenz.
• Links wählen Sie den Eintrag, rechts bearbeiten Sie Editor und Einstellungen.

Ressourcentypen

Der Badge Gemeinsam bedeutet, dass eine Ressource in mehreren Abläufen verwendet wird. Bei service_rerank betrifft eine Änderung zum Beispiel Startberatung und Serviceberatung.

Promptgruppen

Diese fachlichen Gruppen sind von den Ressourcentypen unabhängig: Ein Ablauf kann zum Beispiel LLM-Prompts, Text-Bundles und Strukturdaten enthalten. Quellenpaket-Prompts und source_change_search sind normale sichtbare Datenanalyse-Prompts. Sie sind nicht versteckt, weil fachliche Redaktion nachvollziehen können muss, wie Quellenpakete ausgewertet, zusammengeführt und Originalabsätze für die Vorprüfung 🔎 PRE semantisch geprüft werden. source_change_search bewertet fachliche Aussagen auf widersprechende Originalabsätze; Begriffstreffer werden zusätzlich durch die systemseitige Textsuche gefunden.

Der Prompt service_aggregation_source verlangt pro Item genau einen fachlichen Aspekt. Er trennt insbesondere Antragstellung, Fristen, Mitteilungspflichten, Nachweise, Einkommensgrenzen, Förderhöhe und Auszahlung. Regelrelevante Tabellen müssen als vollständige Markdown-Tabelle mit benannter Dimension und allen Wertespalten ausgegeben werden; mehrere Stufen derselben Zeile dürfen nicht auf eine einzelne Grenze reduziert werden. Nebeneinander dargestellte Haushaltsfälle einer Einkommenstabelle werden als einzelne Zeilen ausgegeben. Einheit, Netto-/Bruttobasis, Zeitraum, Bedingungen, Fußnoten beziehungsweise Fortschreibungen und explizite Anlagen- oder Paragraphenbezüge bleiben bei der Tabelle; der nächste fachliche Abschnitt darf nicht als Teil der Tabelle übernommen werden. Die allgemeine Kurztextgrenze gilt nicht, wenn sie vollständige Tabellenzellen abschneiden würde. Zeitbezüge wie pro Monat, pro Jahr, Dauer, Stichtag oder Gültigkeitszeitraum müssen zusammen mit dem zugehörigen Betrag, Grenzwert oder Vorgang belegt werden. Eine monatliche Auszahlung darf beispielsweise nicht als Monatsbezug einer benachbarten Einkommensgrenze verwendet werden.

Der Prompt facts_glossary_terms arbeitet mit den vollständigen aggregierten Quellinformationen des ausgewählten Services. Der ausgelieferte Standard erzeugt höchstens 15 kuratierte, quellenbelegte Fachbegriffe. Reine Kontaktdaten, einzelne Werte und allgemeine Verfahrenswörter sollen nicht als Glossarkarten entstehen; nummerierte Fachstufen bleiben getrennt.

Sicher arbeiten mit Prompts

1. Eintrag auswählen und zuerst Ressourcentyp sowie den Block Verwendung lesen.
2. Änderung klein halten und Platzhalter, Pflichtabschnitte oder JSON-Struktur nicht entfernen.
3. Speichern und Validierungswarnungen bewusst prüfen.
4. Mit typischen Anliegen in Testen gegenprüfen.
5. Bei unerwartetem Verhalten in Debug API/LLM und Workflow ansehen.
6. Bei Unsicherheit auf Standard zurücksetzen.

Referenz: Felder und Einstellungen

Analyse Voraussetzungen erwartet als Standard eine reine JSON-Liste. Jeder Eintrag enthält eine Bezeichnung und mindestens eine Frage; jede Frage enthält Parameter-ID, Fragetext, Beschreibung und einen der Antworttypen yes_no, number, date oder text. Der eindeutige Modellalias currency wird wie number behandelt. Quellenbezug, erwartete Antwort, Routing, enger Entscheidungsbeleg und Review-Hinweise sind optional. Eine in derselben Quellenbedingung belegte ODER-Alternative bleibt eine gemeinsame Ja/Nein-Voraussetzung; ihre Aufteilung in globale Einzelvoraussetzungen würde die fachliche ODER-Verknüpfung fälschlich in ein UND verwandeln.

Für Analyse Voraussetzungen – atomar reparieren gilt derselbe Pflichtvertrag: Das Fragenarray darf nicht leer sein und jede Frage verwendet die Felder parameter_id, question, description und response_type. Das abweichende Feld question_text ist keine gültige Repair-Ausgabe. Bei einer weiterhin belegten Bestandsbedingung erhält der Repair zusätzlich deren erforderliche Rohdatenfragen, Parameter und Fachdimensionen; eine Einkommensstaffel darf dadurch nicht auf eine einzelne Einkommensfrage verkürzt werden, wenn auch Erwachsenen- und Kinderzahl benötigt werden. Jeder übergebene Verstoß ist einzeln abzuarbeiten. Ein leeres Ergebnis ist nur zulässig, wenn der fokussierte Quellenkontext die Reparatur nicht belegt oder widersprüchlich ist; diese Unsicherheit bleibt zur fachlichen Prüfung offen. Eingaben einer Voraussetzung neu ableiten wird ausschließlich beim manuellen Einzelregel-Neuaufbau verwendet. Eine oder mehrere ausgewählte aktive Wissenskarten dienen dort als Strukturhinweise; alle fachlichen Werte müssen zusätzlich in der aktuellen Quellenaggregation vorkommen. Direkt beantwortbare Mindestdauern bleiben vollständige Ja/Nein-Fragen und erhalten expected_answer=ja sowie einen source-belegten eq/true-Entscheidungsbeleg; ein fehlender Beleg wird höchstens einmal gezielt korrigiert. Bei anderen eigenständigen Ja/Nein-Bedingungen kann der belegte Erfüllungswert true oder false sein. Reine Berechnungs-, Zähl- und Umklassifizierungshinweise dürfen nicht als eigenständige Ja/Nein-Prüfung ausgegeben werden.

Der Prompt Analyse Voraussetzungen verwendet 6.000 Tokens und den Denkaufwand Niedrig. Er darf für eine vollständig belegte atomare Prüfung zusätzlich Operator, typisierten Wert, Ergebnis und ein wörtliches Quellenzitat liefern; bei Zahlen gehören Einheit und gegebenenfalls Bezugsperiode dazu. Bei Einkommensangaben muss die sichtbare Frage selbst die belegte Netto-/Bruttobasis, Person-/Haushaltsdimension und Monats-/Jahresperiode nennen. Eine Angabe nur in Beschreibung, Parameter-ID oder Decision-IR reicht nicht. Eine fehlende oder widersprüchliche Periode wird als source_dependency zur Prüfung offengelassen und nicht aus der Betragshöhe geraten. Nur dann kann AIA3 die Regel ohne freien Regel-Prompt direkt aufbauen. Die ergänzenden Prompts Analyse Voraussetzungen – kompakter Fallback mit 6.000 Tokens und Analyse Voraussetzungen – atomar reparieren mit 5.000 Tokens werden nur innerhalb des begrenzten Harvest-Ablaufs verwendet und nutzen ebenfalls niedrigen Denkaufwand: Der Fallback erhält einen gekürzten, auf Bedingungen konzentrierten Quellenkontext. Vollständig abgeschlossene Einträge am Anfang einer abgeschnittenen Antwort werden nicht direkt gespeichert; nur mit sicher festgestellten Lücken des vorhandenen Bestands dürfen sie gezielt vervollständigt werden. Der Repair teilt ausschließlich die konkret übergebenen Sammelkandidaten, ersetzt eine mit raw_input_required markierte Rechts- oder Grenzwert-Selbsteinschätzung durch belegte Rohdatenfragen oder ergänzt eine weiterhin belegte, im neuen Satz fehlende Bestandsbedingung. Sicher belegte, atomare und vollständig entscheidbare Bestandsbedingungen übernimmt der Server ohne LLM-Neuformulierung und ohne alte Regel-, Status- oder Reviewartefakte. Ist das Kandidatenarray leer, liefert das Modell nur neue Kandidaten für die verbleibenden benannten Lücken und wiederholt den vorhandenen Satz nicht. Es erhält dafür kompakte Kandidaten- und Evidenzdaten sowie nach diesen Belegen priorisierte Originalquellabschnitte und darf keine Schwellen oder Fakten erfinden; eine allgemeinere Aussage darf keine speziellere Bedingung ersetzen. Für Regel für Voraussetzung verwendet der Standard 4.000 Tokens und niedrigen Denkaufwand und erwartet bei komplexeren Fällen ein versioniertes Decision-IR als JSON. Daraus erzeugt der Server Fragenfolge, Verzweigungen, Testfälle und die kompatible Prüfregel gemeinsam. Der Standard verlangt für fachliche Zahlen einen Quellenbezug beziehungsweise eine exakt prüfbare Ableitung und bevorzugt bei vollständigen Staffeln zeilengetreue Tabellen-Lookups. Fehlt eine notwendige Entscheidungsgrundlage, wird sie als fachlicher Reviewfall markiert und nicht durch einen geratenen Wert ersetzt. Decision-IR begrenzt reparieren verwendet 2.000 Tokens mit niedrigem Denkaufwand und darf ausschließlich kleine replace- oder kontrollierte add-Operationen auf serverseitig erlaubten Pfaden liefern; vollständige Ersatzdokumente werden abgelehnt. Der Server übergibt dafür nur relevante IR-Ausschnitte und begrenzte Quellenstellen. Ungültige oder fachlich unvollständige Ergebnisse bleiben inaktiv und zeigen konkrete Prüfhinweise. Manuell gepflegte aktive Promptfelder werden durch ein Deployment nicht überschrieben; Auf Standard zurücksetzen verwendet den aktuellen Repository-Standard.

Die Extraktionsprompts geben ausschließlich fachliche Kandidatenfelder aus. Status, Regeln, Decision-IR, Review- und Validierungsinformationen sind serververwaltet und werden aus einer Modellantwort nicht übernommen. Beim Decision-IR-Repair fasst AIA3 gleichartige Gegenbeispiele kompakt zusammen, hält den gesamten Prompt unter 12.000 Zeichen und kann mehrere kleine zulässige Patches aufeinander aufbauen; geschützte Quellenwerte und Invarianten bleiben dabei unverändert.

Security-Review-Prompt

• Dieser Prompt steuert die semantische Prüfung sicherheitsauffälliger Admin-Inhalte.
• Bearbeiten, Speichern und als Standard setzen sind an audit.write gebunden und werden in der Liste als geschützt markiert.
• Der Prompt wirkt im Admin-Bereich unter Security-Findings, wenn Securitycheck Konfiguration ausgeführt wird.
• Änderungen sollten mit Securitycheck, Testangriff und fachlich erwarteten Fehlalarmen geprüft werden.

Häufige Probleme

• Antworten werden schlechter: Änderung zurücknehmen oder Prompt auf Standard setzen.
• JSON/Struktur ist kaputt: Platzhalter, Formatvorgaben, Temperature und Denkaufwand prüfen.
• Text fehlt im Chat: Beim Text-Bundle prüfen, ob die erwarteten Markdown-Abschnitte noch vorhanden sind.
• Orte oder Regionen werden nicht erkannt: Strukturdaten validieren und auf gültiges JSON prüfen.
• Dialog wird langsam: Denkaufwand, Max. Tokens und LLM-Ziel prüfen.

Querverweise

• Testen für manuelle und automatische Gegenprüfung.
• Debug für API/LLM-Details.
• Admin für Security-Findings und LLM-Konfiguration.