Glossar – Agentic Work in Real Life
Dieses Glossar bündelt die Fachbegriffe der Serie „Agentic Work in Real Life“ und ergänzt einige Begriffe, die im aktuellen AI- und Agentic-Engineering-Diskurs häufig auftauchen, auch wenn sie in den Artikeln selbst nicht im Mittelpunkt stehen.
Die Erklärungen sind bewusst kurz und praxisorientiert. Einige Begriffe – insbesondere AGI, ASI, Agentic AI, Frontier Model, Memory, Skill und Vibe Coding – sind nicht einheitlich normiert und können je nach Anbieter oder Community leicht unterschiedlich verwendet werden.
Produkt-, Modell-, Organisations- und Paper-Namen sind nicht vollständig aufgenommen. Eine Ausnahme bilden Bezeichnungen wie SWE-bench oder ARC-AGI, wenn sie inzwischen selbst als verbreitete Fachbegriffe beziehungsweise Benchmark-Familien verwendet werden.
| Begriff / Akronym | Langform | Kurz erklärt |
|---|---|---|
| Acceptance Criteria | — | Kriterien, anhand derer entschieden wird, ob eine Anforderung oder Änderung fachlich und technisch als erfüllt gilt. |
| Acceptance Test | — | Prüfung, ob ein System oder Feature definierte fachliche Akzeptanzkriterien erfüllt. |
| Accepted Change | — | Änderung, die nach ausreichender technischer und fachlicher Prüfung als akzeptabel übernommen werden kann. |
| Access Control | — | Mechanismen, die steuern, wer oder was auf Daten, Funktionen oder Systeme zugreifen darf. |
| Active Parameters | — | Bei Mixture-of-Experts-Modellen der Teil der gesamten Modellparameter, der für einen konkreten Token beziehungsweise Rechenschritt tatsächlich aktiviert wird. |
| ADR | Architecture Decision Record | Kurzes, versioniertes Dokument, das eine wichtige Architekturentscheidung, ihren Kontext und ihre Begründung festhält. |
| Affected Analysis | — | Ermittlung, welche Projekte, Module oder Tests von einer Änderung tatsächlich betroffen sind, um Arbeit und Verifikation gezielt einzugrenzen. |
| Agent | — | System, das ein Ziel über mehrere Schritte verfolgt und dafür Modell, Context, Tools und weitere Mechanismen kombiniert. |
| Agent File | — | Projekt- oder arbeitsplatzbezogene Instruktionsdatei für Agents, etwa mit Architektur-, Build- oder Arbeitsregeln. Vertieft in Artikel 04. |
| Agent Harness | — | Softwareumgebung, die ein Modell zum Agenten macht, indem sie Context, Tools, Schleifen, Zustände und Ausführung orchestriert. |
| Agent Infrastructure | — | Wiederverwendbare technische und organisatorische Grundlage für Agentic Work, etwa Regeln, Skills, Tests, Tooling und Verifikationsmechanismen. |
| Agent Skill | — | Wiederverwendbares Playbook oder Arbeitsverfahren, das einem Agenten beschreibt, wie eine bestimmte Art von Aufgabe bearbeitet werden soll. |
| Agent Time | — | Zeit, in der ein Agent selbstständig an einer Aufgabe arbeitet. |
| Agent-readable | — | Eigenschaft eines Systems, dessen relevante Struktur, Regeln und Informationen für einen Agenten auffindbar und verständlich bereitgestellt sind. |
| Agent-verifiable | — | Eigenschaft eines Systems, bei dem ein Agent Ergebnisse mit ausführbaren Checks wie Build, Lint, Tests oder Architekturregeln prüfen kann. |
| Agentic AI | — | Sammelbegriff für AI-Systeme, die nicht nur Antworten erzeugen, sondern Ziele über mehrere Schritte verfolgen und Aktionen ausführen können. |
| Agentic Coding | — | Softwareentwicklung, bei der Coding Agents selbstständig Teile des Entwicklungsprozesses wie Analyse, Änderung und Tests übernehmen. |
| Agentic Work | — | Arbeitsweise, bei der AI-Agenten mehrstufige Aufgaben mit einem gewissen Grad an Autonomie bearbeiten. |
| AGI | Artificial General Intelligence | Nicht einheitlich definierter Begriff für AI mit breiten, generalisierbaren Fähigkeiten auf oder nahe menschlichem Niveau über viele Aufgabenbereiche hinweg. |
| AI | Artificial Intelligence | Oberbegriff für Computersysteme, die Aufgaben ausführen, die typischerweise mit Wahrnehmung, Sprache, Lernen, Planung oder Problemlösung verbunden werden. |
| AI Coding Assistant | — | AI-Werkzeug, das Entwickler beim Schreiben oder Verändern von Code unterstützt; im Unterschied zu einem Coding Agent oft mit weniger eigenständiger Tool-Nutzung und Autonomie. |
| AI Safety | — | Forschungs- und Engineering-Feld zur Begrenzung schädlichen, unerwünschten oder unkontrollierten Verhaltens leistungsfähiger AI-Systeme. |
| Alignment | — | Arbeit daran, dass ein AI-System im Sinne der beabsichtigten Ziele, Regeln und menschlichen Aufsicht handelt. |
| Anonymization | — | Veränderung von Daten so, dass Personen nicht mehr identifizierbar sind; tatsächlich anonymisierte Daten sind von pseudonymisierten Daten zu unterscheiden. |
| API | Application Programming Interface | Definierte Schnittstelle, über die Softwarekomponenten oder Dienste miteinander kommunizieren. |
| ARC-AGI | Abstraction and Reasoning Corpus for Artificial General Intelligence | Benchmark-Familie für Generalisierung und das Erlernen neuer Fähigkeiten; ein hoher Score ist kein universeller Nachweis, dass AGI erreicht wurde. |
| Architecture Constraint | — | Architekturregel, die bestimmte strukturelle Lösungen erlaubt oder ausschließt und damit den Lösungsraum begrenzt. Vertieft in Artikel 08. |
| Architecture Review | — | Review mit Fokus darauf, ob eine Änderung zu Verantwortlichkeiten, Grenzen, Abhängigkeiten und Architektur des Systems passt. |
| ASI | Artificial Superintelligence | Hypothetischer Begriff für AI, deren allgemeine kognitive Fähigkeiten menschliche Fähigkeiten deutlich übertreffen; Definitionen variieren. |
| Authorization | — | Entscheidung darüber, ob ein Benutzer, Agent oder System auf eine Ressource oder Aktion zugreifen darf. |
| Benchmark | — | Standardisierte Aufgabe oder Aufgabensammlung, mit der bestimmte Fähigkeiten oder Eigenschaften eines Modells oder Systems gemessen werden. |
| Benchmark Contamination | — | Problem, dass Benchmark-Aufgaben oder sehr ähnliche Daten bereits im Training eines Modells enthalten waren und Ergebnisse dadurch verzerrt sein können. |
| Benchmark Overfitting | — | Überanpassung von Modellen oder Systemen an bekannte Benchmarks, ohne dass sich die allgemeine Leistungsfähigkeit entsprechend verbessert. |
| Big Ball of Mud | — | Bezeichnung für ein System mit schwach erkennbarer Struktur, hoher Kopplung und vielen historisch gewachsenen Ausnahmen. |
| Broken Windows | — | Metapher für die Tendenz, dass sichtbare ungepflegte Ausnahmen oder Regelverstöße weitere ähnliche Abweichungen begünstigen können. |
| Build | — | Prozess, der Quellcode und weitere Artefakte in eine ausführbare oder auslieferbare Form überführt und dabei häufig bereits Fehler sichtbar macht. |
| Cached Tokens | — | Input-Tokens aus wiederkehrendem Context, deren bereits berechnete Zustände ein Anbieter teilweise wiederverwenden kann. |
| CapEx | Capital Expenditure | Investitionsausgaben für länger genutzte Vermögenswerte, etwa eigene AI-Hardware. |
| Chain of Thought (CoT) | Chain of Thought | Bezeichnung für Zwischenschritte des Reasonings eines Modells; sichtbare Zusammenfassungen sind nicht zwingend die interne vollständige Reasoning-Spur. |
| CI | Continuous Integration | Automatisierte Integration und Prüfung von Änderungen, typischerweise mit Build, Lint und Tests. |
| CI/CD | Continuous Integration / Continuous Delivery or Deployment | Automatisierte Pipeline zum Prüfen, Bauen und je nach Ausprägung Bereitstellen oder Ausrollen von Software. |
| Cloud Model | — | AI-Modell, das über Infrastruktur eines externen oder internen Cloud-Anbieters genutzt wird. |
| Coding Agent | — | Agent, der Codebasen untersuchen, Dateien ändern, Tools ausführen, Fehler verarbeiten und zusammenhängende Softwareänderungen erzeugen kann. |
| Cohesion | — | Maß dafür, wie eng die Verantwortlichkeiten innerhalb eines Moduls oder einer Komponente fachlich zusammengehören. |
| Compute Budget | — | Begrenzte Rechenmenge, die für eine Modellanfrage, einen Agent-Run oder eine Evaluation zur Verfügung steht. |
| Computer Use | — | Fähigkeit eines AI-Systems, grafische Benutzeroberflächen ähnlich wie ein Mensch über Maus, Tastatur oder vergleichbare Aktionen zu bedienen. |
| Constraint | — | Explizite Regel oder Grenze, die festlegt, welche Lösungen, Datenflüsse oder Aktionen zulässig sind. |
| Context | — | Informationen, die einem Modell für die aktuelle Verarbeitung tatsächlich zur Verfügung stehen. |
| Context Engineering | — | Gezielte Auswahl, Strukturierung und laufende Pflege des relevanten Contexts für Modelle und Agents. Vertieft in Artikel 04. |
| Context Window | — | Maximale Context-Menge, die ein Modell beziehungsweise ein konkreter Endpunkt in einer Verarbeitung berücksichtigen kann. |
| Contract | — | Explizite Vereinbarung über Schnittstelle, Datenformat, Verhalten oder Verantwortlichkeit zwischen Systemteilen. |
| Converge | — | Phase, in der nach getroffenen Entscheidungen möglichst diszipliniert innerhalb des verbleibenden Lösungsraums umgesetzt wird. Teil von Diverge · Decide · Converge, vertieft in Artikel 10. |
| Coordination Time | — | Menschliche Zeit für Übergaben, Rückfragen, Synchronisation, Context Switching und Koordination zwischen Agents oder Arbeitsschritten. |
| Cost per Accepted Change | — | Engineering-Kennzahl für die gesamten Kosten, bis eine gewünschte Änderung ausreichend geprüft und akzeptiert ist. Vertieft in Artikel 13. |
| Cost per Run | — | Kosten eines einzelnen Modell- oder Agent-Durchlaufs. |
| Cost per Successful Run | — | Kosten pro technisch erfolgreichem Agent-Run, einschließlich der fehlgeschlagenen Versuche, die dafür notwendig waren. |
| Cost per Token | — | Preis beziehungsweise Kosten auf Ebene der vom Modell verarbeiteten oder erzeugten Tokens. |
| Coupling | — | Grad der Abhängigkeit zwischen Modulen oder Komponenten; hohe Kopplung erschwert meist unabhängige Änderungen. |
| CQRS | Command Query Responsibility Segregation | Architekturmuster, das Lesen und verändernde Operationen bewusst voneinander trennt. |
| Credit | — | Produktspezifische Abrechnungseinheit eines AI-Dienstes; technisch nicht dasselbe wie ein Token. |
| CRUD | Create, Read, Update, Delete | Vier grundlegende Operationen zum Anlegen, Lesen, Ändern und Löschen von Daten. |
| Data Minimization | — | Prinzip, nur die Daten zu verarbeiten oder bereitzustellen, die für einen konkreten Zweck tatsächlich notwendig sind. |
| Decide | — | Phase, in der offene Alternativen bewertet und relevante Entscheidungen bewusst getroffen werden. Teil von Diverge · Decide · Converge, vertieft in Artikel 10. |
| Dependency Direction | — | Architekturregel, die festlegt, in welche Richtung Abhängigkeiten zwischen Modulen oder Schichten verlaufen dürfen. |
| Dependency Graph | — | Graphische oder technische Darstellung der Abhängigkeiten zwischen Modulen, Libraries, Services oder anderen Systemteilen. |
| Determinism | — | Eigenschaft eines Systems, bei gleichem Zustand und Input reproduzierbar dasselbe Ergebnis zu liefern. |
| Developer Experience (DX) | Developer Experience | Qualität der Arbeitsumgebung für Entwickler, etwa Verständlichkeit, Tooling, Feedbackgeschwindigkeit und lokale Ausführbarkeit. |
| Diff | — | Darstellung der Unterschiede zwischen zwei Versionen von Dateien oder Code. |
| Discovery | — | Phase des Verstehens und Klärens von Problem, Requirements, offenen Entscheidungen, Risiken und technischem Kontext vor der Umsetzung. |
| Distillation | — | Verfahren, bei dem Wissen oder Verhalten eines größeren Modells in ein kleineres Modell übertragen wird. |
| Diverge | — | Phase, in der mehrere Lösungswege, Hypothesen oder Optionen bewusst geöffnet und untersucht werden. Teil von Diverge · Decide · Converge, vertieft in Artikel 10. |
| DPA / AVV | Data Processing Agreement / Auftragsverarbeitungsvertrag | Vertragliche Regelung zur Verarbeitung personenbezogener Daten durch einen Auftragsverarbeiter. |
| Drift | — | Schrittweise Abweichung von gewünschten Regeln, Architektur, Bedeutung oder Verhalten über mehrere Entscheidungen oder Handlungsschritte – innerhalb eines Runs oder über mehrere Änderungen hinweg. Vertieft in Artikel 06. |
| DRY | Don’t Repeat Yourself | Prinzip, Wissen oder Logik nicht unnötig mehrfach zu duplizieren; keine Aufforderung, jede Ähnlichkeit zwanghaft zu abstrahieren. |
| DSGVO | Datenschutz-Grundverordnung | EU-Verordnung zum Schutz personenbezogener Daten und zu Regeln ihrer Verarbeitung. |
| DTO | Data Transfer Object | Datenstruktur zur Übertragung von Informationen zwischen Systemteilen oder Schnittstellen, meist ohne eigene Geschäftslogik. |
| E2E | End-to-End | Test oder Betrachtung eines vollständigen Ablaufs über mehrere Systemteile hinweg. |
| Embedding | — | Numerische Vektorrepräsentation von Inhalten, mit der semantische Ähnlichkeit oder Beziehungen rechnerisch verglichen werden können. |
| Engineering Capability | — | Fähigkeit einer Person oder Organisation, Software zuverlässig zu verstehen, zu entwickeln, zu verändern, zu prüfen und zu betreiben. |
| Eval | Evaluation | Gezielte Prüfung eines Modells oder Agent-Systems anhand definierter Aufgaben, Kriterien und Messverfahren. |
| Evaluation Harness | — | Infrastruktur, die Evals ausführt, Tools und Umgebungen bereitstellt, Abläufe aufzeichnet und Ergebnisse bewertet. |
| Executable Architecture | — | Architekturregeln, die nicht nur dokumentiert, sondern durch Tools, Tests oder statische Checks mechanisch überprüfbar gemacht werden. |
| Feedback Loop | — | Wiederholter Zyklus aus Ausführung, Beobachtung, Prüfung und Korrektur, durch den Arbeit schrittweise verbessert wird. |
| File Boundary | — | Grenze auf Datei- oder Speicherzugriffsebene; sie garantiert nicht automatisch, dass dieselbe Information nicht über andere Wege erreichbar ist. |
| Fine-Tuning | — | Weiteres Training eines bereits trainierten Modells, bei dem dessen Parameter gezielt angepasst werden. |
| Fixed Cost | — | Kosten, die zunächst unabhängig von der Zahl späterer Nutzungen entstehen, etwa für Agent Infrastructure oder eigene Hardware. |
| Foundation Model | — | Breit trainiertes Grundmodell, das als Basis für viele unterschiedliche Aufgaben und Anwendungen dienen kann. |
| Frontier Model | — | Informeller Begriff für Modelle, die zum jeweiligen Zeitpunkt an der Leistungsgrenze öffentlich oder industriell verfügbarer AI liegen. |
| Function Calling | — | Mechanismus, mit dem ein Modell strukturierte Aufrufe externer Funktionen oder Tools anfordern kann. |
| Generative AI | — | AI-Systeme, die neue Inhalte wie Text, Bilder, Audio, Video oder Code erzeugen. |
| GPU | Graphics Processing Unit | Parallelrechenprozessor, der wegen seiner hohen Matrix-Rechenleistung häufig für Training und Inference von AI-Modellen eingesetzt wird. |
| Ground Truth | — | Referenzwert oder als korrekt angenommene Zielantwort, gegen die ein Modell oder System bewertet wird. |
| Grounding | — | Verknüpfung einer Modellantwort mit konkreten externen Daten, Quellen oder Systemzuständen, um freie Plausibilitätsbildung zu begrenzen. |
| Guardrails | — | Technische oder organisatorische Schutzmechanismen, die unerwünschte Eingaben, Ausgaben oder Aktionen eines AI-Systems begrenzen sollen. |
| Hallucination | — | Plausibel wirkende, aber falsche oder unbelegte Ausgabe eines Modells. |
| Happy Path | — | Idealer Ablauf eines Systems ohne Fehler-, Ausnahme- oder Sonderfälle. |
| Human Active Time | — | Zeit, in der ein Mensch aktiv analysieren, entscheiden, erklären, prüfen oder korrigieren muss. |
| Human Capital | — | Wissen, Fähigkeiten, Erfahrung und Urteilskraft von Menschen als langfristige wirtschaftliche Ressource. |
| Human Review | — | Prüfung eines Ergebnisses durch einen Menschen, insbesondere dort, wo Fachwissen, Verantwortung oder Kontextbewertung notwendig sind. |
| Independent Evidence | — | Prüfevidenz, die nicht nur dieselben Annahmen oder denselben Entstehungsweg wie das zu prüfende Ergebnis wiederholt. |
| Inference | — | Nutzung eines bereits trainierten Modells, um aus einem Input einen Output zu berechnen. |
| Inference-Time Compute | — | Rechenaufwand, der während der Nutzung eines Modells für eine konkrete Aufgabe eingesetzt wird, etwa für zusätzliches Reasoning. |
| Information Boundary | — | Grenze dafür, welche Informationen einen Bereich, Prozess, Agenten oder Trust-Bereich verlassen dürfen. |
| Information Flow | — | Weg, den Informationen durch Quellen, Systeme, Agents, Tools, Speicher und Outputs nehmen. |
| Information Hiding | — | Architekturprinzip, bei dem interne Entscheidungen und Details hinter stabilen Schnittstellen verborgen werden. |
| Input Tokens | — | Tokens, die als Eingabe in eine Modellanfrage eingehen, einschließlich sichtbarer und systemseitig ergänzter Informationen. |
| Invariant | — | Regel oder Eigenschaft, die in einem System unabhängig von einer konkreten Änderung immer gelten soll. |
| Jailbreak | — | Versuch, Sicherheits- oder Verhaltensgrenzen eines AI-Systems durch speziell gestaltete Eingaben zu umgehen. |
| KI | Künstliche Intelligenz | Deutsche Bezeichnung für AI; in der Serie wird überwiegend die international gebräuchliche Abkürzung AI verwendet. |
| KV Cache | Key-Value Cache | Zwischenspeicher von Attention-Zuständen, der wiederholte Berechnungen bei der Token-Generierung vermeiden kann. |
| Layer | — | Architekturschicht mit einer bestimmten Verantwortung und definierten Abhängigkeitsregeln. |
| Least Privilege | — | Sicherheitsprinzip, nach dem ein Benutzer, Agent oder Prozess nur die minimal notwendigen Berechtigungen erhält. |
| Legacy System | — | Bestehendes, häufig über längere Zeit gewachsenes System, dessen Strukturen und Abhängigkeiten Änderungen erschweren können. |
| Lint / Linter | — | Statische Prüfung von Quellcode auf definierte Qualitäts-, Stil- oder Fehlerregeln. |
| LLM | Large Language Model | Großes Sprachmodell, das Token-Sequenzen verarbeitet und typischerweise schrittweise neue Tokens erzeugt. |
| LLM-as-a-Judge | — | Verfahren, bei dem ein Sprachmodell die Qualität oder Korrektheit von Antworten anderer Modelle bewertet. |
| Local Evidence | — | Im vorhandenen Repository oder System gefundene Beispiele, Strukturen und Regeln, die einem Agenten als Hinweis auf gewünschte Lösungen dienen. |
| Local Inference | — | Ausführung eines AI-Modells auf eigener oder selbst kontrollierter Infrastruktur. |
| Local Model | — | Modell, das lokal beziehungsweise auf selbst kontrollierter Infrastruktur betrieben werden kann. |
| Long-Horizon Agent | — | Agent, der über längere Zeiträume und viele Schritte hinweg an komplexen Aufgaben arbeitet. |
| Machine Learning | — | Teilgebiet der AI, bei dem Modelle Verhaltensmuster aus Daten lernen, statt dass alle Regeln vollständig von Menschen programmiert werden. |
| Marginal Cost | — | Zusätzliche Kosten, die durch eine weitere Einheit entstehen, etwa einen zusätzlichen Agent-Run oder eine weitere Änderung. |
| MCP | Model Context Protocol | Offenes Protokoll, über das AI-Anwendungen standardisiert Tools und externe Datenquellen anbinden können. |
| Memory | — | Persistenter Speicher außerhalb der Modellgewichte, aus dem Informationen später wieder in den aktuellen Context eingebracht werden können. |
| Model | — | Trainiertes mathematisches System, das Inputs verarbeitet und daraus Outputs berechnet. |
| Model Card | — | Dokumentation eines Modells mit Angaben zu Fähigkeiten, Evaluationen, Grenzen, Risiken und vorgesehenem Einsatz. |
| Model Review | — | Prüfung eines Ergebnisses durch ein weiteres Modell; nützlich, aber nicht automatisch unabhängig von den Annahmen des erzeugenden Modells. |
| Model Routing | — | Auswahl unterschiedlicher Modelle oder Konfigurationen abhängig von Aufgabe, Risiko, Kosten oder gewünschter Leistungsfähigkeit. |
| Model Score | — | Messwert eines Modells auf einem Benchmark; bei Agenten kann er stark durch Harness, Tools, Context und Compute beeinflusst werden. |
| Module Boundary | — | Definierte Grenze eines Moduls, die festlegt, welche Interna verborgen bleiben und über welche Schnittstellen andere Teile zugreifen dürfen. |
| MoE | Mixture of Experts | Modellarchitektur mit mehreren Teilnetzen, von denen pro Verarbeitungsschritt nur ein Teil aktiviert wird. |
| Monorepo | — | Repository, in dem mehrere Anwendungen, Libraries oder Services gemeinsam versioniert und verwaltet werden. |
| Multi-Agent System | — | System, in dem mehrere Agents koordiniert an Teilaufgaben oder demselben Ziel arbeiten. |
| Multimodal | — | Fähigkeit eines Modells oder Systems, mehrere Modalitäten wie Text, Bild, Audio oder Video zu verarbeiten oder zu erzeugen. |
| Noise | — | Unnötiger, irrelevanter oder qualitativ schwacher Output, der die eigentlich brauchbare Information überlagert. |
| Non-Determinism | — | Eigenschaft, dass gleiche oder sehr ähnliche Eingaben nicht zwingend zu exakt demselben Lösungsweg oder Output führen. |
| Open Source | — | Software, deren Quellcode unter einer entsprechenden Lizenz zugänglich, nutzbar und veränderbar ist; bei AI nicht automatisch gleichbedeutend mit Open Weights. |
| Open Weights | — | Modelle, deren gelernte Gewichte verfügbar sind; Trainingsdaten, Trainingscode oder vollständige Pipeline müssen deshalb nicht offen sein. |
| OpEx | Operating Expenditure | Laufende Betriebsausgaben, etwa API-Nutzung, Strom, Hosting oder Administration. |
| Output Tokens | — | Tokens, die ein Modell während einer Anfrage erzeugt. |
| Paradigm Drift | — | Schleichende Abweichung von einem ursprünglich gewählten Architektur- oder Entwicklungsparadigma hin zu konkurrierenden Mustern. |
| Parameters | — | Gelernte Zahlenwerte eines Modells, die sein Verhalten mitbestimmen. |
| Pass@1 | — | Benchmark-Metrik dafür, ob bereits der erste erzeugte Lösungsversuch erfolgreich ist. |
| Pass@k | — | Benchmark-Metrik für die Wahrscheinlichkeit, dass unter k erzeugten Versuchen mindestens eine erfolgreiche Lösung liegt. |
| Path Dependency | — | Eigenschaft, dass frühe Entscheidungen den später verfügbaren Lösungsweg und Context beeinflussen. |
| Personal Data | — | Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. |
| Post-Training | — | Trainings- und Anpassungsphasen nach dem grundlegenden Pre-Training, etwa für Verhalten, Reasoning, Sicherheit oder Aufgabenspezialisierung. |
| Pre-Training | — | Grundlegende Trainingsphase, in der ein Modell aus großen Datenmengen allgemeine Muster und Fähigkeiten erlernt. |
| Privacy by Design | — | Prinzip, Datenschutz bereits bei Architektur und Gestaltung eines Systems einzuplanen statt erst nachträglich hinzuzufügen. |
| Probabilistic | — | Bezeichnet Systeme, deren Ausgabe auf Wahrscheinlichkeitsverteilungen beruht; gleiche Eingaben müssen deshalb nicht zwingend exakt denselben Output erzeugen. |
| Progressive Disclosure | — | Prinzip, Informationen oder Skills erst dann in den Context zu laden, wenn sie für die aktuelle Aufgabe relevant werden. |
| Prompt | — | Eingabe beziehungsweise Anweisung, die einem Modell für eine konkrete Verarbeitung gegeben wird. |
| Prompt Caching | — | Wiederverwendung bereits berechneter Zustände für wiederkehrende Teile eines Prompts oder Contexts, um Kosten oder Latenz zu reduzieren. |
| Prompt Engineering | — | Gestaltung von Anweisungen und Eingaben für Modelle; bei agentischen Systemen zunehmend eng mit Requirements- und Context-Engineering verbunden. |
| Prompt Injection | — | Angriff oder unerwünschte Instruktion, bei der Inhalte im Context versuchen, ein Modell zu Aktionen entgegen der eigentlichen Nutzer- oder Systemabsicht zu bewegen. |
| Pseudonymization | — | Verarbeitung, bei der direkte Identifikatoren ersetzt oder getrennt werden; bei möglicher Re-Identifikation bleiben die Daten personenbezogen. |
| Quantization | — | Reduktion der numerischen Präzision von Modellwerten, um Speicherbedarf und Rechenaufwand zu senken. |
| RAG | Retrieval-Augmented Generation | Verfahren, bei dem vor oder während der Generierung externe Informationen gesucht und als zusätzlicher Context bereitgestellt werden. |
| Reasoning | — | Zusätzliche modellinterne oder explizite Verarbeitungsschritte, mit denen komplexere Aufgaben systematischer gelöst werden sollen. |
| Reasoning Effort | — | Konfiguration dafür, wie viel Rechen- beziehungsweise Reasoning-Aufwand ein Modell für eine Aufgabe verwenden soll. |
| Reasoning Model | — | Bezeichnung für Modelle, die für mehrstufige Problemlösung und zusätzlichen Inference-Aufwand optimiert sind. |
| Reasoning Tokens | — | Bei manchen APIs separat erfasste Tokens oder Rechenschritte, die für internes Reasoning verwendet werden und nicht vollständig als sichtbarer Text erscheinen müssen. |
| Red Teaming | — | Gezielte Suche nach Schwachstellen, Fehlverhalten oder unerwünschten Grenzfällen durch bewusst adversariale Tests. |
| Reinforcement Learning (RL) | Reinforcement Learning | Trainingsverfahren, bei dem Verhalten anhand von Rückmeldungs- oder Belohnungssignalen optimiert wird. |
| Repository | — | Versionsverwaltete Sammlung von Quellcode, Konfiguration, Tests und weiteren Projektartefakten. |
| Requirements | — | Fachliche und technische Anforderungen, die festlegen, was ein System oder eine Änderung leisten und welche Bedingungen sie erfüllen soll. |
| Requirements Engineering | — | Systematisches Ermitteln, Klären, Dokumentieren und Prüfen von Anforderungen an ein System oder eine Änderung. |
| Responsibility Drift | — | Schleichende Verschiebung von Zuständigkeiten, sodass Code oder Komponenten Aufgaben übernehmen, die ursprünglich anders verortet waren. |
| Responsibility Verification | — | Prüfung, ob eine Änderung nicht nur funktioniert, sondern auch in der richtigen fachlichen oder technischen Verantwortung liegt. |
| Retrieval | — | Gezieltes Auffinden und Bereitstellen externer oder gespeicherter Informationen für eine aktuelle Aufgabe. |
| Review | — | Bewertung einer Änderung durch Menschen oder andere Systeme hinsichtlich Korrektheit, Qualität, Risiken und Systemverträglichkeit. |
| Review Bottleneck | — | Engpass, der entsteht, wenn erzeugte Änderungen schneller produziert werden, als sie sinnvoll geprüft und akzeptiert werden können. |
| RLHF | Reinforcement Learning from Human Feedback | Reinforcement-Learning-Verfahren, bei dem menschliche Präferenzen oder Bewertungen als Signal zur Verhaltensanpassung eines Modells dienen. |
| ROI | Return on Investment | Verhältnis zwischen wirtschaftlichem Nutzen einer Investition und den dafür eingesetzten Kosten. |
| Sampling | — | Verfahren, mit dem aus den vom Modell bewerteten möglichen nächsten Tokens ein konkretes Token ausgewählt wird. |
| Scaffold | — | Alternative Bezeichnung für die um ein Modell gebaute Agent- oder Evaluationsstruktur; häufig ähnlich wie Harness verwendet. |
| Scope | — | Festgelegter Umfang einer Aufgabe oder Änderung, einschließlich dessen, was ausdrücklich nicht dazugehört. |
| SCS | Self-contained System | Architekturansatz, bei dem fachlich geschnittene Systeme möglichst eigenständig arbeiten und nur klar definierte Integrationspunkte besitzen. |
| Semantic Search | — | Suche nach inhaltlicher Ähnlichkeit statt nur nach identischen Wörtern, häufig auf Basis von Embeddings. |
| Separation of Concerns | — | Prinzip, unterschiedliche Verantwortlichkeiten und Problemarten bewusst voneinander zu trennen. |
| SLM | Small Language Model | Unscharfer Sammelbegriff für relativ kleine Sprachmodelle, die häufig auf geringere Kosten, lokale Ausführung oder spezialisierte Aufgaben optimiert sind. |
| Solution Space | — | Menge der grundsätzlich möglichen Lösungswege für ein Problem; Requirements und Constraints können diesen Raum verkleinern. |
| Specification | — | Möglichst konkrete Beschreibung eines gewünschten Verhaltens, einer Änderung oder eines Systems. |
| Static Analysis | — | Analyse von Code ohne dessen Ausführung, etwa für Typfehler, Lint-Regeln oder Architekturverletzungen. |
| Stop Condition | — | Vorab definierte Bedingung, bei der ein Agent seine autonome Arbeit beendet und Rückfrage oder menschliche Entscheidung benötigt. |
| SWE | Software Engineering | Disziplin des systematischen Entwerfens, Entwickelns, Prüfens, Betreibens und Weiterentwickelns von Software. |
| SWE-bench | Software Engineering Benchmark | Benchmark-Familie, die reale GitHub-Issues und Repository-Änderungen zur Bewertung von Coding-Modellen und Agents verwendet. |
| SWE-bench Pro | — | Schwierigere SWE-bench-Variante mit breiterem Repository- und Aufgabenmix und stärkerem Fokus auf realistische agentische Softwarearbeit. |
| SWE-bench Verified | — | Von Menschen geprüfte Teilmenge von SWE-bench, die problematische oder uneindeutige Aufgaben reduzieren sollte. |
| Synthetic Data | — | Künstlich erzeugte Daten, die reale Daten nachbilden oder ergänzen und etwa für Training, Tests oder Datenschutz eingesetzt werden können. |
| System Prompt | — | Übergeordnete Instruktionen, die Verhalten, Rolle oder Grenzen eines Modells für eine Sitzung oder Anwendung festlegen. |
| System Score | — | Messwert des gesamten evaluierten Systems aus Modell, Harness, Tools, Context und weiteren Laufzeitbedingungen. |
| TDD | Test-Driven Development | Entwicklungsansatz, bei dem Tests bewusst vor oder eng vor der Implementierung entwickelt werden und das Design mitsteuern. |
| Technical Debt | — | Künftiger Mehraufwand, der durch kurzfristige technische Entscheidungen, fehlende Pflege oder bewusst aufgeschobene Qualität entsteht. |
| Temperature | — | Sampling-Parameter, der beeinflusst, wie stark wahrscheinlichere gegenüber weniger wahrscheinlichen Token-Optionen bevorzugt werden. |
| Test-Time Compute | — | Alternative Bezeichnung für zusätzlichen Rechenaufwand während der Nutzung eines Modells; weitgehend verwandt mit Inference-Time Compute. |
| Token | — | Verarbeitungseinheit eines Sprachmodells; ein Token kann ein Wort, Wortteil, Zeichen oder andere Textsequenz repräsentieren. |
| Token Budget | — | Maximale oder geplante Tokenmenge für Context, Generierung oder einen Agent-Run. |
| Tokenizer | — | Komponente, die Text in die Token-IDs übersetzt, die ein Sprachmodell verarbeitet. |
| Tool | — | Externe Fähigkeit, die ein Modell oder Agent nutzen kann, etwa Dateizugriff, Suche, Shell, Browser oder API. |
| Tool Calling | — | Mechanismus, mit dem ein Modell strukturierte Aktionen über externe Tools auslösen kann. |
| Top-K | — | Sampling-Verfahren, bei dem nur die k wahrscheinlichsten nächsten Token-Kandidaten für die Auswahl berücksichtigt werden. |
| Top-P | Nucleus Sampling | Sampling-Verfahren, bei dem die kleinste Menge wahrscheinlicher Token-Kandidaten berücksichtigt wird, deren Gesamtwahrscheinlichkeit mindestens p erreicht. |
| Total Parameters | — | Gesamtzahl der Parameter eines Modells, unabhängig davon, ob bei jedem Rechenschritt alle davon aktiv sind. |
| Training | — | Prozess, bei dem Modellparameter anhand von Daten und Optimierungszielen angepasst werden. |
| Trajectory | — | Aufgezeichneter Ablauf eines Agenten aus Beobachtungen, Modellschritten, Tool-Aufrufen, Aktionen und Zwischenzuständen. |
| Transformer | — | Neuronale Netzwerkarchitektur auf Basis von Attention, die die Entwicklung moderner LLMs wesentlich geprägt hat. |
| Trust Boundary | — | Grenze zwischen Bereichen mit unterschiedlichem Vertrauens- oder Schutzstatus, deren Überschreitung bewusst kontrolliert werden sollte. Vertieft in Artikel 09. |
| Unit Test | — | Test einer kleinen, möglichst isolierten Einheit von Software. |
| Validation | — | Prüfung, ob das richtige Problem gelöst beziehungsweise die fachliche Absicht erfüllt wird; in der Praxis oft nicht scharf von Verification getrennt. |
| Variable Cost | — | Kosten, die mit Nutzung oder Produktionsmenge steigen, etwa API- und Tokenkosten. |
| Vector Database | — | Datenbank, die Vektorrepräsentationen wie Embeddings speichert und Ähnlichkeitssuchen unterstützt. |
| Verification | — | Prüfung, welche belastbare Evidenz dafür vorliegt, dass eine Änderung oder Behauptung korrekt und akzeptabel ist. |
| Verification Debt | — | Aufgeschobener oder fehlender Verifikationsaufwand, der später Unsicherheit und zusätzliche Prüfkosten erzeugt. Vertieft in Artikel 12. |
| Verification Diversity | — | Kombination unterschiedlicher Prüfmethoden, damit nicht alle Checks dieselben Annahmen und Fehlerklassen teilen. Vertieft in Artikel 12. |
| Verification Surface | — | Gesamtheit der Aspekte einer Änderung, die geprüft werden müssen, um sie verantwortbar akzeptieren zu können. Vertieft in Artikel 12. |
| Vibe Coding | — | Informeller Entwicklungsstil, bei dem Software primär über natürliche Sprache und AI-generierten Code entsteht; im engeren Sinn mit wenig direkter Codeprüfung. |
| VLM | Vision-Language Model | Modell, das visuelle Informationen und Sprache gemeinsam verarbeitet; der Begriff wird zunehmend bei multimodalen Systemen verwendet. |
| VRAM | Video Random Access Memory | Speicher einer GPU; bei lokaler Inference oft ein wesentlicher Grenzfaktor für Modellgröße und Context. |
| Wall Clock | — | Reale verstrichene Zeit vom Start bis zum Ende eines Vorgangs, unabhängig davon, wie viel davon menschliche aktive Arbeitszeit ist. |
| Weights | — | Gelernte Zahlenwerte eines neuronalen Netzes; im LLM-Alltag oft nahezu synonym zu Modellparametern verwendet. |
| Workflow Lock-in | — | Steigende Wechselkosten, wenn Prozesse, Tools, Daten und Agent Infrastructure stark an einen bestimmten Anbieter oder Workflow gekoppelt sind. |
| World Model | — | Interne oder explizite Repräsentation davon, wie eine Umgebung funktioniert und wie Aktionen ihren Zustand verändern können. |
Stand: September 2026. Das Glossar beschreibt die Begriffe so, wie sie in dieser Serie und im aktuellen technischen Diskurs verwendet werden. Bei nicht standardisierten Begriffen ist die kurze Erklärung bewusst als praktische Einordnung und nicht als normative Definition zu verstehen.