Cohere

1. Cohere ist Modellanbieter, Retrieval-Spezialist und Enterprise-AI-Plattform

Cohere lässt sich 2026 nicht sinnvoll auf ein einzelnes Sprachmodell reduzieren. Das Unternehmen entwickelt generative Command-Modelle, Retrievalmodelle, Dokument- und Audiomodelle sowie komplette Arbeits- und Suchplattformen.

Für eine technische Chronik müssen Foundation-Modell, API, Retrievalpipeline, North, Compass, Model Vault und private Bereitstellung getrennt bezeichnet werden.

2. 2019: Gründung in Toronto

Cohere wurde 2019 in Toronto gegründet. Die Unternehmensgeschichte beginnt damit vor dem öffentlichen Chatbot-Boom und war von Anfang an auf große Sprachmodelle und produktive NLP-Infrastruktur ausgerichtet.

Der frühe Fokus auf APIs und Unternehmensintegration erklärt, warum Retrieval, Reranking und private Bereitstellung später eine ebenso große Rolle spielen wie reine Chatfähigkeiten.

3. Aidan Gomez, Nick Frosst und Ivan Zhang

Die drei Mitgründer sind Aidan Gomez, Nick Frosst und Ivan Zhang. Gomez war zuvor an der Transformer-Forschung beteiligt; die Cohere-Geschichte ist damit eng mit der Entwicklung moderner Transformer-Modelle verbunden.

Biografische Nähe zur Transformer-Forschung ersetzt keine Produktanalyse, hilft aber die technische Herkunft des Unternehmens einzuordnen.

4. Cohere Labs als Forschungsschicht

Cohere Labs ist die Open-Science- und Forschungsschicht des Unternehmens. Dort entstehen unter anderem Aya-Projekte, offene Datensätze und multilingual ausgerichtete Forschungsmodelle.

Cohere Labs ist nicht dasselbe wie die kommerzielle Cohere-Plattform. Forschungsmodell, kommerzielles Modell und Enterprise-Produkt besitzen unterschiedliche Ziele, Lizenzen und Supportpfade.

5. Enterprise AI statt Consumer-Chat als Grundposition

Cohere positioniert sich primär für Unternehmen, regulierte Branchen und kontrollierbare Deployments. Das unterscheidet die Produktlogik von Consumer-Assistenten, bei denen eine öffentliche Chatoberfläche im Mittelpunkt steht.

Die technische Konsequenz ist eine starke Betonung von Retrieval, Zugriffskontrolle, Datenresidenz, VPC, On-Premises, Model Vault und reproduzierbarer Inferenz.

6. 15. November 2021: Cohere Platform wird allgemein verfügbar

Die Cohere Platform wurde im November 2021 öffentlich verfügbar. Sie bot APIs für Textgenerierung und Repräsentationsmodelle und sollte NLP-Funktionen mit wenigen Integrationsschritten in Anwendungen bringen.

Schon dieser frühe Aufbau trennt Generierung von Repräsentation. Diese Trennung entwickelt sich später zu Command auf der einen und Embed/Rerank auf der anderen Seite.

7. Frühe Generation-Modelle

Die ersten öffentlichen Cohere-Angebote umfassten generative Modelle für Zusammenfassungen, Beschreibungen, Metadaten und andere Sprachaufgaben.

Historische Modellnamen und damalige Fine-Tuning-Funktionen dürfen nicht mit dem heutigen Command-A+-Stack gleichgesetzt werden.

8. Frühe Representation-Modelle

Neben Generation bot Cohere früh Repräsentationsmodelle für semantische Ähnlichkeit, Klassifikation und Suche.

Diese zweite Linie ist historisch wichtig, weil Cohere Retrieval nicht erst mit RAG entdeckte, sondern semantische Suche früh als eigenständigen Produktbereich aufbaute.

9. 2022: Cohere Labs entsteht

2022 wurde Cohere Labs als Forschungsinitiative aufgebaut. Die Forschungsschicht entwickelte sich später zu einer großen offenen Community mit starkem Fokus auf Mehrsprachigkeit und Zugänglichkeit.

Die Aya-Linie ist das sichtbarste Beispiel dafür, dass die Forschungsstrategie nicht nur ein Nebenprodukt der kommerziellen Command-Familie ist.

10. 1. Mai 2023: Rerank wird eigener Endpunkt

Mit Rerank stellte Cohere 2023 einen eigenen zweiten Retrievalschritt bereit: Kandidaten werden zunächst durch Suchsystem oder Embeddings gefunden und danach nach semantischer Relevanz neu sortiert.

Rerank ersetzt damit nicht automatisch die erste Suchstufe. Es ist besonders nützlich, wenn bestehende Keyword- oder Vektorsuche beibehalten und ihre Ergebnisreihenfolge verbessert werden soll.

11. 5. Juni 2023: Aya-Initiative startet

Aya begann als offene Forschungsinitiative für multilingualere und kulturell breiter abgedeckte KI.

Der spätere Aya-Modellstamm muss deshalb als eigene Forschungsfamilie gelesen werden und nicht als bloße kleinere Command-Variante.

12. 25. Juli 2023: Coral

Coral wurde als Enterprise Knowledge Assistant vorgestellt. Es verband Cohere-Modelle mit Unternehmenswissen und Retrieval und war ein wichtiger Vorläufer der späteren North-Produktlinie.

Coral ist heute vor allem historisch relevant; für aktuelle Integrationen darf ein älterer Coral-Screenshot nicht mit North oder Compass gleichgesetzt werden.

13. 28. September 2023: Chat mit RAG

Cohere integrierte Retrieval-Augmented Generation stärker in den Chatpfad. Das Modell konnte externe Dokumente als Grounding erhalten und Antworten mit Quellenbezug erzeugen.

RAG reduziert die Abhängigkeit von reinem Modellwissen, ersetzt aber weder Retrievalqualität noch Quellenprüfung.

14. 30. November 2023: Cohere auf Amazon Bedrock

Embed und Command Light wurden über Amazon Bedrock verfügbar. Die Distribution über Hyperscaler wurde damit ein fester Teil der Enterprise-Strategie.

Bei Cloudplattformen sind Modellversion, Plattform-ID, Datenpfad und Vertragsbeziehung getrennt zu prüfen; ein Cohere-Modell auf AWS ist nicht derselbe Betriebsweg wie die Cohere-SaaS-API.

15. Command als Instruktionsfamilie

Command als Instruktionsfamilie steht für Instruktionsbefolgung und generative Textaufgaben. Die Cohere-Architektur zeigt früh, dass ein produktives KI-System aus mehreren spezialisierten Schichten bestehen kann.

Für reproduzierbare Tests müssen Eingabedaten, Modellversion, Retrievalkonfiguration und Ausgaberegeln dokumentiert werden; sonst wird eine Änderung in einer Schicht fälschlich dem Basismodell zugeschrieben.

16. Command Light

Command Light steht für geringere Latenz und kleinere Serving-Klasse. Die Cohere-Architektur zeigt früh, dass ein produktives KI-System aus mehreren spezialisierten Schichten bestehen kann.

Für reproduzierbare Tests müssen Eingabedaten, Modellversion, Retrievalkonfiguration und Ausgaberegeln dokumentiert werden; sonst wird eine Änderung in einer Schicht fälschlich dem Basismodell zugeschrieben.

17. Fine-Tuning in der frühen Plattform

Fine-Tuning in der frühen Plattform steht für domänenspezifische Anpassung über damalige Plattformfunktionen. Die Cohere-Architektur zeigt früh, dass ein produktives KI-System aus mehreren spezialisierten Schichten bestehen kann.

Für reproduzierbare Tests müssen Eingabedaten, Modellversion, Retrievalkonfiguration und Ausgaberegeln dokumentiert werden; sonst wird eine Änderung in einer Schicht fälschlich dem Basismodell zugeschrieben.

18. Embed als Vektorraummodell

Embed als Vektorraummodell steht für semantische Repräsentation für Suche und Klassifikation. Die Cohere-Architektur zeigt früh, dass ein produktives KI-System aus mehreren spezialisierten Schichten bestehen kann.

Für reproduzierbare Tests müssen Eingabedaten, Modellversion, Retrievalkonfiguration und Ausgaberegeln dokumentiert werden; sonst wird eine Änderung in einer Schicht fälschlich dem Basismodell zugeschrieben.

19. Multilingual Embed

Multilingual Embed steht für sprachübergreifende semantische Repräsentationen. Die Cohere-Architektur zeigt früh, dass ein produktives KI-System aus mehreren spezialisierten Schichten bestehen kann.

Für reproduzierbare Tests müssen Eingabedaten, Modellversion, Retrievalkonfiguration und Ausgaberegeln dokumentiert werden; sonst wird eine Änderung in einer Schicht fälschlich dem Basismodell zugeschrieben.

20. Rerank als Cross-Encoder-Schicht

Rerank als Cross-Encoder-Schicht steht für queryabhängige Neubewertung bereits gefundener Dokumente. Die Cohere-Architektur zeigt früh, dass ein produktives KI-System aus mehreren spezialisierten Schichten bestehen kann.

Für reproduzierbare Tests müssen Eingabedaten, Modellversion, Retrievalkonfiguration und Ausgaberegeln dokumentiert werden; sonst wird eine Änderung in einer Schicht fälschlich dem Basismodell zugeschrieben.

21. Lexikalische Suche plus Rerank

Lexikalische Suche plus Rerank steht für Erhalt bestehender Suchindizes mit semantischer Zweitstufe. Die Cohere-Architektur zeigt früh, dass ein produktives KI-System aus mehreren spezialisierten Schichten bestehen kann.

Für reproduzierbare Tests müssen Eingabedaten, Modellversion, Retrievalkonfiguration und Ausgaberegeln dokumentiert werden; sonst wird eine Änderung in einer Schicht fälschlich dem Basismodell zugeschrieben.

22. Vektorsuche plus Rerank

Vektorsuche plus Rerank steht für breiter Recall in Stufe eins und präzisere Sortierung in Stufe zwei. Die Cohere-Architektur zeigt früh, dass ein produktives KI-System aus mehreren spezialisierten Schichten bestehen kann.

Für reproduzierbare Tests müssen Eingabedaten, Modellversion, Retrievalkonfiguration und Ausgaberegeln dokumentiert werden; sonst wird eine Änderung in einer Schicht fälschlich dem Basismodell zugeschrieben.

23. RAG als Pipeline

RAG als Pipeline steht für Retrieval, Ranking, Kontextbau und Generierung als getrennte Schritte. Die Cohere-Architektur zeigt früh, dass ein produktives KI-System aus mehreren spezialisierten Schichten bestehen kann.

Für reproduzierbare Tests müssen Eingabedaten, Modellversion, Retrievalkonfiguration und Ausgaberegeln dokumentiert werden; sonst wird eine Änderung in einer Schicht fälschlich dem Basismodell zugeschrieben.

24. Grounding und Zitationen

Grounding und Zitationen steht für nachvollziehbare Bezugnahme auf bereitgestellte Dokumente. Die Cohere-Architektur zeigt früh, dass ein produktives KI-System aus mehreren spezialisierten Schichten bestehen kann.

Für reproduzierbare Tests müssen Eingabedaten, Modellversion, Retrievalkonfiguration und Ausgaberegeln dokumentiert werden; sonst wird eine Änderung in einer Schicht fälschlich dem Basismodell zugeschrieben.

25. Tool Use als nächste Ebene

Tool Use als nächste Ebene steht für externe Funktionen statt ausschließlich textlicher Antwort. Die Cohere-Architektur zeigt früh, dass ein produktives KI-System aus mehreren spezialisierten Schichten bestehen kann.

Für reproduzierbare Tests müssen Eingabedaten, Modellversion, Retrievalkonfiguration und Ausgaberegeln dokumentiert werden; sonst wird eine Änderung in einer Schicht fälschlich dem Basismodell zugeschrieben.

26. 13. Februar 2024: Aya Model

Aya wurde als offenes, instruction-getuntes multilingual ausgerichtetes Forschungsmodell für mehr als 100 Sprachen veröffentlicht.

Die hohe Sprachzahl beschreibt Abdeckung und Forschungsziel; sie bedeutet nicht identische Qualität in jeder Sprache oder Domäne.

27. 11. März 2024: Command R

Command R wurde für produktives RAG, Tool Use und lange Unternehmenskontexte veröffentlicht und brachte ein Kontextfenster von 128K in die R-Familie.

Die R-Bezeichnung steht historisch eng für Retrieval-orientierte Generierung. Spätere Command-A-Modelle übernehmen viele dieser Fähigkeiten ohne das R im Namen.

28. 14. März 2024: Tool Use mit Command R

Cohere machte Tool Use zu einer expliziten Funktion des Command-R-Stacks. Modelle können strukturierte Funktionsaufrufe erzeugen, während die eigentliche Ausführung außerhalb des Modells erfolgt.

Tool Use erweitert Wirkung und Risiko. Schema, Argumente, Berechtigungen und Rückgaben müssen separat validiert werden.

29. 4. April 2024: Command R+

Command R+ erweiterte die RAG- und Multi-Step-Tool-Use-Linie als stärkeres Modell mit 128K Kontext.

R+ war für komplexere Enterprise-RAG-Workloads gedacht, wurde später aber von der Command-A-Linie als Hauptpfad abgelöst.

30. 11. April 2024: Rerank 3

Rerank 3 modernisierte die semantische Ranking-Linie für Enterprise Search und Retrieval.

Ein Reranker bewertet Relevanz und erzeugt keine verlässliche Antwort auf die Nutzerfrage; Generation bleibt eine getrennte Schicht.

31. 23. Mai 2024: Aya 23

Aya 23 erschien mit offenen Gewichten in 8B- und 35B-Klassen und konzentrierte sich auf 23 Sprachen.

Weniger Zielsprachen als Aya-101 bedeuten hier eine andere Optimierungsstrategie: mehr Kapazität pro ausgewählter Sprache statt möglichst großer Sprachabdeckung.

32. August 2024: aktualisierte Command-R-Snapshots

Command R und Command R+ erhielten im August 2024 aktualisierte Modellversionen. Diese datierten IDs blieben länger live als die ursprünglichen 03/04-2024-Versionen.

Produktionssysteme sollten feste Modell-IDs protokollieren. Ein Alias kann sonst zu einem anderen Snapshot zeigen als beim ursprünglichen Test.

33. 24. Oktober 2024: Aya Expanse

Aya Expanse setzte die Forschungsfamilie als 8B- und 32B-Linie fort und fokussierte 23 Sprachen.

Aya Expanse ist ein multilingualer Forschungs- und Open-Weight-Pfad; Lizenz und kommerzielle Nutzungsrechte müssen separat vom Begriff Open Weight geprüft werden.

34. 2. Dezember 2024: Rerank 3.5

Rerank 3.5 verbesserte die Rankingqualität für Enterprise Search und semistrukturierte Daten.

Später ergänzt Rerank 4 die Linie um Pro- und Fast-Varianten; die Versionsnummer beschreibt daher eine eigenständige Retrievalfamilie, nicht die Command-Generation.

35. 13. Dezember 2024: Command R7B

Command R7B brachte RAG, Tool Use und agentische Fähigkeiten in eine kleinere, schnellere Modellklasse mit 128K Kontext.

Kleine Modelle sind besonders interessant, wenn Latenz, Kosten oder Private Deployment wichtiger sind als maximale Modellkapazität.

36. 9. Januar 2025: North Early Access

North wurde als sicherer AI Workspace vorgestellt, der LLMs, Enterprise Search und Automatisierung zusammenführt.

North ist ein Produkt und Orchestrationssystem. Es darf nicht mit dem darunter verwendeten Command-Modell gleichgesetzt werden.

37. 31. Januar 2025: North als Produktivitätsplattform

Cohere konkretisierte North als Enterprise Workspace für produktive Wissensarbeit.

Der Schwerpunkt verschiebt sich damit von einzelnen API-Endpunkten zu einem Arbeitsprodukt mit Suche, Dokumenten, Agenten und Unternehmensdaten.

38. 27. Februar 2025: Command R7B Arabic

Eine auf Arabisch optimierte R7B-Variante zeigt Coheres Strategie, Sprach- und Regionenanforderungen auch über spezialisierte Modellpfade abzudecken.

Eine sprachspezialisierte Variante ist nicht automatisch für alle Aufgaben besser; Domäne, Dialekt, Tool Use und Retrieval bleiben gesondert zu testen.

39. 4. März 2025: Aya Vision

Aya Vision erweitert die Aya-Forschung um Bild- und Texteingaben.

Multimodalität bedeutet hier Verstehen von Bildern im Kontext mehrsprachiger Aufgaben, nicht Bildgenerierung.

40. 13. März 2025: Command A

Command A markiert den Übergang von der R-Familie zu einer neuen generativen Hauptlinie. Es besitzt 256K Kontext und wurde für Agents, RAG, Tool Use und Mehrsprachigkeit optimiert.

Command A ist ein dichtes 111B-Modell und wurde auf einen vergleichsweise kleinen Serving-Footprint für private Enterprise-Deployments ausgelegt.

41. 15. April 2025: Embed 4

Embed 4 erweitert die Retrievalrepräsentation auf Text, Bilder und gemischte Dokumentinhalte bei bis zu 128K Kontext.

Damit kann die erste Retrievalstufe multimodale Unternehmensdaten semantisch erschließen; Rerank bleibt die getrennte Qualitätsstufe danach.

42. 31. Juli 2025: Command A Vision

Command A Vision ist Coheres erste Command-Variante mit Bildverständnis und 128K Kontext. Sie adressiert Diagramme, Tabellen, OCR und Dokument-Q&A.

Die Vision-Variante akzeptiert Bilder, erzeugt aber keine Bilder. Tool Use wurde für diese Variante nicht als allgemeiner Funktionspfad unterstützt.

43. 6. August 2025: North General Availability

North wurde als Plattform für Agenten und Automatisierungen in Unternehmensinfrastruktur allgemein positioniert.

Der Produktstatus ist wichtig, weil frühe North-EAP-Beschreibungen nicht automatisch den späteren GA-Funktionsumfang dokumentieren.

44. 21. August 2025: Command A Reasoning

Command A Reasoning ergänzt explizites Reasoning für komplexere Problem- und Agentenaufgaben. Es besitzt 256K Kontext und größere Ausgabelimits als die ursprüngliche Command-A-Variante.

Reasoning ist kein Wahrheitsbeweis. Längere interne oder sichtbare Denkpfade können Fehler strukturierter darstellen, aber nicht automatisch vermeiden.

45. 28. August 2025: Command A Translate

Command A Translate spezialisiert sich auf maschinelle Übersetzung in 23 Sprachen.

Übersetzungsqualität hängt von Sprachpaar, Fachdomäne, Terminologie und Kontext ab; ein allgemeiner Command-Chatprompt ist nicht dasselbe wie die spezialisierte Translate-Variante.

46. 15. September 2025: große Deprecation-Welle

Cohere kündigte die Ablösung älterer Command-Modelle, Legacy-Endpunkte und früher Fine-Tuning-Pfade an.

Diese Phase ist für Archivierung zentral: API-Versionen können verschwinden, obwohl historische Dokumentation und ältere Cloudplattform-IDs weiter existieren.

47. 11. Dezember 2025: Rerank 4

Rerank 4 führt eine Pro- und eine Fast-Klasse mit 32K Kontext ein.

Pro priorisiert maximale Rankingqualität, Fast niedrige Latenz und hohen Durchsatz. Beide bleiben Retrievalmodelle und keine Chatmodelle.

48. 28. Januar 2026: Model Vault

Model Vault startet als Cohere-verwaltete, isolierte Inferenzumgebung für dedizierte Modellbereitstellungen.

Es kombiniert API-Komfort mit Single-Tenant-Isolation. Es ist weder identisch mit SaaS-Multitenancy noch mit vollständig kundengemanagtem On-Premises.

49. 17. Februar 2026: Tiny Aya

Tiny Aya bringt die offene multilingual ausgerichtete Forschung in eine 3,35B-Klasse für 70+ Sprachen und lokale beziehungsweise Edge-nahe Nutzung.

Die regionale Aufteilung in Global, Earth, Fire und Water zeigt, dass Mehrsprachigkeit auch als gezielte Sprach- und Kulturabdeckung modelliert werden kann.

50. 16. März 2026: Ausbau der Sovereign-AI-Infrastruktur

Cohere vertiefte 2026 die Infrastruktur- und Hardwarestrategie für souveräne Deployments.

Souveränität ist kein einzelnes Produktfeature, sondern ergibt sich aus Modelllizenz, Hosting, Netzwerk, Datenresidenz, Zugriffskontrolle und Betriebsverantwortung.

51. 26. März 2026: Cohere Transcribe

Cohere Transcribe ist ein 2B-Automatic-Speech-Recognition-Modell mit Conformer-Encoder, Transformer-Decoder, 14 Sprachen und Apache-2.0-Lizenz.

Audio wird in Text transkribiert. Das Modell ist kein allgemeines Sprachmodell und keine Text-to-Speech-Engine.

52. 24. April 2026: Cohere und Aleph Alpha kündigen geplantes Zusammengehen an

Cohere und Aleph Alpha kündigten ein geplantes Zusammengehen für souveräne Enterprise AI an, verbunden mit einer transatlantischen Kanada-Deutschland-Strategie.

Für die Technikchronik ist das vor allem als Infrastruktur-, Souveränitäts- und Enterprise-Ereignis relevant; bestehende Modellfamilien bleiben technisch unterscheidbar, solange die angekündigte Transaktion und Integration nicht als technische Vereinheitlichung missverstanden werden.

53. 20. Mai 2026: Command A+

Command A+ wird als Apache-2.0-Modell mit 218B Gesamt- und 25B aktiven Parametern veröffentlicht. Es ist Coheres erstes Command-MoE und kombiniert Text, Bild, Reasoning, Tool Use und 48 Sprachen.

Mit 128K Eingabekontext und bis zu 64K Ausgabe konsolidiert A+ Fähigkeiten, die zuvor auf Command A, Reasoning, Vision und Translate verteilt waren.

54. 9. Juni 2026: North Mini Code

North Mini Code ist Coheres erstes speziell agentisches Codingmodell und der erste Vertreter einer neuen North-Modelllinie. Es besitzt 30B Gesamt- und 3B aktive Parameter und steht unter Apache 2.0.

Der geringe aktive Anteil reduziert Rechenaufwand, aber nicht automatisch den Speicherbedarf der vollständigen Gewichte. Für lokale Nutzung bleiben Quantisierung und Runtime entscheidend.

55. 7. Juli 2026: Cohere Transcribe Arabic

Cohere Transcribe Arabic ergänzt die Speech-Linie als auf arabische Audioeingaben optimierte Variante.

Sprachspezialisierung und allgemeine Mehrsprachigkeit sind zwei unterschiedliche Ziele; Produktionsauswahl sollte auf realen Audio- und Dialektdaten basieren.

56. 27. Juli 2026: North Automations

North Automations erweitert North um orchestrierte, mehrstufige Agentenworkflows mit Governance und menschlicher Kontrolle.

Ein Automation-Workflow ist keine einzelne Modellantwort. Trigger, Schritte, Agentenrechte, Freigaben, Fehlerpfade und Wiederholungslogik sind eigenständige Betriebsobjekte.

57. 27. August 2026: Parse v5

Parse wird als 2,3B-Dokument-Parsingmodell für PDFs, Präsentationen und Bilder vorgestellt. Es extrahiert strukturierte Inhalte einschließlich Text, Tabellen, Formulare, Bilder und räumliche Positionen.

Parse ist mehr als OCR, aber kein allgemeiner Chatassistent. Seine Ausgabe dient häufig als Ingestion-Schicht vor Embed, Rerank, RAG oder Agenten.

58. 1. September 2026: aktueller Cohere-Endstand

Am Stichtag bilden Command A+, North Mini Code, Embed 4, Rerank 4, Parse v5 und Cohere Transcribe die wichtigsten aktuellen Modellpfade; North, Compass und Model Vault sind darüberliegende Produktschichten.

Aya bleibt parallel als offene multilingual ausgerichtete Forschungsfamilie bestehen. Diese Ebenen werden auf dieser Seite nicht zu einer einzigen Produktmarke zusammengezogen.

59. Command R: Retrieval als Designziel

Command R wurde nicht nur als Chatmodell mit optionaler Suche positioniert, sondern für RAG-Workloads mit Grounding, langen Dokumenten und Tool Use entwickelt.

Die Qualität eines RAG-Systems hängt dennoch von Indexierung, Query-Rewrite, Retrieval, Reranking, Kontextpacking und Generierung gemeinsam ab.

60. 128K Kontext in der R-Familie

128K erlaubt große Dokumentmengen im Prompt, ist aber kein Ersatz für Retrieval.

Sehr lange Kontexte erhöhen Kosten und können relevante Stellen verwässern; selektives Retrieval bleibt auch bei großen Kontextfenstern sinnvoll.

61. Command R+: mehr Kapazität für komplexe RAG-Flows

R+ zielte auf anspruchsvollere Multi-Step- und Tool-Use-Aufgaben als Command R.

Historisch ist R+ ein wichtiger Zwischenschritt, aber für neue Systeme muss geprüft werden, ob aktuelle Command-A-Modelle oder A+ die bessere Lifecycle-Wahl sind.

62. Command R7B: kleine agentische Klasse

R7B demonstriert, dass Agentenfähigkeit nicht zwingend ein sehr großes Modell erfordert.

Kleinere Modelle können in kontrollierten Domänen, mit starken Tools und gutem Retrieval wirtschaftlicher sein als ein großes Frontiermodell.

63. Retrieval Query

Retrieval Query bezeichnet die Formulierung der Suchanfrage vor dem eigentlichen Abruf. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Retrieval Query mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

64. Query Rewrite

Query Rewrite bezeichnet das Umformen einer Nutzerfrage in besser suchbare Teilfragen. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Query Rewrite mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

65. First-stage Retrieval

First-stage Retrieval bezeichnet die breite Kandidatensuche über Keyword-, Vektor- oder hybride Indizes. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte First-stage Retrieval mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

66. Hybrid Search

Hybrid Search bezeichnet die Kombination lexikalischer und semantischer Signale. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Hybrid Search mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

67. Embedding-Dimension

Embedding-Dimension bezeichnet die Größe des Vektorraums und ihre Auswirkungen auf Speicher und Suche. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Embedding-Dimension mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

68. Chunking

Chunking bezeichnet die Zerlegung langer Dokumente vor Indexierung und Retrieval. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Chunking mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

69. Chunk-Overlap

Chunk-Overlap bezeichnet die Überlappung angrenzender Textsegmente zur Erhaltung von Kontext. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Chunk-Overlap mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

70. Metadata Filtering

Metadata Filtering bezeichnet die Einschränkung des Suchraums über strukturierte Metadaten. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Metadata Filtering mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

71. Rerank Top-N

Rerank Top-N bezeichnet die Zahl der Kandidaten, die nach der ersten Suche erneut bewertet werden. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Rerank Top-N mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

72. Context Packing

Context Packing bezeichnet die Auswahl und Reihenfolge von Dokumentausschnitten für den Modellkontext. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Context Packing mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

73. Citations

Citations bezeichnet die Zuordnung erzeugter Aussagen zu bereitgestellten Quellenabschnitten. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Citations mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

74. Grounded Generation

Grounded Generation bezeichnet die Beschränkung einer Antwort auf nachgelieferte Unternehmensdaten. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Grounded Generation mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

75. Tool Schema

Tool Schema bezeichnet die maschinenlesbare Beschreibung erlaubter Funktionen und Parameter. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Tool Schema mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

76. Tool Choice

Tool Choice bezeichnet die Entscheidung, ob und welches Werkzeug aufgerufen werden soll. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Tool Choice mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

77. Parallel Tool Calls

Parallel Tool Calls bezeichnet gleichzeitige Aufrufe unabhängiger Funktionen. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Parallel Tool Calls mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

78. Agent Loop

Agent Loop bezeichnet die wiederholte Folge aus planen, handeln, beobachten und fortsetzen. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Agent Loop mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

79. Conversation State

Conversation State bezeichnet der gespeicherte Zustand über mehrere Agentenschritte. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Conversation State mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

80. Structured Outputs

Structured Outputs bezeichnet schemaorientierte Ausgaben für nachgelagerte Verarbeitung. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Structured Outputs mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

81. Safety Modes

Safety Modes bezeichnet produktseitige Regeln für unerwünschte oder riskante Ausgaben. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Safety Modes mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

82. Multilingual Routing

Multilingual Routing bezeichnet die Auswahl von Modell, Retrieval und Terminologie je Sprache. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Multilingual Routing mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

83. Long Context

Long Context bezeichnet das Verhalten bei sehr großen Eingabekontexten. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Long Context mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

84. Max Output

Max Output bezeichnet das unabhängige Limit für generierbare Ausgabetokens. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Max Output mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

85. Knowledge Cutoff

Knowledge Cutoff bezeichnet den Wissensstand des trainierten Modells ohne aktuelle Retrievaldaten. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Knowledge Cutoff mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

86. Latency

Latency bezeichnet Zeit bis zum ersten Token und laufender Token-Durchsatz. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Latency mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

87. Throughput

Throughput bezeichnet verarbeitete Token oder Requests pro Zeiteinheit unter Last. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Throughput mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

88. Batching

Batching bezeichnet das Bündeln mehrerer Anfragen zur besseren Hardwareauslastung. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Batching mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

89. Quantisierung

Quantisierung bezeichnet reduzierte Zahlenpräzision zur Senkung von Speicher- und Rechenbedarf. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Quantisierung mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

90. KV-Cache

KV-Cache bezeichnet Zwischenspeicher von Attention-Zuständen bei langer Generierung. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte KV-Cache mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

91. MoE Routing

MoE Routing bezeichnet die tokenweise Auswahl aktiver Experten in Sparse-Modellen. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte MoE Routing mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

92. Active Parameters

Active Parameters bezeichnet der pro Token tatsächlich berechnete Teil eines MoE-Modells. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Active Parameters mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

93. Total Parameters

Total Parameters bezeichnet der gesamte Gewichtsbestand einschließlich inaktiver Experten. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Total Parameters mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

94. Private Inference

Private Inference bezeichnet Modellbetrieb in kundenseitig kontrollierter Infrastruktur. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Private Inference mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

95. Model Vault

Model Vault bezeichnet dedizierte Cohere-verwaltete Inferenz mit Isolation. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Model Vault mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

96. VPC Deployment

VPC Deployment bezeichnet Betrieb im privaten Netzwerkbereich eines Cloudkontos. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte VPC Deployment mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

97. On-Premises

On-Premises bezeichnet Betrieb auf eigener lokaler Hardware. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte On-Premises mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

98. Air Gap

Air Gap bezeichnet Netzwerkisolation besonders sensibler Systeme. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Air Gap mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

99. SaaS API

SaaS API bezeichnet mehrmandantenfähiger gehosteter Zugriff ohne eigene Serving-Infrastruktur. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte SaaS API mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

100. Cloud Marketplace

Cloud Marketplace bezeichnet Bereitstellung über AWS, Azure, OCI oder andere Plattformen. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Cloud Marketplace mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

101. Model Versioning

Model Versioning bezeichnet feste Modell-IDs und datierte Snapshots. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Model Versioning mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

102. Deprecation

Deprecation bezeichnet angekündigte Ablösung eines Modell- oder API-Pfads. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Deprecation mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

103. Retirement

Retirement bezeichnet das tatsächliche Ende der Verfügbarkeit. In einem Cohere-System ist diese Schicht getrennt vom eigentlichen Foundation-Modell zu betrachten.

Für Fehlersuche und Reproduzierbarkeit sollte Retirement mit konkreten Parametern, Versionen und Eingabedaten dokumentiert werden. Andernfalls kann eine Pipelineänderung wie ein Modellwechsel wirken.

104. Command A: 111B Dense

Command A besitzt 111 Milliarden Parameter in einer dichten Architektur.

Dense bedeutet, dass die Modellgewichte nicht wie bei einem Sparse-MoE durch einen Router in aktive Experten aufgeteilt werden.

105. Command A: 256K Kontext

Die ursprüngliche Command-A-Variante bietet 256K Kontext.

Das ist länger als A+ mit 128K Eingabekontext; neuere Modellgeneration bedeutet daher nicht automatisch größeres Kontextfenster.

106. Command A: Agenten und SQL

Command A wurde besonders für Tool Use, SQL, RAG und Enterprise-Agenten optimiert.

Die reale Agentenleistung hängt zusätzlich von Tooldesign, Berechtigungen, Datenqualität und Harness ab.

107. Command A Vision: 112B-Klasse

Command A Vision fügt der A-Familie visuelle Eingaben hinzu.

Die Variante ist historisch wichtig, obwohl A+ später multimodales Reasoning in ein konsolidiertes Modell integriert.

108. Command A Reasoning: 111B

Command A Reasoning bleibt in derselben Größenklasse wie Command A, ergänzt aber einen expliziten Reasoningpfad.

Reasoning-Version und Basismodell sind daher unterschiedliche Post-Training- beziehungsweise Fähigkeitsprofile, nicht bloß ein UI-Schalter.

109. Command A Translate: 23 Sprachen

Command A Translate fokussiert maschinelle Übersetzung für 23 Sprachen.

Für Translation sind Terminologie, Formatbeibehaltung und sprachpaarspezifische Evaluation oft wichtiger als allgemeine Chatbenchmarks.

110. Command A+: 218B/25B MoE

Command A+ besitzt 218 Milliarden Gesamt- und 25 Milliarden aktive Parameter.

Der Unterschied zwischen Gesamt- und Aktivparametern erklärt, warum MoE hohe Kapazität mit geringerer Rechenlast pro Token verbinden kann.

111. Command A+: 48 Sprachen

A+ erweitert die unterstützte Sprachabdeckung auf 48 Sprachen einschließlich aller Amtssprachen der Europäischen Union.

Breite Sprachabdeckung sollte durch lokale Tests ergänzt werden, weil Fachsprache, Dialekt und Retrievaldaten eigene Fehlerquellen bleiben.

112. Command A+: Text und Bild

A+ akzeptiert Text und Bilder als Eingabe und erzeugt Textausgaben.

Bildverständnis ist damit in das aktuelle Command-Flagship integriert; Bildgenerierung ist davon getrennt.

113. Command A+: Tool Use

A+ unterstützt strukturierte Toolnutzung für agentische Enterprise-Workflows.

Die Ausführung erfolgt außerhalb des Modellgewichts. Ein falscher Toolaufruf kann daher echte Systemwirkung entfalten und verlangt Rechtekontrolle.

114. Command A+: Apache 2.0

A+ wird unter Apache 2.0 als Open-Weight-Modell bereitgestellt.

Open Weight und private Bereitstellung schaffen Kontrolle über Gewichte und Datenpfad; sie garantieren jedoch nicht automatisch sichere Konfiguration oder korrekte Outputs.

115. Command A+: 128K Input / 64K Output

A+ trennt ein 128K-Eingabefenster von einem maximalen 64K-Ausgabebudget.

Input- und Outputlimit müssen separat geplant werden; lange Agententraces können das Ausgabelimit erreichen, obwohl der Prompt selbst deutlich kleiner ist.

116. Command A+: Hardwareklasse

Cohere nennt 1× B200 oder 2× H100 bei geeigneter W4A4-Konfiguration als Minimalpfade.

Diese Angaben hängen von Quantisierung, Runtime und Servingkonfiguration ab und sind keine Garantie für jede Community-Implementierung.

117. Aya als Open-Science-Projekt

Aya verbindet Modellentwicklung mit globaler Forschungscommunity und multilingualen Datensätzen.

Aya als Open-Science-Projekt gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

118. Aya-101

Aya-101 steht für sehr breite Sprachabdeckung in der ersten Modellgeneration.

Aya-101 gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

119. Aya 23 8B

Die 8B-Variante senkt Hardwarebedarf bei fokussierter 23-Sprachen-Abdeckung.

Aya 23 8B gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

120. Aya 23 35B

Die 35B-Variante bietet mehr Kapazität für dieselbe fokussierte Sprachfamilie.

Aya 23 35B gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

121. Aya Expanse 8B

Die kleinere Expanse-Variante war Teil des 2024er Pfads und wurde später aus der Cohere-API-Lifecycle-Liste entfernt.

Aya Expanse 8B gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

122. Aya Expanse 32B

Die 32B-Variante bleibt ein zentraler multilingualer Open-Weight-Pfad.

Aya Expanse 32B gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

123. Aya Vision 32B

Aya Vision verbindet multilingualen Text mit visuellen Eingaben.

Aya Vision 32B gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

124. Tiny Aya Global

Global zielt auf ausgewogene 70+-Sprachen-Abdeckung in 3,35B Größe.

Tiny Aya Global gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

125. Tiny Aya Earth

Earth priorisiert westasiatische und afrikanische Sprachräume.

Tiny Aya Earth gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

126. Tiny Aya Fire

Fire priorisiert südasiatische Sprachräume.

Tiny Aya Fire gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

127. Tiny Aya Water

Water priorisiert europäische und asiatisch-pazifische Sprachräume.

Tiny Aya Water gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

128. Aya-Lizenzierung

Aya-Modelle verwenden je nach Generation offene Gewichte mit eigenen beziehungsweise CC-BY-NC-Bedingungen; Lizenz muss pro Checkpoint geprüft werden.

Aya-Lizenzierung gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

129. Multilinguale Evaluation

Durchschnittswerte können schwache Einzelsprachen verdecken; Evaluation sollte pro Sprache und Aufgabe erfolgen.

Multilinguale Evaluation gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

130. Code-Mixing

Gemischte Sprachen innerhalb eines Prompts können Safety- und Qualitätsverhalten verändern.

Code-Mixing gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

131. On-device Aya

Tiny Aya macht lokale mehrsprachige Assistenz auf deutlich kleineren Systemen realistischer.

On-device Aya gehört zur Forschungsfamilie und sollte nicht automatisch mit dem kommerziellen Command- oder North-Supportmodell gleichgesetzt werden. Für produktive Nutzung werden Lizenz, Runtime, Hardware, Safety und Sprachqualität separat geprüft.

132. Embed 4: multimodale Embeddings

Embed 4 kann Text, Bilder und gemischte Dokumentinhalte in einen gemeinsamen Retrievalraum überführen.

Die Vektordimension ist konfigurierbar; Speicherbedarf, Recall und nachfolgende Rerankstufe sollten gemeinsam evaluiert werden.

133. Embed 4: 128K Kontext

Der große Kontext erlaubt die Repräsentation umfangreicherer Dokumentinhalte.

Trotzdem ist ein einzelner großer Embedding-Input nicht automatisch besser als gut strukturiertes Chunking.

134. Rerank 4 Pro

Rerank 4 Pro priorisiert höchste Rankingqualität für komplexe Retrievalaufgaben.

Die zusätzliche Rankingstufe kostet Latenz, kann aber die Qualität des an Command übergebenen Kontexts deutlich erhöhen.

135. Rerank 4 Fast

Rerank 4 Fast priorisiert Durchsatz und geringe Latenz.

Für interaktive Suche kann Fast sinnvoller sein, wenn der Qualitätsabstand zu Pro im eigenen Korpus klein ist.

136. Rerank 4 und JSON

Rerank 4 kann auch semistrukturierte Daten bewerten.

Feldbezeichnungen und Serialisierung beeinflussen Relevanzsignale; rohe JSON-Mengen sollten nicht blind übergeben werden.

137. Parse v5: 2,3B

Parse v5 ist ein spezialisiertes 2,3B-Dokumentmodell und keine allgemeine Command-Variante.

Seine Stärke liegt in strukturierter Extraktion als Vorstufe für Suche, RAG und Agenten.

138. Parse v5: Markdown-Ausgabe

Parse liefert strukturierte Markdown-Ausgabe mit dokumentnaher Reihenfolge.

Für nachfolgende Systeme muss zwischen semantischer Textstruktur und exakter Layoutrekonstruktion unterschieden werden.

139. Parse v5: Bounding Boxes

Räumliche Koordinaten helfen, Tabellen, Abbildungen und Textblöcke auf der Originalseite zu verorten.

Das ist für visuelle Grounding-Prüfung wertvoll, ersetzt aber keine menschliche Kontrolle bei kritischen Dokumenten.

140. Compass als End-to-End-Suche

Compass bündelt Konnektoren, Verarbeitung, Indexierung und Retrieval als fertiges Suchsystem.

Compass ist damit eine Produktschicht über Parse, Embed, Rerank und weiteren Komponenten, nicht ein einzelner Foundation-Checkpoint.

141. Document-level Security

Enterprise Search muss die Berechtigungen der Ursprungssysteme bis zum Treffer und zur generierten Antwort respektieren.

Ein semantisch relevanter Treffer darf nicht erscheinen, wenn der anfragende Benutzer das Quelldokument nicht lesen darf.

142. North als Enterprise Workspace

North verbindet Chat, Unternehmenssuche, Inhaltserstellung, Agenten und Automations in einer kontrollierten Arbeitsoberfläche.

North als Enterprise Workspace muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

143. North Discover

Discover steht für Suche und verifizierbare Erkenntnisse auf verbundenen Unternehmensdaten.

North Discover muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

144. North Create

Create bündelt Dokument-, Zusammenfassungs-, Tabellen- und andere generative Arbeitsabläufe.

North Create muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

145. North Automate

Automate nutzt Agenten und Workflows für wiederkehrende oder mehrstufige Prozesse.

North Automate muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

146. North Agents

Benutzerdefinierte Agenten kombinieren Modell, Instruktionen, Tools, Datenzugriff und Berechtigungen.

North Agents muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

147. North Automations

Automations orchestriert mehrere Schritte, Trigger und Agenten mit Governance.

North Automations muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

148. Human in the Loop

Sensible Schritte sollten explizite Freigabe- und Prüfpfade besitzen.

Human in the Loop muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

149. North Connectors

Konnektoren bringen Daten aus bestehenden Unternehmenssystemen in Suche und Agenten.

North Connectors muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

150. ACL Adherence

Zugriffsregeln aus Quellsystemen müssen auch in Retrieval und generierter Antwort wirksam bleiben.

ACL Adherence muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

151. Auditability

Agentische Systeme benötigen nachvollziehbare Protokolle für Datenzugriff und Aktionen.

Auditability muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

152. North in VPC

North kann innerhalb einer kundenseitig kontrollierten Private-Cloud-Umgebung betrieben werden.

North in VPC muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

153. North On-Premises

Für besonders sensible Workloads kann North in eigener Infrastruktur betrieben werden.

North On-Premises muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

154. North auf Model Vault

Model Vault bietet eine Cohere-verwaltete, dedizierte Bereitstellungsform auch für North.

North auf Model Vault muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

155. North ≠ Command

North verwendet Modelle, ist aber selbst ein Produkt mit zusätzlichem Zustand, Search, Connectors, Agenten und Governance.

North ≠ Command muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

156. North ≠ Compass

Compass ist Such- und Discovery-System; North ist der breitere Workplace- und Agentenstack.

North ≠ Compass muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

157. Coral → North

Coral ist historischer Vorläufer einer Enterprise-Knowledge-Assistentenlinie, North die spätere umfassendere Plattform.

Coral → North muss bei Tests mit konkreter Deploymentform, verbundenen Datenquellen, Benutzerrechten und Modellversion dokumentiert werden. Sonst lässt sich Produktverhalten nicht reproduzieren.

158. North Mini Code: 30B/3B MoE

North Mini Code besitzt 30B Gesamt- und etwa 3B aktive Parameter.

Bei North Mini Code: 30B/3B MoE sind Harness, Toolset, Repositoryzustand und Sandbox mindestens so wichtig wie der Modellcheckpoint. Ein Benchmark ohne diese Angaben ist nur eingeschränkt reproduzierbar.

159. North Mini Code: Apache 2.0

Die Gewichte stehen unter Apache 2.0 bereit.

Bei North Mini Code: Apache 2.0 sind Harness, Toolset, Repositoryzustand und Sandbox mindestens so wichtig wie der Modellcheckpoint. Ein Benchmark ohne diese Angaben ist nur eingeschränkt reproduzierbar.

160. North Mini Code: Agentic Coding

Das Modell ist für mehrstufige Softwareengineering-Aufgaben und Coding-Harnesses trainiert.

Bei North Mini Code: Agentic Coding sind Harness, Toolset, Repositoryzustand und Sandbox mindestens so wichtig wie der Modellcheckpoint. Ein Benchmark ohne diese Angaben ist nur eingeschränkt reproduzierbar.

161. North Mini Code: Architekturverständnis

Repository-Navigation und Systemarchitektur gehören zu den Zielaufgaben.

Bei North Mini Code: Architekturverständnis sind Harness, Toolset, Repositoryzustand und Sandbox mindestens so wichtig wie der Modellcheckpoint. Ein Benchmark ohne diese Angaben ist nur eingeschränkt reproduzierbar.

162. North Mini Code: Code Review

Agentische Review-Aufgaben verbinden Quelltextanalyse mit Tool- und Repositorykontext.

Bei North Mini Code: Code Review sind Harness, Toolset, Repositoryzustand und Sandbox mindestens so wichtig wie der Modellcheckpoint. Ein Benchmark ohne diese Angaben ist nur eingeschränkt reproduzierbar.

163. North Mini Code: OpenCode

Cohere trainierte auf Kompatibilität mit OpenCode; andere Harnesses bleiben möglich.

Bei North Mini Code: OpenCode sind Harness, Toolset, Repositoryzustand und Sandbox mindestens so wichtig wie der Modellcheckpoint. Ein Benchmark ohne diese Angaben ist nur eingeschränkt reproduzierbar.

164. North Mini Code: lokale Nutzung

Die kleine aktive MoE-Klasse kann lokale beziehungsweise private Coding-Deployments wirtschaftlicher machen.

Bei North Mini Code: lokale Nutzung sind Harness, Toolset, Repositoryzustand und Sandbox mindestens so wichtig wie der Modellcheckpoint. Ein Benchmark ohne diese Angaben ist nur eingeschränkt reproduzierbar.

165. Codingagent ≠ Completionmodell

Agentisches Coding umfasst Lesen, Planen, Shell, Tests und Dateiedits; reine Autovervollständigung ist eine andere Aufgabe.

Bei Codingagent ≠ Completionmodell sind Harness, Toolset, Repositoryzustand und Sandbox mindestens so wichtig wie der Modellcheckpoint. Ein Benchmark ohne diese Angaben ist nur eingeschränkt reproduzierbar.

166. Repositoryrechte

Ein Codingagent sollte nur auf benötigte Repositories, Branches und Secrets zugreifen.

Bei Repositoryrechte sind Harness, Toolset, Repositoryzustand und Sandbox mindestens so wichtig wie der Modellcheckpoint. Ein Benchmark ohne diese Angaben ist nur eingeschränkt reproduzierbar.

167. Testpflicht

Automatisch erzeugte Patches müssen durch Tests, Linter und Review überprüft werden.

Bei Testpflicht sind Harness, Toolset, Repositoryzustand und Sandbox mindestens so wichtig wie der Modellcheckpoint. Ein Benchmark ohne diese Angaben ist nur eingeschränkt reproduzierbar.

168. Cohere Transcribe: 2B ASR

Ein 2B-Conformer-basiertes Speech-to-Text-Modell mit Transformer-Decoder.

Cohere Transcribe: 2B ASR sollte mit Originalaudio, Sprache, Samplingbedingungen und exakter Modellversion archiviert werden. Textausgabe allein reicht nicht, um spätere Abweichungen zu erklären.

169. 14 Sprachen im Grundmodell

Das März-2026-Modell wurde für 14 Sprachen trainiert.

14 Sprachen im Grundmodell sollte mit Originalaudio, Sprache, Samplingbedingungen und exakter Modellversion archiviert werden. Textausgabe allein reicht nicht, um spätere Abweichungen zu erklären.

170. Transcribe Arabic

Eine Juli-2026-Variante ist gezielt auf arabische Audiodaten optimiert.

Transcribe Arabic sollte mit Originalaudio, Sprache, Samplingbedingungen und exakter Modellversion archiviert werden. Textausgabe allein reicht nicht, um spätere Abweichungen zu erklären.

171. WER als ASR-Metrik

Word Error Rate misst Erkennungsfehler, bildet aber nicht alle fachlichen Transkriptionsprobleme ab.

WER als ASR-Metrik sollte mit Originalaudio, Sprache, Samplingbedingungen und exakter Modellversion archiviert werden. Textausgabe allein reicht nicht, um spätere Abweichungen zu erklären.

172. Diarization

Sprechertrennung ist von reiner Worterkennung zu unterscheiden und kann gesonderte Pipelinekomponenten benötigen.

Diarization sollte mit Originalaudio, Sprache, Samplingbedingungen und exakter Modellversion archiviert werden. Textausgabe allein reicht nicht, um spätere Abweichungen zu erklären.

173. Punctuation

Interpunktion in Transkripten ist eine Textrekonstruktionsschicht und kann semantisch relevant sein.

Punctuation sollte mit Originalaudio, Sprache, Samplingbedingungen und exakter Modellversion archiviert werden. Textausgabe allein reicht nicht, um spätere Abweichungen zu erklären.

174. Fachbegriffe im Audio

Eigennamen und Domänenterminologie benötigen separate Tests oder Biasing-Mechanismen, wenn verfügbar.

Fachbegriffe im Audio sollte mit Originalaudio, Sprache, Samplingbedingungen und exakter Modellversion archiviert werden. Textausgabe allein reicht nicht, um spätere Abweichungen zu erklären.

175. Audio Privacy

Sprachaufnahmen können besonders sensible personenbezogene Informationen enthalten und benötigen klare Datenpfade.

Audio Privacy sollte mit Originalaudio, Sprache, Samplingbedingungen und exakter Modellversion archiviert werden. Textausgabe allein reicht nicht, um spätere Abweichungen zu erklären.

176. SaaS Deployment

Cohere betreibt Modellinferenz als vollständig verwalteten Dienst.

SaaS Deployment muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

177. Private VPC

Modelle laufen in einem isolierten virtuellen Netzwerk unter Kontrolle des Unternehmenskontos.

Private VPC muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

178. On-Premises

Modelle laufen auf eigener Hardware im lokalen Rechenzentrum.

On-Premises muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

179. Air-gapped On-Premises

Netzwerkisolation verhindert regulären externen Datenverkehr und erhöht Betriebsverantwortung.

Air-gapped On-Premises muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

180. Public/Hybrid Cloud

Private und öffentliche Ressourcen können nach Workload kombiniert werden.

Public/Hybrid Cloud muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

181. Model Vault Standard

Dedizierte, Cohere-verwaltete Single-Tenant-Inferenz mit isolierten Servingkomponenten.

Model Vault Standard muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

182. Model Vault Encrypted

Eine Vault-Variante kann zusätzliche Schutzmechanismen für Daten in Nutzung einsetzen.

Model Vault Encrypted muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

183. Zero Data Retention

ZDR kann für bestimmte Deployments bedeuten, dass Prompts und Antworten nicht dauerhaft gespeichert werden.

Zero Data Retention muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

184. Noisy Neighbor

Dedizierte Inferenz verhindert Leistungsbeeinflussung durch andere Mandanten auf derselben Servinginstanz.

Noisy Neighbor muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

185. Region

Der physische oder logische Standort einer Inferenz ist eine separate Compliance-Eigenschaft.

Region muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

186. Cloud Provider

AWS, Azure, GCP oder OCI verändern Betriebs- und Vertragskontext, nicht die semantische Modellfamilie.

Cloud Provider muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

187. Sovereign AI

Souveränität umfasst Datenkontrolle, Modellkontrolle, Infrastruktur, Jurisdiktion und Betriebsabhängigkeiten.

Sovereign AI muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

188. Open Weight und Souveränität

Offene Gewichte erleichtern Self-Hosting, garantieren aber keine organisatorische oder rechtliche Souveränität.

Open Weight und Souveränität muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

189. Aleph-Alpha-Allianz

Das 2026 angekündigte Zusammengehen stärkt die Kanada-Europa-Sovereignty-Strategie.

Aleph-Alpha-Allianz muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

190. STACKIT-Bezug

Die Partnerschaft nennt STACKIT als Infrastrukturbaustein für europäische souveräne Angebote.

STACKIT-Bezug muss in Architektur- und Datenschutzdokumentation explizit festgehalten werden. Derselbe Modellname kann in unterschiedlichen Deploymentpfaden völlig andere Datenflüsse und Verantwortlichkeiten besitzen.

191. Cohere Chat API

Generative Modelle werden über Chat-Endpunkte angesprochen.

Cohere Chat API sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

192. V1 und V2

API-Generationen unterscheiden Request- und Responseformate sowie verfügbare Funktionen.

V1 und V2 sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

193. OpenAI-kompatible Schnittstellen

Kompatibilitätsschichten können Migration erleichtern, decken aber nicht automatisch jede native Cohere-Funktion ab.

OpenAI-kompatible Schnittstellen sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

194. SDKs

Cohere stellt SDKs für mehrere Programmiersprachen bereit.

SDKs sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

195. Streaming

Streaming liefert Ausgabetokens schrittweise und verändert Clientfehlerbilder.

Streaming sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

196. Retries

Wiederholungen müssen idempotente und nicht-idempotente Aktionen unterscheiden.

Retries sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

197. Rate Limits

Limits hängen von Account, Produkt und Deployment ab.

Rate Limits sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

198. Timeouts

Lange Reasoning- oder Tool-Workflows benötigen andere Timeoutstrategien als kurze Chats.

Timeouts sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

199. Request IDs

Korrelations- und Request-IDs erleichtern Support und Loganalyse.

Request IDs sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

200. Model ID

Feste IDs sind reproduzierbarer als bewegliche Aliasnamen.

Model ID sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

201. Chat History

Gesprächsverlauf muss bewusst begrenzt, versioniert oder zusammengefasst werden.

Chat History sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

202. Documents im Prompt

Dokumente als Grounding sollten Herkunft und Berechtigungsstatus mitführen.

Documents im Prompt sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

203. Tool Results

Werkzeugrückgaben sind untrusted input und können Prompt-Injection enthalten.

Tool Results sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

204. JSON Schema

Strukturierte Ausgaben brauchen serverseitige Validierung.

JSON Schema sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

205. Citations API

Zitationsmetadaten helfen bei der Zuordnung von Antwortteilen zu Quellen.

Citations API sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

206. Embed API

Vektorisierung ist ein eigener Endpoint mit eigenen Limits und Dimensionen.

Embed API sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

207. Rerank API

Reranking akzeptiert Query und Kandidatendokumente und liefert Scores/Reihenfolge.

Rerank API sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

208. Parse API

Dokumentdateien werden in strukturierte Inhalte überführt.

Parse API sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

209. Audio Transcriptions API

Audioeingaben werden über einen dedizierten Transkriptionspfad verarbeitet.

Audio Transcriptions API sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

210. Batch und Offline-Verarbeitung

Große Mengen sollten getrennt von interaktiven Latenzanforderungen geplant werden.

Batch und Offline-Verarbeitung sollte in Produktionssystemen mit Version, Limits, Fehlercodes und Observability dokumentiert werden. Ein SDK-Upgrade kann Verhalten verändern, obwohl der Modellname gleich bleibt.

211. Privacy Policy vom 1. Mai 2026

Die aktuelle Datenschutzrichtlinie trennt Website-/Trial-Kontext, Enterprise-Nutzung, Endnutzer und private Deployments.

Privacy Policy vom 1. Mai 2026 ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

212. Enterprise Customer Data

Eingaben und Ausgaben unter Enterprise-Verträgen werden durch Vertrag und gegebenenfalls DPA geregelt.

Enterprise Customer Data ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

213. Private Deployment Data

Bei privaten oder Drittanbieter-Deployments erklärt Cohere, keinen Zugriff auf die dort verarbeiteten Daten zu haben.

Private Deployment Data ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

214. Training Controls

Enterprise-Kunden können vertraglich steuern, wie Daten für Training verwendet werden.

Training Controls ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

215. Model Training Privacy Notice

Trainingsdatenfragen sind von normaler Produktdatenverarbeitung zu unterscheiden.

Model Training Privacy Notice ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

216. International Transfers

Jurisdiktion und internationale Übertragungen hängen vom jeweiligen Vertrags- und Deploymentkontext ab.

International Transfers ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

217. Data Retention

Aufbewahrung ist eine eigene Eigenschaft und nicht gleichbedeutend mit Training.

Data Retention ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

218. Logs

Betriebslogs können Metadaten enthalten, auch wenn Prompts nicht für Training verwendet werden.

Logs ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

219. Access Control

Administratoren und Services sollten nur minimal notwendige Rechte besitzen.

Access Control ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

220. Prompt Injection

Externe Dokumente können Anweisungen enthalten, die ein Agent nicht als vertrauenswürdige Regeln behandeln darf.

Prompt Injection ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

221. Indirect Prompt Injection

Retrievalquellen, Webseiten und Dateien können versteckte manipulative Instruktionen transportieren.

Indirect Prompt Injection ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

222. Tool Authorization

Ein Modellvorschlag ist keine Autorisierung für eine reale Aktion.

Tool Authorization ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

223. Secrets

API-Keys, Tokens und Passwörter gehören in Secret-Stores, nicht in normale Prompts.

Secrets ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

224. Audit Logs

Nachvollziehbare Aktionen sind besonders bei Agents und Automations erforderlich.

Audit Logs ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

225. Human Approval

Irreversible oder sensible Aktionen sollten einen Freigabeschritt besitzen.

Human Approval ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

226. Least Privilege

Agenten erhalten nur die Daten- und Toolrechte, die für die konkrete Aufgabe notwendig sind.

Least Privilege ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

227. Data Exfiltration

Tool- und Connector-Ketten können Daten ungewollt an externe Systeme übertragen.

Data Exfiltration ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

228. Search ACL

Retrieval darf keine Inhalte aus Dokumenten liefern, für die der Nutzer keine Berechtigung besitzt.

Search ACL ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

229. Document Poisoning

Manipulierte Dokumente können Retrieval- und Agentenergebnisse systematisch beeinflussen.

Document Poisoning ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

230. Model Signing

Signaturen und Artefaktprüfung helfen, manipulierte Modellpakete in der Lieferkette zu erkennen.

Model Signing ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

231. Supply Chain

Container, Runtime, CUDA, Python-Pakete und Modellartefakte bilden gemeinsam die AI-Supply-Chain.

Supply Chain ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

232. Safety Evaluation

Sicherheitsverhalten muss pro Sprache, Modalität und Agentenpfad getestet werden.

Safety Evaluation ist keine reine Modellfrage. Deployment, Vertrag, Connectoren, Logging, Retention und organisatorische Rechte bestimmen den tatsächlichen Risikopfad mindestens ebenso stark.

233. RAG-Architektur: Ingestion

Dokumente werden aufgenommen, normalisiert und für nachfolgende Retrievalschritte vorbereitet.

Fehler in der Ingestion propagieren bis zur generierten Antwort; Originaldatei, Parser-Version und Ingestionszeitpunkt müssen nachvollziehbar bleiben.

234. RAG-Architektur: Normalisierung

Zeichenkodierung, Unicode, Whitespace, Tabellen und Metadaten werden in eine konsistente Form gebracht.

Zu aggressive Normalisierung kann bedeutungstragende Struktur verlieren; insbesondere juristische, technische und tabellarische Dokumente benötigen konservative Regeln.

235. RAG-Architektur: Dokumentidentität

Jedes Quelldokument benötigt eine stabile ID, Version und Herkunft.

Ohne stabile Identität lassen sich Löschung, ACL, Reindexierung und Citation-Rekonstruktion nicht zuverlässig durchführen.

236. RAG-Architektur: Chunk-Grenzen

Chunk-Grenzen sollten semantische Einheiten respektieren, statt nur starre Tokenzahlen zu verwenden.

Überschriften, Tabellen, Absätze und Listen können eigene Segmentierungsregeln benötigen.

237. RAG-Architektur: Parent-Child-Chunks

Kleine Chunks verbessern präzises Retrieval, größere Parent-Blöcke liefern Kontext für die Antwort.

Parent-Child-Strategien reduzieren den Zielkonflikt zwischen Retrievalpräzision und ausreichend zusammenhängendem Kontext.

238. RAG-Architektur: Tabellen-Chunks

Tabellen sollten Header und relevante Zeilenbeziehungen erhalten.

Einzelne Zellen ohne Header sind semantisch oft wertlos und führen zu falschem Retrieval.

239. RAG-Architektur: Bild- und Textsignale

Embed 4 kann multimodale Dokumentbestandteile gemeinsam erschließen.

Bild- und Textrepräsentation muss gegen das reale Korpus evaluiert werden; visuelle Relevanz kann von textueller Relevanz abweichen.

240. RAG-Architektur: Indexversion

Ein Index ist ein versioniertes Produktionsartefakt.

Embeddingmodell, Dimension, Chunking und Metadatenfelder bestimmen seine Semantik und müssen gemeinsam versioniert werden.

241. RAG-Architektur: Reindexierung

Ein Wechsel des Embeddingmodells erfordert normalerweise eine vollständige Neuerzeugung der Vektoren.

Alte und neue Embeddings in demselben Index zu mischen ist nur mit explizit kompatiblen Räumen sinnvoll.

242. RAG-Architektur: Hybridgewichtung

Lexikalische und semantische Scores benötigen eine definierte Fusion.

Gewichte sollten auf einem gelabelten Query-Dokument-Datensatz optimiert werden, nicht nach Bauchgefühl.

243. RAG-Architektur: Recall@K

Recall@K misst, ob relevante Dokumente in der Kandidatenmenge auftauchen.

Ein schlechter Recall kann von keinem späteren Reranker vollständig repariert werden.

244. RAG-Architektur: Precision@K

Precision@K misst den Anteil wirklich relevanter Treffer in der betrachteten Spitzengruppe.

Hohe Precision reduziert Kontextverschmutzung und Kosten, darf aber Recall nicht zu stark opfern.

245. RAG-Architektur: NDCG

NDCG bewertet nicht nur Treffer, sondern ihre Reihenfolge und abgestufte Relevanz.

Für Rerank-Evaluation ist eine rangsensitive Metrik häufig aussagekräftiger als binäre Trefferquote.

246. RAG-Architektur: MRR

Mean Reciprocal Rank belohnt Systeme, die den ersten relevanten Treffer sehr weit oben platzieren.

Für Q&A-Suche mit einem dominanten Primärdokument kann MRR besonders verständlich sein.

247. RAG-Architektur: Query Sets

Produktive Retrievaltests brauchen reale, repräsentative Fragen aus der eigenen Domäne.

Synthetische Fragen sind nützlich, dürfen reale Sprachvarianten und Tippfehler aber nicht vollständig ersetzen.

248. RAG-Architektur: Hard Negatives

Ähnliche, aber falsche Dokumente sind besonders wertvolle Testfälle für Rerank.

Sie zeigen, ob das System nur thematische Nähe oder tatsächliche Antwortrelevanz erkennt.

249. RAG-Architektur: Temporal Relevance

Aktuelle Dokumente können bei gleicher Semantik höher priorisiert werden.

Zeitgewichtung darf historische Primärquellen nicht ungewollt verdrängen, wenn die Frage ausdrücklich historisch ist.

250. RAG-Architektur: Authority Weighting

Source-of-Truth-Dokumente können gegenüber sekundären Notizen priorisiert werden.

Autorität sollte als Metadatum explizit modelliert werden statt indirekt über Dateinamen zu raten.

251. RAG-Architektur: Deduplication

Nahezu identische Dokumentversionen können Ranking und Kontext künstlich dominieren.

Hashing, SimHash oder semantische Deduplikation reduzieren redundante Treffer.

252. RAG-Architektur: Canonical Source

Für mehrere Kopien desselben Inhalts sollte eine kanonische Quelle definiert werden.

Citation und Aktualisierung werden dadurch konsistenter.

253. RAG-Architektur: Query Classification

Fragen können vor Retrieval nach Typ klassifiziert werden, etwa Fakt, Vergleich, Zeitraum oder Aggregation.

Die Klassifikation kann Suchstrategie und Filter steuern, sollte aber falsche harte Routingentscheidungen vermeiden.

254. RAG-Architektur: Multi-Query Retrieval

Mehrere umformulierte Suchanfragen können Recall erhöhen.

Mehr Querys erhöhen Kosten und Duplikate; Ergebnisse müssen zusammengeführt und rerankt werden.

255. RAG-Architektur: Decomposition

Komplexe Fragen können in Teilfragen zerlegt und separat recherchiert werden.

Die spätere Synthese muss erkennen, ob Teilantworten aus kompatiblen Quellen und Zeitständen stammen.

256. RAG-Architektur: Answerability

Das System sollte erkennen dürfen, dass die vorhandenen Quellen keine ausreichende Antwort enthalten.

Ein expliziter Nichtwissen-Pfad ist sicherer als erzwungene Generierung aus schwacher Evidenz.

257. RAG-Architektur: Citation Coverage

Nicht nur einzelne Quellenlinks, sondern der Anteil tatsächlich belegter Aussagen sollte gemessen werden.

Hohe Citation Coverage sagt noch nichts darüber aus, ob die jeweilige Quelle die Aussage korrekt stützt.

258. RAG-Architektur: Citation Correctness

Jede Zitation muss semantisch zur konkreten Aussage passen.

Automatische Checks können offensichtliche Fehlzuordnungen finden, kritische Aussagen benötigen dennoch manuelle Stichproben.

259. RAG-Architektur: Retrieval Latency

First-stage Search, Rerank und Generator tragen getrennt zur Gesamtlatenz bei.

Profiling pro Stufe zeigt, ob ein schnelleres Modell überhaupt die dominante Verzögerung adressiert.

260. RAG-Architektur: Retrieval Cost

Embedding, Rerank und Generation erzeugen unterschiedliche Kostenprofile.

Optimierung sollte auf Kosten pro erfolgreicher Aufgabe statt nur Tokenpreis pro Modell zielen.

261. RAG-Architektur: Cache

Häufige Querys oder stabile Retrievalresultate können gecacht werden.

ACL, Dokumentversion und Benutzerkontext müssen Teil des Cache-Schlüssels sein, sonst drohen Datenlecks.

262. RAG-Architektur: ACL vor Rerank

Nicht autorisierte Dokumente sollten möglichst vor Rerank und Kontextbau ausgeschlossen werden.

Das reduziert sowohl Datenschutzrisiko als auch unnötige Rechenkosten.

263. RAG-Architektur: ACL nach Sync

Berechtigungsänderungen müssen zeitnah in den Suchindex gelangen.

Ein fachlich aktueller Index mit veralteter ACL ist sicherheitstechnisch trotzdem falsch.

264. RAG-Architektur: Tenant Isolation

Mandantendaten müssen in Index, Cache und Logs voneinander isoliert bleiben.

Eine gemeinsame Modellinstanz darf nicht zu einem gemeinsamen Retrievalraum ohne Zugriffstrennung führen.

265. RAG-Architektur: Poisoned Documents

Absichtlich manipulierte Dokumente können Ranking und Agentenverhalten beeinflussen.

Quellenvertrauen, Änderungsprotokolle und Prompt-Injection-Filter gehören deshalb in die Ingestion- und Retrievalschicht.

266. RAG-Architektur: Stale Embeddings

Ein aktualisiertes Dokument mit altem Vektor kann veraltete Semantik liefern.

Content-Hash und Indexstatus sollten sicherstellen, dass Text und Embedding dieselbe Version repräsentieren.

267. RAG-Architektur: Evaluation Drift

Ein Retrievalsystem kann sich durch neue Dokumente verschlechtern, obwohl Modell und Code gleich bleiben.

Regelmäßige Evaluation auf fixen Kontrollquerys erkennt Korpusdrift.

268. RAG-Architektur: Multilingual Search

Querysprache und Dokumentsprache können verschieden sein.

Mehrsprachige Embeddings und Reranking müssen Cross-Lingual-Retrieval explizit auf realen Sprachpaaren testen.

269. RAG-Architektur: Translational Retrieval

Eine Query kann vor Suche übersetzt oder direkt multilingual eingebettet werden.

Übersetzung fügt eine Fehlerquelle hinzu, kann aber spezialisierte monolinguale Indizes erschließen.

270. RAG-Architektur: Numeric Search

Semantische Embeddings sind bei exakten Nummern, IDs oder Teilenummern oft schwächer.

Lexikalische oder strukturierte Filter sollten für exakte Kennungen parallel bestehen.

271. RAG-Architektur: Date Search

Datumsfragen profitieren von strukturierten Zeitmetadaten statt nur semantischer Ähnlichkeit.

Zeitzonen, Veröffentlichungsdatum und Gültigkeitszeitraum sollten getrennte Felder sein.

272. RAG-Architektur: Entity Search

Entitäten sollten über stabile IDs oder normalisierte Namen identifizierbar sein.

Nur semantische Ähnlichkeit kann gleichnamige Personen, Produkte oder Standorte vermischen.

273. RAG-Architektur: Federated Search

Mehrere Suchsysteme können parallel abgefragt und anschließend gemeinsam rerankt werden.

Scores verschiedener Systeme sind meist nicht direkt vergleichbar und benötigen Normalisierung oder gemeinsame Rerankstufe.

274. RAG-Architektur: Search Fallback

Bei Ausfall eines Retrievaldienstes sollte das System definieren, ob es fehlschlägt oder mit reduziertem Modus weiterarbeitet.

Eine unbelegte Modellantwort als stiller Fallback kann gefährlicher sein als ein klarer Fehler.

275. Command A+ MoE: Router

Der Router entscheidet für jedes Token, welche Experten aktiviert werden.

Routerqualität beeinflusst Spezialisierung, Lastverteilung und Servingeffizienz.

276. Command A+ MoE: Expert Load Balance

Ungleichmäßig genutzte Experten können Hardware ungleich belasten.

Servingframeworks benötigen Strategien zur Verteilung und Kommunikation der Experten.

277. Command A+ MoE: Expert Parallelism

Experten können über mehrere GPUs verteilt werden.

Netzwerkbandbreite und Topologie werden dadurch zu einem Teil der Inferenzleistung.

278. Command A+ MoE: Tensor Parallelism

Große Matrixoperationen können zusätzlich über GPUs gesplittet werden.

Expert- und Tensor-Parallelism müssen gemeinsam auf Hardware und Batchprofil abgestimmt werden.

279. Command A+ MoE: W4A4

Cohere nennt W4A4 als wichtigen Quantisierungspfad für geringe Hardwareanforderungen.

Gewichts- und Aktivierungsquantisierung sollte mit eigener Qualitäts- und Stabilitätsmessung abgesichert werden.

280. Command A+ MoE: BF16 Referenz

BF16 kann als höherpräziser Referenzpfad für Qualitätsvergleiche dienen.

Abweichungen quantisierter Deployments lassen sich nur gegen eine klar definierte Referenz sinnvoll bewerten.

281. Command A+ MoE: KV-Cache bei 128K

Lange Kontexte erzeugen erheblichen KV-Cache-Bedarf zusätzlich zu den Modellgewichten.

Hardwareplanung nur anhand der Parameterzahl unterschätzt deshalb lange produktive Sessions.

282. Command A+ MoE: 64K Generation

Sehr lange Ausgaben können Rechenzeit, Cache und Kosten stark erhöhen.

Agenten sollten Outputbudgets passend zur Aufgabe begrenzen statt das Maximum pauschal auszunutzen.

283. Command A+ MoE: Vision Encoder

Bildinput ergänzt die Sprachverarbeitung um eine visuelle Repräsentationsschicht.

Bildauflösung, Anzahl und Vorverarbeitung beeinflussen Kontext- und Rechenbedarf.

284. Command A+ MoE: Multimodales Reasoning

Text- und Bildinformationen können gemeinsam in Schlussfolgerungen einfließen.

Ein plausibles multimodales Ergebnis muss bei kritischen Dokumenten gegen das Originalbild geprüft werden.

285. Command A+ MoE: 48 Sprachen

Die breite Sprachabdeckung erhöht Einsatzmöglichkeiten in multinationalen Unternehmen.

Terminologie, kultureller Kontext und Safety sollten dennoch sprachspezifisch evaluiert werden.

286. Command A+ MoE: EU-Sprachen

Cohere hebt die Abdeckung aller offiziellen EU-Sprachen hervor.

Das ist für europäische Enterprise-Szenarien nützlich, ersetzt aber keine datenschutzrechtliche Deploymentprüfung.

287. Command A+ MoE: Agentic QA

A+ wurde mit North-basierten Enterprise-Aufgaben evaluiert und auf agentische Wissensarbeit ausgerichtet.

Produktionsleistung hängt von North-/Harness-Konfiguration und Datenzugriff ab, nicht nur vom nackten Checkpoint.

288. Command A+ MoE: Spreadsheet Analysis

Tabellen- und Spreadsheet-Aufgaben verbinden visuelles beziehungsweise strukturiertes Verständnis mit Reasoning.

Numerische Ergebnisse sollten durch deterministische Berechnungswerkzeuge validiert werden.

289. Command A+ MoE: Translation

A+ integriert breite Übersetzungsfähigkeit in den Generalistenpfad.

Spezialisierte Translate-Modelle können für bestehende produktive Workflows dennoch relevant bleiben.

290. Command A+ MoE: RAG

A+ kann als Generator über Cohere-Retrievalpipelines eingesetzt werden.

Retrievalmetriken und Generatorqualität müssen getrennt gemessen werden.

291. Command A+ MoE: Tool Use Security

Tool Calls können reale Aktionen auslösen.

Parameterprüfung, Rollenmodell und Approval sind außerhalb des Modells zu erzwingen.

292. Command A+ MoE: System Prompt Stability

Systeminstruktionen formen Verhalten, sind aber kein kryptografischer Sicherheitsmechanismus.

Untrusted Tool- und Dokumentinhalte dürfen nicht dieselbe Autoritätsstufe erhalten.

293. Command A+ MoE: Determinismus

Samplingparameter beeinflussen Antwortvariation.

Für Regressionstests sollten Temperatur, Seed sofern verfügbar und Prompt exakt protokolliert werden.

294. Command A+ MoE: Throughput Test

Durchsatz hängt von Batch, Sequenzlänge, Quantisierung und GPU ab.

Marketingwerte sind nur unter vergleichbaren Bedingungen sinnvoll interpretierbar.

295. Command A+ MoE: TTFT

Time to First Token ist besonders für interaktive Nutzung relevant.

Ein Modell kann hohen Gesamtdurchsatz besitzen und trotzdem bei langem Prefill eine hohe TTFT zeigen.

296. Command A+ MoE: Inter-token Latency

Die Geschwindigkeit nach dem ersten Token bestimmt das subjektive Streaminggefühl.

Lange Toolpausen oder Retrievalzeiten liegen außerhalb dieser Kennzahl.

297. Command A+ MoE: Concurrency

Viele parallele Nutzer verändern Batch- und Speicherverhalten.

Ein Einzelrequest-Benchmark sagt wenig über Produktionslast.

298. Command A+ MoE: Admission Control

Bei hoher Last sollten Requests kontrolliert angenommen oder gequeued werden.

Unbegrenzte Parallelität kann Latenz für alle Nutzer verschlechtern.

299. Command A+ MoE: Prefill/Decode Trennung

Lange Eingaben belasten Prefill, lange Antworten Decode.

Kapazitätsplanung sollte beide Phasen getrennt messen.

300. Command A+ MoE: Context Truncation

Automatisches Abschneiden alter Tokens kann Systemregeln oder wichtige Quellen entfernen.

Truncationsstrategie muss bewusst festgelegt und getestet werden.

301. Command A+ MoE: Prompt Cache

Wiederkehrende lange Präfixe können potenziell gecacht werden, sofern der Servingpfad dies unterstützt.

Cache-Semantik muss mit Benutzer- und Datenisolation vereinbar sein.

302. Command A+ MoE: Reproducible Snapshot

Gewichte, Tokenizer, Chattemplate und Runtime-Version gehören zusammen.

Nur der Modellname reicht nicht für spätere Reproduktion.

303. Command A+ MoE: Model Card

Model Card und Releasepost dokumentieren Fähigkeiten, Grenzen und Einsatzbedingungen.

Sie sollten gemeinsam mit dem Checkpoint archiviert werden.

304. Command A+ MoE: Benchmark Leakage

Öffentliche Benchmarks können Teil der Entwicklungsoptimierung werden.

Eigene Blindtests aus der Unternehmensdomäne liefern robustere Entscheidungssignale.

305. Command A+ MoE: Failure Taxonomy

Fehler sollten in Retrieval-, Reasoning-, Tool-, Vision-, Sprach- und Formatfehler getrennt werden.

Nur so lässt sich erkennen, welche Systemschicht tatsächlich verbessert werden muss.

306. Command A+ MoE: Model Routing

Ein Produkt kann unterschiedliche Modelle je Aufgabe einsetzen.

Routing muss sichtbar oder protokolliert sein, wenn Ergebnisse reproduzierbar bleiben sollen.

307. Command A+ MoE: Fallback Model

Bei Kapazitäts- oder Verfügbarkeitsproblemen kann ein Ersatzmodell eingesetzt werden.

Fallbacks benötigen eigene Qualitäts- und Safety-Grenzen.

308. Command A+ MoE: Canary Rollout

Neue Modellversionen sollten zunächst auf begrenztem Traffic evaluiert werden.

Vergleichbare Logs und automatische Regressionchecks erleichtern Rollbackentscheidungen.

309. Command A+ MoE: Rollback

Ein produktiver Modellwechsel benötigt einen definierten Rückweg.

Prompt- und Schemaänderungen sollten mit dem Modellrollback kompatibel bleiben.

310. Command A+ MoE: Cost per Task

Tokenpreis oder GPU-Stunde allein misst nicht Wirtschaftlichkeit.

Entscheidend ist der Gesamtaufwand pro korrekt abgeschlossener Aufgabe inklusive Retrieval und menschlicher Korrektur.

311. North Governance: Workspace-Grenzen

Arbeitsbereiche sollten organisatorische Daten- und Rechtebereiche abbilden.

Ein globaler Workspace mit allen Daten erhöht das Schadenspotenzial fehlerhafter Retrieval- oder Agentenaktionen.

312. North Governance: Rollen

Admins, Builder und normale Nutzer benötigen unterschiedliche Rechte.

Agentenerstellung und Connectorfreigabe sollten nicht automatisch allen Nutzern offenstehen.

313. North Governance: Connector-Onboarding

Neue Datenquellen sollten mit Datenklasse, Owner und ACL-Modell registriert werden.

Ein Connector ist ein Sicherheitsobjekt, nicht nur Komfortfunktion.

314. North Governance: Connector-Offboarding

Entfernte Systeme müssen auch aus Index, Cache und Agententools verschwinden.

Nur die UI-Verbindung zu löschen reicht nicht, wenn Datenkopien bestehen bleiben.

315. North Governance: Service Accounts

Connectoren arbeiten häufig mit technischen Identitäten.

Service Accounts benötigen minimale Rechte und regelmäßige Credential-Rotation.

316. North Governance: User Delegation

Aktionen im Namen eines Nutzers sollten dessen tatsächliche Berechtigungen respektieren.

Ein zentraler Superuser-Connector kann sonst ACLs umgehen.

317. North Governance: Data Classification

Öffentlich, intern, vertraulich und streng vertraulich sollten unterschiedlich behandelt werden.

Retrieval, Logging und Toolfreigaben können an die Datenklasse gekoppelt werden.

318. North Governance: DLP

Data-Loss-Prevention-Regeln können sensible Muster vor externer Weitergabe blockieren.

DLP ist Ergänzung und ersetzt kein korrektes Berechtigungsmodell.

319. North Governance: Approval Matrix

Aktionen können nach Risiko verschiedene Freigaben benötigen.

Lesen, Entwurf, Schreiben, Löschen und externe Kommunikation sollten nicht dieselbe Stufe haben.

320. North Governance: Dual Control

Besonders kritische Aktionen können zwei unabhängige Freigaben benötigen.

Das reduziert Single-Point-of-Failure bei hochwirksamen Agenten.

321. North Governance: Automation Owner

Jede Automation benötigt einen fachlichen Owner.

Verwaiste Workflows können nach Prozessänderungen unbemerkt falsche Aktionen ausführen.

322. North Governance: Change Management

Änderungen an Prompt, Agent, Tool oder Trigger sollten versioniert freigegeben werden.

Agentenlogik ist produktiver Code und verdient vergleichbare Change-Kontrollen.

323. North Governance: Test Workspace

Neue Agents und Automations sollten zunächst mit Testdaten laufen.

Produktivdaten und reale Schreibrechte gehören erst nach Regressionstests dazu.

324. North Governance: Dry Run

Ein Dry-Run-Modus kann geplante Aktionen anzeigen, ohne sie auszuführen.

Dies ist besonders für neue Automations und Datenmigrationen nützlich.

325. North Governance: Shadow Mode

Ein Agent kann parallel beobachten und Empfehlungen erzeugen, ohne operative Entscheidungen zu treffen.

So lässt sich reale Qualität messen, bevor Autonomie erhöht wird.

326. North Governance: Kill Switch

Agentische Systeme benötigen eine schnelle zentrale Deaktivierung.

Der Kill Switch sollte auch laufende Trigger und Schreibtools stoppen können.

327. North Governance: Budget Limits

Token-, Tool- und Laufzeitbudgets begrenzen Kosten und Endlosschleifen.

Budgets sollten pro Agent und Workflow sichtbar sein.

328. North Governance: Step Limits

Maximale Agentenschritte verhindern unbegrenzte Planungsschleifen.

Ein sauberer Abbruchstatus ist besser als stilles Timeout.

329. North Governance: Tool Allowlist

Jeder Agent sollte nur ausdrücklich freigegebene Tools sehen.

Ein universeller Werkzeugkasten erhöht Prompt-Injection- und Fehlbedienungsrisiko.

330. North Governance: Domain Allowlist

Web- oder API-Zugriff kann auf erlaubte Domains beschränkt werden.

Dies reduziert Exfiltration und unkontrollierte Drittquellen.

331. North Governance: File Scope

Dateizugriff sollte auf benötigte Ordner oder Bibliotheken beschränkt sein.

Globale Dateisystemrechte sind für die meisten Aufgaben unnötig.

332. North Governance: Email Send

E-Mail-Versand ist eine reale Außenwirkung und sollte als schreibende Aktion behandelt werden.

Entwurf und Senden sollten getrennte Rechte besitzen.

333. North Governance: Calendar Write

Terminerstellung verändert externe Systeme.

Duplikate, Zeitzonen und Teilnehmerauflösung benötigen deterministische Checks.

334. North Governance: CRM Write

CRM-Änderungen können Geschäftsprozesse auslösen.

Feldvalidierung und Auditlog müssen unabhängig vom Modell erfolgen.

335. North Governance: Database Write

Direkte Datenbankschreibrechte sind besonders riskant.

Stored Procedures oder eingeschränkte APIs sind sicherer als generischer SQL-Zugriff.

336. North Governance: Shell Tool

Shellzugriff ermöglicht weitreichende Systemänderungen.

Containerisierung, Pfadgrenzen, Netzwerkregeln und Resource Limits sind Pflicht.

337. North Governance: Browser Tool

Browseragenten interagieren mit untrusted Webinhalten.

Webseiten dürfen Systemregeln nicht überschreiben und Downloads benötigen Malwarekontrolle.

338. North Governance: Prompt Library

Freigegebene Prompts sollten versioniert und mit Owner versehen werden.

Ad-hoc-Änderungen erschweren Audit und reproduzierbare Ergebnisse.

339. North Governance: Agent Template

Wiederverwendbare Agentenvorlagen reduzieren Wildwuchs.

Vorlagen sollten Toolrechte und Safety-Standards mitbringen.

340. North Governance: Knowledge Source Owner

Jede wichtige Wissensquelle braucht einen Verantwortlichen für Aktualität.

KI kann eine veraltete Quelle nicht zuverlässig als organisatorisch überholt erkennen.

341. North Governance: Retention Policy

Logs und Conversations benötigen definierte Aufbewahrungsfristen.

Zu lange Retention erhöht Datenschutzrisiko, zu kurze Retention erschwert Audit.

342. North Governance: Incident Review

Fehlaktionen sollten als technische Incidents mit Root-Cause-Analyse behandelt werden.

Die Ursache kann Modell, Prompt, Tool, Berechtigung oder Datenquelle sein.

343. North Governance: Red Team

Agenten sollten mit Prompt Injection, Datenexfiltration und Toolmissbrauch getestet werden.

Red-Teaming muss die reale Tool- und Connectorlandschaft abbilden.

344. North Governance: Multilingual Safety

Safetytests sollten auch in den tatsächlich genutzten Sprachen erfolgen.

Übersetzte Policies allein garantieren kein identisches Modellverhalten.

345. North Governance: Business Continuity

Abhängigkeiten von Modell, Vault, Connector und Identitätsprovider brauchen Ausfallstrategien.

Kritische Geschäftsprozesse sollten nicht ohne definierten manuellen Fallback automatisiert werden.

346. North Governance: Vendor Exit

Exportierbare Daten, Prompts und Workflowdefinitionen reduzieren Lock-in.

Souveränität umfasst auch die Fähigkeit, einen Anbieter kontrolliert zu wechseln.

347. Private Deployment: GPU Sizing

Modellgröße, Quantisierung, Kontext und Concurrency bestimmen den GPU-Bedarf.

Nur Parameterzahl oder Hersteller-Minimum ist für Produktionssizing unzureichend.

348. Private Deployment: Driver Matrix

GPU-Treiber, CUDA und Servingcontainer müssen kompatibel sein.

Unterstützte Versionen gehören in die Betriebsdokumentation.

349. Private Deployment: Kubernetes

Viele private Deployments nutzen Kubernetes für Scheduling und Lifecycle.

Kubernetes ist Orchestrierung, nicht automatisch Security; Netzwerk- und Secretregeln bleiben nötig.

350. Private Deployment: Node Pools

Unterschiedliche Modelle können getrennte GPU-Pools benötigen.

Ressourcenklassen sollten nach Modell und Latenzziel dimensioniert werden.

351. Private Deployment: Autoscaling

Autoscaling muss GPU-Startzeit und Modellladezeit berücksichtigen.

Zu aggressives Scale-to-zero kann interaktive Latenz verschlechtern.

352. Private Deployment: Health Checks

Servinginstanzen benötigen Readiness- und Liveness-Prüfungen.

Ein Prozess kann laufen, obwohl das Modell noch nicht geladen oder die GPU fehlerhaft ist.

353. Private Deployment: Rolling Upgrade

Neue Container oder Modellversionen sollten ohne vollständigen Ausfall ausgerollt werden.

Kompatibilität von API und Promptformat muss während Mischbetrieb gewährleistet sein.

354. Private Deployment: Blue/Green

Zwei getrennte Stacks ermöglichen kontrollierte Umschaltung und schnellen Rollback.

Die Methode benötigt zusätzliche Kapazität, reduziert aber Release-Risiko.

355. Private Deployment: GPU Memory Fragmentation

Langlaufende Servingprozesse können Speicherfragmentierung oder Leaks zeigen.

Monitoring sollte freien VRAM und OOM-Ereignisse erfassen.

356. Private Deployment: Disk Cache

Große Modellartefakte profitieren von lokalem Caching.

Cacheintegrität und Artefakthash müssen vor Laden geprüft werden.

357. Private Deployment: Registry

Containerimages sollten aus kontrollierten Registries mit Signaturen bezogen werden.

Ungeprüfte Images erweitern die Supply-Chain-Angriffsfläche.

358. Private Deployment: Secrets Store

API- und Connectorsecrets gehören in einen Secret Manager.

Environment-Dumps und Logs dürfen Secrets nicht versehentlich ausgeben.

359. Private Deployment: Network Policy

Pods beziehungsweise Services sollten nur notwendige Netzwerkziele erreichen.

Default-deny reduziert Exfiltrationsmöglichkeiten.

360. Private Deployment: Egress Proxy

Externe Requests können zentral protokolliert und gefiltert werden.

Ein Proxy schafft Sichtbarkeit, ersetzt aber keine Tool-Allowlist.

361. Private Deployment: TLS

Interne und externe API-Verbindungen sollten verschlüsselt und authentifiziert sein.

Zertifikatsrotation gehört zum normalen Betrieb.

362. Private Deployment: mTLS

Mutual TLS kann Service-zu-Service-Identität absichern.

Dies ist besonders in Zero-Trust-Netzen relevant.

363. Private Deployment: IAM

Identitäten sollten über Rollen statt gemeinsam genutzte Schlüssel autorisiert werden.

Maschinen- und Benutzeridentitäten müssen getrennt sein.

364. Private Deployment: Audit Storage

Auditlogs sollten manipulationsgeschützt und ausreichend lange verfügbar sein.

Modelle selbst sollten keine Möglichkeit besitzen, Auditspuren zu löschen.

365. Private Deployment: Metrics

Tokenrate, TTFT, Fehler, GPU-Auslastung und Queue-Länge bilden einen Mindestmetriksatz.

Nur CPU- oder HTTP-Monitoring reicht für GPU-Inferenz nicht.

366. Private Deployment: Tracing

Distributed Tracing verbindet Retrieval-, Rerank-, Model- und Toollatenz.

Trace-Daten können sensibel sein und sollten Promptinhalte minimieren.

367. Private Deployment: SLO

Service Level Objectives definieren akzeptable Latenz, Fehlerquote und Verfügbarkeit.

SLOs sollten je Workload statt nur global festgelegt werden.

368. Private Deployment: Capacity Reserve

Kritische Workloads benötigen Reserve für Lastspitzen oder Hardwareausfall.

Maximale Dauerauslastung lässt keinen Fehlertoleranzpuffer.

369. Private Deployment: Disaster Recovery

Modelle, Konfigurationen und Indizes benötigen Wiederherstellungspläne.

Der eigentliche Checkpoint allein stellt keinen funktionsfähigen RAG-/Agentenstack wieder her.

370. Private Deployment: Backup

Prompts, Agentendefinitionen, Indexmetadaten und Konfigurationen sollten gesichert werden.

Personenbezogene Daten in Backups unterliegen ebenfalls Retention und Zugriffsschutz.

371. Private Deployment: Restore Test

Backups sind erst vertrauenswürdig, wenn Wiederherstellung regelmäßig getestet wird.

Restore-Tests sollten auch Modellartefakte und Suchindizes einschließen.

372. Model Vault Operations: Single Tenant

Dedizierte Instanzen reduzieren Ressourcenteilung mit anderen Kunden.

Identitäts-, Netzwerk- und Anwendungssicherheit bleiben trotzdem erforderlich.

373. Model Vault Operations: Performance Tier

Vaults können je Modell und Performanceklasse unterschiedlich dimensioniert werden.

Auswahl sollte anhand gemessener QPS und Latenz erfolgen.

374. Model Vault Operations: Standard vs Encrypted

Encrypted Vaults adressieren zusätzliche Anforderungen an Daten in Nutzung und Attestation.

Nicht jeder Modell-/GPU-Pfad ist in beiden Varianten identisch verfügbar.

375. Model Vault Operations: ZDR

ZDR kann Prompt- und Response-Retention minimieren.

Anwendungslogs außerhalb des Vaults müssen separat betrachtet werden.

376. Model Vault Operations: Spend Tracking

Vault-Nutzung wird als dedizierte Infrastrukturkosten sichtbar.

Kapazitätsauslastung bestimmt Wirtschaftlichkeit stärker als reiner Tokenvergleich.

377. Model Vault Operations: North Integration

North kann auf Model Vault als dediziertem Inferenzpfad betrieben werden.

Workspace- und Datenzugriffsschichten bleiben oberhalb der Modellinferenz bestehen.

378. Sovereign Deployment: Jurisdiction

Datenstandort und Betreiberjurisdiktion sind getrennte Compliance-Fragen.

Ein Server in Europa löst nicht automatisch jede internationale Rechtsfrage.

379. Sovereign Deployment: Control Plane

Auch Management- und Updatepfade können grenzüberschreitende Abhängigkeiten erzeugen.

Souveränitätsanalyse muss Control Plane und nicht nur GPU-Datenpfad erfassen.

380. Sovereign Deployment: Model Updates

Automatische Updates können Reproduzierbarkeit und Freigaben unterlaufen.

Regulierte Umgebungen benötigen kontrollierte Versionseinspielung.

381. Sovereign Deployment: Dependency Lock

Python-, CUDA- und Systempakete sollten versioniert werden.

Ohne Dependency-Lock ist ein lokaler Checkpoint später nicht vollständig reproduzierbar.

382. Evaluation: Golden Set

Ein kuratiertes Golden Set repräsentiert zentrale reale Unternehmensaufgaben.

Es sollte feste Antworten, tolerierte Varianten und Quellenbelege enthalten.

383. Evaluation: Regression Set

Fehler aus der Vergangenheit sollten dauerhaft in Regressionstests aufgenommen werden.

So verhindert ein Modellupgrade die Wiederkehr bereits gelöster Probleme.

384. Evaluation: Slice Analysis

Ergebnisse sollten nach Sprache, Domäne, Dokumenttyp und Nutzergruppe geschnitten werden.

Ein guter Gesamtscore kann schwache Teilgruppen verdecken.

385. Evaluation: Human Rubric

Subjektive Qualität benötigt klare Bewertungsrubriken für Korrektheit, Relevanz und Vollständigkeit.

Freitextbewertungen ohne Rubrik sind schwer vergleichbar.

386. Evaluation: Pairwise Comparison

Zwei Modellversionen können blind gegeneinander bewertet werden.

Randomisierte Reihenfolge reduziert Markennamen- und Positionsbias.

387. Evaluation: Statistical Power

Kleine Testsets erzeugen instabile Unterschiede.

Stichprobengröße sollte zur erwarteten Effektgröße passen.

388. Evaluation: Confidence Interval

Scores sollten mit Unsicherheitsintervallen statt nur Einzelwerten betrachtet werden.

Ein scheinbarer Vorsprung kann statistisch nicht belastbar sein.

389. Evaluation: Cost-normalized Quality

Qualität kann pro Euro, GPU-Stunde oder erfolgreicher Aufgabe normalisiert werden.

Das ist für Enterprise-Auswahl oft relevanter als absolute Benchmarkspitze.

390. Evaluation: Latency-normalized Quality

Ein etwas schwächeres Modell kann bei deutlich geringerer Latenz produktiver sein.

Qualitäts-Latenz-Paretofronten zeigen diesen Zielkonflikt besser.

391. Evaluation: RAG Faithfulness

Antwortaussagen werden gegen bereitgestellte Quellen auf Widerspruch geprüft.

Faithfulness misst nicht, ob die Quelle selbst wahr oder aktuell ist.

392. Evaluation: Tool Success Rate

Agenten sollten nach erfolgreich abgeschlossenen Toolzielen bewertet werden.

Ein syntaktisch korrekter Tool Call ist noch kein erfolgreicher Workflow.

393. Evaluation: End-to-End Task Success

Das wichtigste Maß ist oft, ob die reale Aufgabe korrekt abgeschlossen wurde.

Zwischenmetriken helfen bei Diagnose, ersetzen aber nicht End-to-End-Erfolg.

394. Evaluation: Safety Pass Rate

Riskante Testfälle benötigen definierte erlaubte und verbotene Resultate.

Safety sollte nach Sprache und Toolkontext getrennt gemessen werden.

395. Evaluation: Prompt Robustness

Leichte Umformulierungen sollten nicht zu völlig anderem Verhalten führen.

Robustheitstests decken überangepasste Prompts und fragile Routingregeln auf.

396. Evaluation: Adversarial Inputs

Absichtlich irreführende oder manipulative Inputs zeigen Sicherheitsgrenzen.

Agenten benötigen zusätzlich Tests mit schädlichen Toolresultaten und Dokumenten.

397. Evaluation: Long-context Needle

Gezielte Fakten in langen Kontexten testen Retrieval innerhalb des Promptfensters.

Solche Tests sollten realistische Ablenktexte statt künstlicher Wiederholungen verwenden.

398. Evaluation: Multimodal Grounding

Bildbezogene Aussagen werden gegen sichtbare Bildregionen geprüft.

Bounding-Box- oder Crop-basierte Checks können Fehlgrounding sichtbar machen.

399. Evaluation: Translation Terminology

Fachbegriffe werden gegen definierte Terminologielisten bewertet.

Allgemeine BLEU-ähnliche Scores reichen für regulierte Fachtexte nicht.

400. Evaluation: ASR WER by Domain

Transcribe sollte pro Sprach- und Audioklasse gemessen werden.

Telefonie, Meetingraum und Studioaudio besitzen unterschiedliche Fehlermuster.

401. Observability: Prompt Version

Jeder Request sollte auf eine Prompt- oder Agentenversion rückführbar sein.

Sonst können Textänderungen nicht von Modelländerungen unterschieden werden.

402. Observability: Model Version

Modell-ID gehört in jeden relevanten Trace.

Aliasnamen sollten bei Speicherung auf tatsächlichen Snapshot aufgelöst werden, wenn möglich.

403. Observability: Retrieval Trace

Gefundene Dokumente, Scores und Filter sollten rekonstruierbar sein.

Datenschutz verlangt dabei Minimierung sensibler Volltexte in Logs.

404. Observability: Tool Trace

Toolname, validierte Argumente, Ergebnisstatus und Laufzeit sollten protokolliert werden.

Secrets und vollständige sensible Payloads gehören nicht unmaskiert in Logs.

405. Observability: User Feedback

Korrekturen und Downvotes können wertvolle Fehlerdaten liefern.

Feedback muss nach Datenschutz- und Trainingsregeln getrennt behandelt werden.

406. Lifecycle: Live

Live bedeutet aktuell unterstützt und für den vorgesehenen Endpoint verfügbar.

Live sagt nichts darüber aus, ob das Modell für den eigenen Use Case empfohlen ist.

407. Lifecycle: Deprecated

Deprecated bedeutet angekündigte Ablösung bei noch möglicher Übergangsverfügbarkeit.

Migration sollte vor Retirement erfolgen.

408. Lifecycle: Retired

Retired bedeutet, dass der Pfad nicht mehr normal nutzbar ist.

Archivsysteme müssen ältere Requests dann mit lokaler Kopie oder dokumentiertem Ersatz reproduzieren.

409. Lifecycle: Alias

Aliasnamen erleichtern Entwicklung, können aber auf andere Snapshots zeigen.

Produktive Reproduktion bevorzugt feste Modell-IDs.

410. Lifecycle: Cloud Lag

Hyperscaler können neuere oder ältere Snapshots als Cohere selbst führen.

Lifecycle muss pro Plattform dokumentiert werden.

411. Lifecycle: API Version

Modell und API entwickeln sich unabhängig.

Eine neue API kann alte Modelle unterstützen oder ein Modellupgrade ohne APIwechsel stattfinden.

412. Lifecycle: SDK Version

SDKs kapseln Protokolldetails, können aber Breaking Changes enthalten.

Lockfile und Changelog gehören in reproduzierbare Anwendungen.

413. Lifecycle: Data Schema

Agenten- und Retrievalschemas können sich unabhängig vom Modell ändern.

Schema-Migration benötigt Tests und gegebenenfalls Backward Compatibility.

414. Lifecycle: Connector Version

Connectorverhalten ändert sich mit Quell-API und Produktupdate.

Syncfehler sollten nicht automatisch als Modellfehler klassifiziert werden.

415. Lifecycle: Benchmark Refresh

Benchmarkversionen ändern Datensätze und Scoring.

Scores aus verschiedenen Benchmarkrevisionen sind nicht direkt vergleichbar.

416. Lifecycle: Documentation Snapshot

Offizielle Dokumentation sollte zum Produktionsrelease lokal archiviert werden.

Später aktualisierte Webseiten können historische Defaults überschreiben.

417. Aktuelles Portfolio: Command A+ als konsolidiertes Flagship

Command A+ bündelt Reasoning, Vision, Tool Use, RAG und breite Mehrsprachigkeit in einer Modellfamilie.

Für Greenfield-Enterprise-Projekte ist es der zentrale aktuelle Command-Pfad, sofern 128K Input ausreichen.

418. Aktuelles Portfolio: Command A als Long-Context-Alternative

Command A bleibt mit 256K Kontext live und kann für textbasierte Long-Context-Aufgaben relevant sein.

Ein älteres Modell kann aufgrund eines spezifischen Limits weiterhin technisch sinnvoll sein.

419. Aktuelles Portfolio: Command A Reasoning

Der 2025er Reasoningpfad bleibt als eigenständige live geführte Modellversion dokumentiert.

Bestehende Produktionsintegration sollte nicht ohne Regressionstest auf A+ umgestellt werden.

420. Aktuelles Portfolio: Command A Vision

Die Visionvariante bleibt als historisch und produktiv relevanter multimodaler Pfad verfügbar.

A+ integriert Vision breiter, aber alte Workflows können auf Vision-spezifische Eigenschaften abgestimmt sein.

421. Aktuelles Portfolio: Command A Translate

Translate bleibt ein spezialisierter 23-Sprachen-Pfad.

Spezialisierung kann in regulierten Übersetzungsworkflows wichtiger als allgemeine Modellkonsolidierung sein.

422. Aktuelles Portfolio: Command R 08-2024

Der aktualisierte R-Snapshot bleibt als live geführter Retrievalpfad dokumentiert.

Für neue Systeme sollte dennoch Lifecycle und Migrationsziel geprüft werden.

423. Aktuelles Portfolio: Command R+ 08-2024

R+ 08-2024 bleibt als stärkerer historischer RAG-Pfad verfügbar.

Bestehende RAG-Systeme können davon abhängen, obwohl A/A+ aktueller sind.

424. Aktuelles Portfolio: Command R7B

R7B bleibt die kleine 128K-Commandklasse.

Für geringe Hardware- oder Latenzbudgets kann ein kleinerer live geführter Pfad sinnvoll sein.

425. Aktuelles Portfolio: Embed v4.0

Embed 4 ist der aktuelle multimodale Retrievalencoder.

Dimension und Indexkonfiguration müssen beim produktiven Einsatz gemeinsam versioniert werden.

426. Aktuelles Portfolio: Embed v3

Ältere v3-Embeddings bleiben in vielen bestehenden Indizes im Einsatz.

Ein Wechsel zu v4 benötigt Reindexierung und Qualitätsvergleich.

427. Aktuelles Portfolio: Rerank v4 Pro

Pro ist der aktuelle Qualitätsreranker mit 32K Kontext.

Er eignet sich besonders für komplexe Kandidaten und semistrukturierte Daten.

428. Aktuelles Portfolio: Rerank v4 Fast

Fast ist der aktuelle Durchsatzreranker mit 32K Kontext.

Die Modellwahl kann pro Latenzklasse differenziert werden.

429. Aktuelles Portfolio: Rerank 3.5

Rerank 3.5 bleibt in vielen Cloud- und Enterprise-Stacks verfügbar.

Migration auf v4 sollte anhand eigener Query-Sets statt Versionsnummer entschieden werden.

430. Aktuelles Portfolio: Parse v5.0

Parse v5 ist der aktuelle Dokumentparser und besitzt einen eigenen Endpoint.

Er ist kein Alias für OCR innerhalb eines Command-Modells.

431. Aktuelles Portfolio: Cohere Transcribe

Das März-2026-ASR-Modell bleibt der allgemeine multilingual ausgerichtete Audiopfad.

Audiofiles und Sprache müssen vor Request passend validiert werden.

432. Aktuelles Portfolio: Transcribe Arabic

Die Arabic-Version ist ein eigener spezialiserter Modellpfad.

Routing sollte anhand Sprache und Audioqualität erfolgen.

433. Aktuelles Portfolio: North Mini Code

North Mini Code ist die aktuelle spezialisierte offene Coding-Modelllinie.

Der Name North bezeichnet hier eine Modellfamilie, während North zugleich als Enterprise-Produkt existiert; Kontext muss die Bedeutung klar machen.

434. Aktuelles Portfolio: Aya Expanse 32B

Aya Expanse 32B bleibt ein zentraler multilingualer Forschungscheckpoint.

Die Lizenz unterscheidet sich von Apache-2.0-Command-A+.

435. Aktuelles Portfolio: Aya Vision

Aya Vision bleibt ein eigener Open-Weight-VLM-Pfad.

Visionfähigkeit und kommerzielle Nutzungsrechte müssen getrennt betrachtet werden.

436. Aktuelles Portfolio: Tiny Aya

Tiny Aya erweitert die lokale multilingual ausgerichtete Klasse auf 3,35B.

Regionale Varianten sollten nicht anhand Namen, sondern anhand dokumentierter Sprachschwerpunkte ausgewählt werden.

437. Aktuelles Portfolio: North

North ist die aktuelle Workplace-, Agenten- und Automationsplattform.

Es kombiniert mehrere Modell- und Retrievalbausteine mit Enterprise-Governance.

438. Aktuelles Portfolio: Compass

Compass ist Coheres End-to-End Search- und Discovery-System.

Es adressiert Indexierung, Retrieval und Datenzugang als Produkt.

439. Aktuelles Portfolio: Model Vault

Model Vault ist dedizierte Cohere-verwaltete Inferenzinfrastruktur.

Es ist ein Deploymentprodukt, kein Modell.

440. Praxisworkflow: interne Wissenssuche

Dokumente werden mit Parse/Connectoren aufgenommen, mit Embed indexiert, mit Rerank priorisiert und über Command beantwortet.

ACL, Aktualität und Zitationen müssen über die gesamte Kette erhalten bleiben.

441. Praxisworkflow: Vertragsanalyse

Parse extrahiert Dokumentstruktur, Retrieval findet relevante Klauseln und Command synthetisiert die Analyse.

Juristische Schlussfolgerungen benötigen fachliche Prüfung und Originalzitate.

442. Praxisworkflow: Finanzbericht

Tabellen und Text werden erschlossen, relevante Perioden abgerufen und Zahlen gegebenenfalls mit deterministischen Tools berechnet.

Das Modell sollte keine arithmetischen Resultate aus Fließtext schätzen, wenn eine Berechnung möglich ist.

443. Praxisworkflow: Supportagent

North-Agenten können Wissenssuche und Tools für Kundenprozesse verbinden.

Schreibende Aktionen wie Gutschrift oder Kontenänderung benötigen klare Autorisierung.

444. Praxisworkflow: Research Assistant

Mehrere Quellen werden gesucht, gerankt und zu einer belegten Zusammenfassung verbunden.

Quellenvielfalt und Widersprüche sollten sichtbar bleiben.

445. Praxisworkflow: Compliance Search

Compass kann regulierte Richtlinien und interne Policies durchsuchen.

Gültigkeitsdatum, Jurisdiktion und Dokumentstatus sind essenzielle Metadaten.

446. Praxisworkflow: Meeting Transcription

Transcribe erzeugt Text, danach können Command und Retrieval Zusammenfassungen und Aufgaben ableiten.

Audiooriginal, Sprecherzuordnung und sensible Inhalte benötigen eine eigene Retentionstrategie.

447. Praxisworkflow: arabische Transkription

Transcribe Arabic kann als spezialisierter ASR-Pfad eingesetzt werden.

Dialekt- und Domänentests sollten vor breitem Rollout erfolgen.

448. Praxisworkflow: Dokument-Ingestion

Parse wandelt visuelle Dokumente in maschinenlesbare Struktur um, die danach gechunkt und eingebettet wird.

Parserfehler müssen vor Indexierung erkannt werden, sonst werden sie zu dauerhaften Retrievalfehlern.

449. Praxisworkflow: multimodale Suche

Embed 4 kann Bild- und Textsignale in einem Retrievalsystem kombinieren.

Rerank und Generator müssen mit derselben Dokumentrepräsentation sinnvoll umgehen können.

450. Praxisworkflow: Code-Migration

North Mini Code kann Repositoryanalyse, Änderung und Tests im Agentenharness koordinieren.

Branch, Buildumgebung und Regressionstests werden außerhalb des Modells kontrolliert.

451. Praxisworkflow: Code Review

Agentischer Review kann Diff, Repositorykontext und Tests kombinieren.

Security-sensitive Änderungen benötigen menschliche Freigabe.

452. Praxisworkflow: Incident Triage

North kann Logs und Wissensquellen durchsuchen und mögliche Ursachen priorisieren.

Produktionsänderungen sollten nicht allein aus einer probabilistischen Diagnose automatisch erfolgen.

453. Praxisworkflow: Workflow Automation

North Automations verbindet Trigger, Agents, Tools und Freigaben.

Idempotenz und Fehlerkompensation sind normale Softwareengineering-Aufgaben und nicht durch das Modell gelöst.

454. Praxisworkflow: Übersetzung

Command A Translate oder A+ können Inhalte sprachübergreifend übertragen.

Terminologie, Zahlen, Namen und Format werden mit deterministischen Checks abgesichert.

455. Praxisworkflow: multilingualer Helpdesk

Retrieval kann in Originalsprache suchen und die Antwort in Zielsprache formulieren.

Cross-Lingual-Retrieval und Sprachwechsel müssen als eigene Testdimension gelten.

456. Praxisworkflow: private RAG

Modelle und Retrieval laufen in VPC oder On-Prem, sodass sensible Dokumente den kontrollierten Bereich nicht verlassen.

Connectoren und Monitoring dürfen den privaten Datenpfad nicht unbemerkt wieder öffnen.

457. Praxisworkflow: dedizierte Inferenz

Model Vault übernimmt Serving und Skalierung in einer isolierten Cohere-verwalteten Umgebung.

Anwendungsdatenbanken, Connectoren und Clients bleiben dennoch separate Sicherheitszonen.

458. Praxisworkflow: Air-Gap

On-Prem-Systeme können ohne regulären Internetzugang betrieben werden.

Updates, Modellartefakte und Lizenzdateien benötigen dann einen kontrollierten Offline-Transferprozess.

459. Praxisworkflow: Retrieval A/B-Test

Zwei Embed-/Rerank-Konfigurationen werden auf demselben Queryset verglichen.

Generator und Prompt sollten für den Retrievalvergleich konstant bleiben.

460. Praxisworkflow: Modell A/B-Test

Zwei Commandmodelle erhalten identischen Retrievalkontext und Tools.

So wird Modellqualität von Suchqualität getrennt.

461. Praxisworkflow: Shadow Agent

Ein neuer Agent erzeugt Empfehlungen parallel zum bestehenden Prozess, führt aber keine Aktionen aus.

Erst nach ausreichender Erfolgsrate und Sicherheitsprüfung werden Schreibrechte freigeschaltet.

462. Praxisworkflow: Human Approval Queue

Sensible Agentenaktionen landen in einer Freigabewarteschlange.

Der Prüfer benötigt Kontext, Quelle, geplante Aktion und Auswirkungen, nicht nur ein Ja/Nein-Feld.

463. Praxisworkflow: Scheduled Automation

Zeitgesteuerte Workflows müssen Zeitzone, Retry und verpasste Läufe definieren.

Doppelte Ausführung wird durch Idempotenz verhindert.

464. Praxisworkflow: Batch Parsing

Große Dokumentmengen werden asynchron verarbeitet und anschließend indexiert.

Fehlerhafte Dateien sollten isoliert und nicht den gesamten Batch stoppen.

465. Praxisworkflow: Continuous Indexing

Neue und geänderte Dokumente werden inkrementell aufgenommen.

Delete- und ACL-Events sind genauso wichtig wie Create/Update.

466. Praxisworkflow: Migration auf Embed 4

Ein paralleler neuer Index ermöglicht Vergleich mit dem bisherigen Embeddingmodell.

Nach Qualitätsprüfung wird Traffic kontrolliert umgeschaltet.

467. Praxisworkflow: Migration auf Rerank 4

Pro oder Fast werden gegen den bisherigen Reranker auf identischen Kandidaten evaluiert.

Nur Rankingstufe ändern, damit Ursache des Qualitätsunterschieds klar bleibt.

468. Praxisworkflow: Migration auf Command A+

A+ wird gegen bestehende A-/Reasoning-/Vision-Workflows getestet.

Kontextlimit, Toolschemas und multimodale Inputs müssen neu validiert werden.

469. Praxisworkflow: Cloud-to-Private Migration

Modell- und Retrievallogik wird von SaaS in VPC oder On-Prem übertragen.

Netzwerk-, IAM-, Observability- und Updateverantwortung wandert dabei zum Betreiber.

470. Praxisworkflow: Private-to-Model-Vault

Eigene Servinginfrastruktur kann durch dedizierte Managed Inference ersetzt werden.

Kontrollgewinn und Betriebsaufwand müssen gegen Cohere-Management und Vertragsanforderungen abgewogen werden.

471. Praxisworkflow: Disaster-Recovery-Test

Ein kompletter Stack wird aus Backups und Artefakten neu aufgebaut.

Erfolgreich ist der Test erst, wenn Retrieval und Agenten dieselben Kernaufgaben wieder lösen können.

472. Praxisworkflow: Audit-Rekonstruktion

Ein vergangener Agentenlauf wird aus Modell-ID, Promptversion, Quellen und Tool Calls rekonstruiert.

Fehlende Trace-Daten machen Ursache und Verantwortlichkeit unklar.

473. Praxisworkflow: Prompt-Injection-Test

Manipulierte Dokumente versuchen, den Agenten zu Datenabfluss oder Toolmissbrauch zu bewegen.

Erwartet wird, dass Dokumentinhalt als untrusted data behandelt und sensible Aktion blockiert wird.

474. Praxisworkflow: Multilingual Safety Test

Identische riskante Aufgaben werden in mehreren Sprachen und Code-Mixing getestet.

Unterschiedliche Ablehnungs- oder Toolverhaltensmuster müssen sichtbar werden.

475. Praxisworkflow: Cost Benchmark

Kosten aus Parse, Embed, Rerank, Command und Human Review werden pro Aufgabe erfasst.

So entsteht ein realistischer TCO-Vergleich statt eines isolierten Tokenpreises.

476. Praxisworkflow: Latency Budget

Ein Gesamtziel wird auf Search, Rerank, Model und Tools aufgeteilt.

Optimierung konzentriert sich auf die tatsächlich dominante Stufe.

477. Praxisworkflow: High Availability

Mehrere Servinginstanzen und gesunde Failoverpfade sichern kritische Workloads ab.

Fallbackmodell und degradierter Modus benötigen vorher definierte Qualitätsgrenzen.

478. Praxisworkflow: Vendor-Neutral Retrieval

Embed/Rerank oder Generator können über standardisierte Schnittstellen austauschbar gehalten werden.

Abstraktion darf besondere Cohere-Funktionen nicht unsichtbar falsch emulieren.

479. Praxisworkflow: Export und Archiv

Checkpoints, Lizenzen, Konfigurationen, Promptsets und Testresultate werden gemeinsam archiviert.

Nur so bleibt der Stand vom 1. September 2026 später nachvollziehbar.

480. Problemhilfe: Command A+ antwortet in falscher Sprache

System- und Nutzerprompt auf widersprüchliche Sprachvorgaben prüfen.

Explizite Zielsprache setzen und multilingualen Regressionstest hinzufügen.

481. Problemhilfe: Cross-Lingual Retrieval findet Übersetzung statt Original

Embeddingraum priorisiert semantische Äquivalenz ohne Source-Priorität.

Sprach- und Autoritätsmetadaten im Ranking berücksichtigen.

482. Problemhilfe: Rerank bevorzugt lange Dokumente

Dokumentformat oder Chunking erzeugt systematischen Bias.

Längenverteilung im Testset prüfen und geeignete Chunkgrößen vergleichen.

483. Problemhilfe: Rerank bevorzugt JSON mit vielen Feldern

Irrelevante Feldnamen beeinflussen den Relevanzscore.

Nur suchrelevante Felder serialisieren und Feldstruktur standardisieren.

484. Problemhilfe: Parse verarbeitet Scan ohne Textschicht schlecht

Bildqualität, Rotation oder Kompression kann die visuelle Extraktion erschweren.

Vorverarbeitung und Seitenqualität messen, statt nur Parsermodell zu wechseln.

485. Problemhilfe: Parse kostet zu viel bei Millionen Seiten

API-Aufrufsmuster und Auslastung passen nicht zur Skalierung.

Batching oder Model Vault für dauerhafte hohe Nutzung wirtschaftlich vergleichen.

486. Problemhilfe: Transcribe-Datei ist zu groß

Endpoint besitzt Dateigrößen- und Formatgrenzen.

Audio segmentieren, Zeitbezug erhalten und Segmente nach Transkription sauber zusammensetzen.

487. Problemhilfe: Transkript-Zeitbezug geht verloren

ASR-Ausgabe enthält nicht automatisch alle benötigten Segmentmetadaten.

Zeitstempel separat erfassen oder unterstützte Ausgabefelder verwenden.

488. Problemhilfe: North Automation erzeugt Kostenlawine

Loop oder Fan-out erzeugt zu viele Modell- und Toolaufrufe.

Run-, Token- und Step-Budgets setzen und Alarmierung aktivieren.

489. Problemhilfe: Agent erstellt viele Unteraufgaben ohne Nutzen

Planungsheuristik ist zu offen.

Maximale Subtask-Zahl und klare Erfolgskriterien definieren.

490. Problemhilfe: Agent ignoriert frische Richtlinie

Retrieval liefert ältere, höher gerankte Version.

Canonical- und Gültigkeitsmetadaten stärker gewichten.

491. Problemhilfe: Agent zitiert internes Draft statt freigegebener Policy

Source-of-Truth-Klassifikation fehlt.

Dokumentstatus in Metadaten abbilden und Drafts aus produktiven Antworten ausschließen.

492. Problemhilfe: Benutzer sieht Citation aber kein Dokument

Citation kann auf eine Quelle zeigen, deren UI-Zugriff separat blockiert ist.

Citationdarstellung mit ACL und Source-Preview synchronisieren.

493. Problemhilfe: Model Vault ist unterausgelastet

Dedizierte Kapazität passt nicht zum Trafficprofil.

Performance Tier, Instanzanzahl oder Shared/SaaS-Alternative wirtschaftlich prüfen.

494. Problemhilfe: On-Prem ist teurer als erwartet

GPU-Kapital, Personal, Strom, Redundanz und Lifecycle werden unterschätzt.

TCO gegen Model Vault und Cloudpfade über realistische Auslastung rechnen.

495. Problemhilfe: Private VPC hat hohe Egress-Kosten

Retrievaldaten oder Tools verlassen unnötig Region/Cloud.

Datenpfade kartieren und Services co-lokalisieren.

496. Problemhilfe: Cloudregion unterstützt Modell nicht

Modellrollout ist plattform- oder regionsabhängig.

Verfügbarkeitsmatrix prüfen und Architektur nicht auf Aliasannahmen aufbauen.

497. Problemhilfe: A+ Quantisierung lädt, aber Qualität fällt in einer Sprache

Quantisierungseffekt kann sprach- oder aufgabenspezifisch sein.

Slice-Evaluation pro Sprache gegen BF16-Referenz durchführen.

498. Problemhilfe: MoE Experten verteilen sich schlecht

Servingframework oder Topologie passt nicht zur Expertverteilung.

Expert-Parallelism und Kommunikationsprofil messen.

499. Problemhilfe: TTFT steigt bei langen PDFs

Der Prefill wird durch großen Kontext dominiert.

Retrieval enger machen, Chunks reduzieren oder Vorverarbeitung nutzen.

500. Problemhilfe: Output mit 64K führt zu Timeout

Maximales Ausgabelimit ist kein empfohlenes Standardbudget.

Aufgabe segmentieren und Ausgabegrenzen realistisch setzen.

501. Problemhilfe: Chatverlauf verdrängt Systemkontext

Truncationstrategie entfernt falsche Nachrichten.

Systemregeln pinnen und alte Gesprächsteile kontrolliert zusammenfassen.

502. Problemhilfe: Agent benutzt altes Toolschema

Prompt oder Cache enthält veraltete Definition.

Toolversion in Agentenversion aufnehmen und Cache invalidieren.

503. Problemhilfe: Toolresultat enthält riesigen Text

Unbegrenzte Tooloutputs blähen Kontext und Kosten auf.

Toolseitig filtern, paginieren oder zusammenfassen und Originalreferenz erhalten.

504. Problemhilfe: Retrievalcache leakt zwischen Benutzern

Cache-Key enthält keine ACL- oder Benutzerkomponente.

Cache nach Tenant, Rolle und Datenversion isolieren.

505. Problemhilfe: Embeddingindex mischt Mandanten

Tenantfilter fehlt in Index oder Query.

Physische oder logisch erzwungene Mandantenisolation implementieren.

506. Problemhilfe: North-Connector synchronisiert nur teilweise

API-Rate-Limits, Pagination oder Berechtigungen blockieren Teile.

Syncmetriken, Cursor und Fehlerqueue überwachen.

507. Problemhilfe: gelöschte Berechtigung bleibt im Index

ACL-Delta wurde nicht verarbeitet.

Reconciliation-Lauf und vollständige Berechtigungsneuberechnung einplanen.

508. Problemhilfe: Auditlog enthält sensible Prompts

Observability speichert zu viel Rohinhalt.

Redaction, Hashes und strukturierte Metadaten statt vollständiger Prompts verwenden.

509. Problemhilfe: Redaction zerstört Diagnosefähigkeit

Zu aggressive Maskierung entfernt relevante Fehlerdetails.

Datenschutzfreundliche Feldauswahl und kontrollierten Break-glass-Zugriff etablieren.

510. Problemhilfe: Agentenvergleich ist nicht reproduzierbar

Tools, Daten und Startzustand unterscheiden sich zwischen Runs.

Harness-Snapshot und Sandboxzustand mitversionieren.

511. Problemhilfe: Benchmarkscore steigt, Nutzerzufriedenheit sinkt

Benchmark deckt reale Aufgaben nicht ab.

Produktmetriken und echte Nutzeraufgaben in Evaluation aufnehmen.

512. Problemhilfe: Aya-Lizenz wird mit Command A+ verwechselt

Beide sind Open-Weight-Pfade mit unterschiedlichen Lizenzbedingungen.

Lizenzdatei pro Checkpoint prüfen und archivieren.

513. Problemhilfe: Tiny Aya Global ist in Region schwächer

Global ist ausgewogen, nicht für jede Region optimal.

Earth/Fire/Water gegen das konkrete Sprachset testen.

514. Problemhilfe: Translate behält HTML nicht korrekt

LLM-Übersetzung kann Markup verändern.

Tags schützen, strukturiert segmentieren und HTML nach Übersetzung validieren.

515. Problemhilfe: Übersetzung erfindet höflichere Formulierung

Generative Übersetzung kann Stil paraphrasieren.

Literalitätsgrad, Terminologie und Referenztests explizit steuern.

516. Problemhilfe: Retrieval antwortet auf falschen Zeitraum

Zeitfilter fehlt oder Query ist zeitlich ambig.

Gültigkeits- und Veröffentlichungsdaten als strukturierte Filter nutzen.

517. Problemhilfe: Search findet Kopie statt Primärquelle

Duplikate besitzen ähnlichen semantischen Score.

Canonical Source und Authority Weighting einführen.

518. Problemhilfe: Agent scheitert nach Modellupgrade

Prompt oder Toolverhalten war auf alte Generation angepasst.

Canary, Regression Set und Rollbackpfad verwenden.

519. Problemhilfe: Cloudmigration ändert Antwortqualität

Provider nutzt anderen Snapshot, Quantisierung oder Servingstack.

Modellartefakt und Plattformversion explizit vergleichen.

520. Aya-Forschung: Instruction Tuning

Aya nutzte multilingual ausgerichtete Instruction-Daten, um Aufgabenbefolgung über viele Sprachen zu verbessern.

Instruction Tuning ist eine Post-Training-Schicht und darf nicht mit dem Vortraining des Basismodells verwechselt werden.

521. Aya-Forschung: Preference Training

Spätere Aya-Arbeiten verwenden Präferenzsignale zur Qualitätssteigerung.

Präferenzdaten können kulturelle und sprachliche Biases enthalten und benötigen breite Evaluation.

522. Aya-Forschung: Model Merging

Aya Expanse nutzt unter anderem Model-Merging-Ansätze als Teil der Entwicklungsstrategie.

Merge-Verfahren erzeugen neue Checkpoints, deren Verhalten nicht einfach aus den Ausgangsmodellen abgeleitet werden kann.

523. Aya-Forschung: Low-resource Languages

Ein Kernziel ist bessere Abdeckung von Sprachen mit weniger Trainingsdaten.

Geringere Datenmenge erhöht die Bedeutung von Communitydaten, Evaluation und kulturellem Kontext.

524. Aya-Forschung: Cultural Context

Sprachkompetenz allein bildet kulturelle Angemessenheit nicht vollständig ab.

Evaluation sollte lokale Begriffe, Konventionen und soziale Kontexte berücksichtigen.

525. Aya-Forschung: Community Contribution

Aya wurde mit einer großen internationalen Forschungsgemeinschaft aufgebaut.

Offene Zusammenarbeit verbreitert Perspektiven, verlangt aber klare Dataset-Provenienz und Lizenzierung.

526. Aya-Forschung: Dataset Provenance

Herkunft und Lizenz von Trainings- und Instruction-Daten sind für Reproduzierbarkeit wichtig.

Ein Modellcheckpoint allein dokumentiert nicht die Entstehung des multilingualen Verhaltens.

527. Aya-Forschung: Generative Evaluation

Multilinguale Generationsqualität benötigt Aufgaben jenseits klassischer Übersetzungsbenchmarks.

Offene Antworten sollten auf Korrektheit, Sprache, Stil und kulturelle Passung bewertet werden.

528. Aya-Forschung: Safety Cross-Lingual

Safety-Policies können zwischen Sprachen unterschiedlich wirken.

Tests müssen direkte Übersetzungen und natürlich formulierte lokale Prompts einschließen.

529. Aya-Forschung: Code-Mixed Safety

Code-Mixing kann Klassifikations- und Safetygrenzen verschieben.

Gemischte Sprache gehört in reale multilingual ausgerichtete Red-Team-Sets.

530. Aya-Forschung: Regional Variants

Tiny Aya Earth, Fire und Water setzen unterschiedliche regionale Schwerpunkte.

Regionale Spezialisierung sollte anhand tatsächlicher Sprachen statt geographischer Namensassoziation gewählt werden.

531. Aya-Forschung: Mobile Deployment

3,35B-Klasse eröffnet mobile und Edge-nahe Experimente.

Energie, Speicher, Quantisierung und Tokenizerperformance bestimmen reale Gerätefähigkeit.

532. Aya-Forschung: Offline Translation

Lokale Modelle können Übersetzung ohne Cloudpfad ermöglichen.

Qualität und Terminologie bleiben auch offline prüfpflichtig.

533. Aya-Forschung: Privacy Benefit

On-device-Inferenz kann Datenübertragung reduzieren.

Lokale Telemetrie, Appberechtigungen und Updatepfade müssen trotzdem betrachtet werden.

534. Aya-Forschung: Quantization

Kleine multilingual ausgerichtete Modelle eignen sich für Quantisierungsexperimente.

Qualitätsverlust sollte pro Sprache statt nur auf englischen Benchmarks gemessen werden.

535. Aya-Forschung: Tokenizer Effects

Tokenizer zerlegt verschiedene Schriften und Sprachen unterschiedlich effizient.

Tokenkosten und Kontextnutzung können deshalb sprachabhängig stark variieren.

536. Aya-Forschung: Script Coverage

Lateinische, arabische, kyrillische und asiatische Schriftsysteme stellen unterschiedliche Tokenisierungs- und Datenanforderungen.

Visuelle Ähnlichkeit oder Unicode-Normalisierung kann zusätzliche Fehler erzeugen.

537. Aya-Forschung: Translation Direction

Qualität kann zwischen A→B und B→A asymmetrisch sein.

Sprachpaare sollten in beide Richtungen separat bewertet werden.

538. Aya-Forschung: Named Entities

Eigennamen werden in multilingualen Modellen häufig transliteriert, übersetzt oder verändert.

Entity-Erhaltung sollte in Geschäftstexten explizit geprüft werden.

539. Aya-Forschung: Numbers and Units

Zahlen und Einheiten sollten sprachübergreifend semantisch erhalten bleiben.

Lokalisierung darf keine Werte oder Maßeinheiten verfälschen.

540. Enterprise Security: Zero Trust

North wird mit Zero-Trust-Prinzipien und granularer Zugriffskontrolle positioniert.

Vertrauen wird pro Identität, Ressource und Aktion geprüft statt aus Netzwerkposition abgeleitet.

541. Enterprise Security: RBAC

Role-Based Access Control ordnet Rechte organisatorischen Rollen zu.

Rollen sollten regelmäßig auf Überprivilegierung überprüft werden.

542. Enterprise Security: Document ACL

Dokumentberechtigungen müssen bis in Search und RAG erhalten bleiben.

Ein Agent darf keine Quelle sehen, die der Benutzer im Ursprungssystem nicht öffnen könnte.

543. Enterprise Security: Encryption at Rest

Gespeicherte Daten und Artefakte sollten verschlüsselt sein.

Schlüsselmanagement und Zugriff auf Schlüssel sind eigene Sicherheitskomponenten.

544. Enterprise Security: Encryption in Transit

Netzwerkübertragung sollte TLS-geschützt sein.

Interne Servicekommunikation darf nicht pauschal als vertrauenswürdig gelten.

545. Enterprise Security: Data in Use

Encrypted Vaults adressieren zusätzliche Schutzanforderungen während laufender Verarbeitung.

Hardwaregestützte Isolation ist eine andere Schicht als Verschlüsselung auf Platte.

546. Enterprise Security: Attestation

Remote Attestation kann nachweisen, dass eine erwartete vertrauliche Umgebung läuft.

Attestation schützt nicht gegen fehlerhafte Anwendungsprompts oder überbreite Toolrechte.

547. Enterprise Security: Key Rotation

Schlüssel und Credentials sollten regelmäßig und nach Incidents rotiert werden.

Rotation muss ohne unkontrollierten Serviceausfall möglich sein.

548. Enterprise Security: SSO

Single Sign-On zentralisiert Benutzeridentität und Deprovisioning.

SSO allein definiert noch keine Daten- oder Toolrechte innerhalb von North.

549. Enterprise Security: SCIM

Automatisierte Benutzer- und Gruppenprovisionierung kann Rollen aktuell halten.

Fehlerhafte Gruppenzuordnung kann unmittelbar Retrieval- und Agentenrechte verändern.

550. Enterprise Security: Session Control

Sessions sollten Ablaufzeiten und erneute Authentifizierung für sensible Aktionen besitzen.

Lange Agentenläufe dürfen nicht stillschweigend unbegrenzt alte Berechtigungen nutzen.

551. Enterprise Security: Break Glass

Notfallzugang sollte streng protokolliert und zeitlich begrenzt sein.

Break-glass-Rechte gehören nicht in normale Agententoolsets.

552. Enterprise Security: Segregation of Duties

Builder, Reviewer und Operator können getrennte Rollen erhalten.

Dies reduziert das Risiko, dass eine Person Agentenlogik und produktive Freigabe allein kontrolliert.

553. Enterprise Security: Change Approval

Prompt- und Workflowänderungen können formale Freigaben benötigen.

Kleine Textänderungen können große Agentenwirkung haben und sind daher nicht nur redaktionell.

554. Enterprise Security: Vulnerability Management

Container, SDKs und Abhängigkeiten benötigen Patch- und CVE-Prozesse.

Modelle sind nur ein Teil der Angriffsfläche.

555. Enterprise Security: Penetration Testing

Externe und interne Tests sollten API, Auth, Connectors und Agententools abdecken.

Prompt Injection ergänzt klassische Web- und Infrastrukturtests, ersetzt sie aber nicht.

556. Enterprise Security: Model Abuse

Modelle können für unerwünschte Inhalte oder Automatisierung missbraucht werden.

Usage Policies, Monitoring und Berechtigungen bilden mehrere Schutzschichten.

557. Enterprise Security: Insider Risk

Autorisierte Benutzer können Daten absichtlich oder versehentlich falsch verwenden.

Least Privilege und Auditability reduzieren Folgen, verhindern aber nicht jede Insiderhandlung.

558. Enterprise Security: Data Minimization

Nur für die Aufgabe notwendige Daten sollten in Prompt und Retrievalkontext gelangen.

Weniger Daten reduzieren sowohl Datenschutz- als auch Prompt-Injection-Fläche.

559. Enterprise Security: Purpose Limitation

Datenzugriff sollte dem definierten Geschäftszweck entsprechen.

Ein technisch möglicher Connectorzugriff ist nicht automatisch organisatorisch oder rechtlich zulässig.

560. Enterprise Security: Retention by Data Class

Aufbewahrungsfristen können nach Datenklasse differenziert werden.

Auditdaten und Gesprächsinhalte benötigen nicht zwingend dieselbe Retention.

561. Enterprise Security: Legal Hold

Rechtliche Aufbewahrungspflichten können normale Löschfristen übersteuern.

Solche Ausnahmen sollten formal dokumentiert und begrenzt sein.

562. Enterprise Security: Incident Containment

Bei Agentenfehlverhalten müssen Toolzugriff, Tokens und Trigger schnell gesperrt werden können.

Containment hat Vorrang vor sofortiger Ursachenanalyse.

563. Enterprise Security: Root Cause

Nach einem Incident wird zwischen Modell-, Daten-, Prompt-, Tool- und Berechtigungsfehler unterschieden.

Eine pauschale Erklärung als Halluzination verhindert nachhaltige Korrektur.

564. Enterprise Security: Lessons Learned

Erkannte Fehler sollten in Tests, Policies und Monitoring zurückfließen.

Ein Incident ist erst abgeschlossen, wenn Wiederholung technisch erschwert wurde.

565. Enterprise Security: Regulatory Evidence

Regulierte Organisationen benötigen Nachweise über Datenfluss, Rollen und Kontrollen.

Technische Logs sollten mit organisatorischer Dokumentation verknüpft werden.

566. Enterprise Security: Model Inventory

Jede produktive Modellversion sollte in einem Inventar geführt werden.

Owner, Zweck, Deployment, Lizenz und Lifecycle gehören zu jedem Eintrag.

567. Enterprise Security: Agent Inventory

Auch Agents und Automations brauchen ein Inventar.

Ein Agent ist ein eigenständiges produktives System mit Tools und Datenrechten.

568. Enterprise Security: Connector Inventory

Datenquellen und externe Systeme sollten zentral sichtbar sein.

Ungenutzte Connectoren erhöhen unnötig die Angriffsfläche.

569. Enterprise Security: Data Flow Diagram

Ein Datenflussdiagramm zeigt, welche Informationen zwischen Client, Search, Model und Tools wandern.

Es ist besonders hilfreich, SaaS, Vault, VPC und On-Prem nicht zu vermischen.

570. Enterprise Security: Threat Model

Bedrohungen werden nach Assets, Angreifern, Eintrittspunkten und Auswirkungen strukturiert.

Prompt Injection wird damit neben klassische Credential-, Netzwerk- und Supply-Chain-Risiken eingeordnet.

571. Enterprise Security: Safety vs Security

Safety adressiert unerwünschtes Modellverhalten, Security unautorisierten Zugriff und Systemmissbrauch.

Beide Bereiche überschneiden sich, sind aber nicht identisch.

572. Enterprise Security: Privacy vs Security

Datenschutz definiert zulässige Verarbeitung, Security schützt Systeme und Daten.

Ein sicheres System kann datenschutzrechtlich unzulässig konfiguriert sein und umgekehrt.

573. Enterprise Security: Sovereignty vs Privacy

Souveränität betrifft Kontrolle über Technologie und Datenpfade, Datenschutz individuelle und rechtliche Verarbeitung.

EU- oder On-Prem-Betrieb beantwortet nicht automatisch jede Privacy-Frage.

574. Enterprise Security: Availability

Security umfasst auch Verfügbarkeit gegen Ausfälle und Überlastung.

Rate Limits, Capacity Reserve und Disaster Recovery sind daher Teil des Sicherheitsdesigns.

575. Enterprise Security: Integrity

Dokumente, Modelle und Konfigurationen müssen gegen unbemerkte Manipulation geschützt werden.

Hashes, Signaturen und Versionskontrolle schaffen Nachvollziehbarkeit.

576. Enterprise Security: Confidentiality

Zugriff auf Prompts, Dokumente und Outputs wird auf berechtigte Identitäten begrenzt.

Logs und Backups müssen dieselben Vertraulichkeitsregeln respektieren.

577. Enterprise Security: Non-repudiation

Auditspuren können nachvollziehbar machen, wer welche Freigabe oder Aktion ausgelöst hat.

Dies verlangt vertrauenswürdige Identitäten und manipulationsgeschützte Logs.

578. Enterprise Security: Periodic Review

Rollen, Connectoren, Agents und Retention sollten regelmäßig überprüft werden.

Ein einmal korrekt eingerichteter Stack driftet mit Organisation und Produktänderungen.

579. Wann Command A+?

Wenn ein aktuelles, offen verfügbares Enterprise-Generalistenmodell mit Reasoning, Vision, Tool Use, Mehrsprachigkeit und privatem Deployment benötigt wird.

Bei sehr langen Eingabekontexten kann das 256K-Fenster von Command A trotzdem relevant bleiben; A+ ist nicht in jedem Parameter automatisch größer.

580. Wann Command A?

Wenn ein stabiler textbasierter Enterprise-Generalist mit 256K Kontext und bewährtem RAG-/Tool-Use-Pfad benötigt wird.

Für neue multimodale oder konsolidierte Agentenprojekte sollte A+ mitgetestet werden.

581. Wann Command A Reasoning?

Wenn bestehende Integrationen den spezialisierten 2025er Reasoningpfad benötigen oder reproduzieren müssen.

Für Greenfield-Projekte ist zu prüfen, ob A+ die Fähigkeiten inzwischen effizienter zusammenführt.

582. Wann Command A Vision?

Für bestehende 2025er Bildanalysepfade oder gezielte Reproduktion dieser Modellversion.

A+ ist der modernere konsolidierte multimodale Pfad, während Parse für reine Dokumentextraktion oft spezialisierter ist.

583. Wann Command A Translate?

Für kontrollierte maschinelle Übersetzung in unterstützten Sprachen mit Enterprise-Deployment.

Terminologie und Format müssen mit domänenspezifischen Testsets geprüft werden.

584. Wann North Mini Code?

Für agentisches Coding mit kleiner aktiver MoE-Klasse und hoher Deploymentkontrolle.

Repository-Harness, Tests und Sandbox sind entscheidend; Modellwahl allein macht keinen sicheren Codingagenten.

585. Wann Embed 4?

Für semantische Suche über Text, Bilder und gemischte Dokumente.

Bei präzisen Ranglisten sollte Embed häufig mit Rerank kombiniert werden.

586. Wann Rerank 4 Pro?

Wenn Rankingqualität wichtiger ist als minimale Latenz.

Die eigene Retrievaldistribution muss den Mehrwert gegenüber Fast messen.

587. Wann Rerank 4 Fast?

Wenn hohe QPS und geringe Latenz wichtiger sind.

Fast sollte nicht allein aufgrund des Namens gewählt werden; Qualitätsverlust ist korpusabhängig.

588. Wann Parse?

Wenn komplexe Geschäftsdokumente strukturiert für Search/RAG/Agents erschlossen werden sollen.

Für freies visuelles Q&A kann ein allgemeiner VLM-Pfad geeigneter sein.

589. Wann Transcribe?

Für Speech-to-Text und Audiodaten, nicht für allgemeine Textgenerierung.

Sprache, Fachvokabular und Aufnahmebedingungen müssen mit echten Audiodaten evaluiert werden.

590. Wann Aya?

Für multilingual ausgerichtete offene Forschung, lokale Experimente und Sprachabdeckung außerhalb rein kommerzieller Command-Pfade.

Lizenzbedingungen und Supportmodell unterscheiden sich von Enterprise Command.

591. Wann North?

Wenn nicht nur ein Modell, sondern ein fertiger Enterprise-Workspace mit Suche, Agents, Connectors und Automations benötigt wird.

North erfordert Governance- und Berechtigungsdesign, nicht nur Prompt Engineering.

592. Wann Compass?

Wenn End-to-End Enterprise Search und Discovery im Vordergrund stehen.

Für freie generative Wissensarbeit ist North breiter; für reine Retrieval-API-Bausteine sind Embed/Rerank granularer.

593. Wann Model Vault?

Wenn dedizierte, Cohere-verwaltete Inferenz ohne eigene Serving-Infrastruktur benötigt wird.

Bei maximaler Infrastrukturkontrolle bleibt kundengemanagtes VPC oder On-Prem eine andere Option.

594. Problemhilfe: Modellname wird abgelehnt

Modell-ID gegen die aktuelle Models-Übersicht prüfen; alte Aliasnamen können deprecated oder retired sein.

Feste datierte ID verwenden und Plattform unterscheiden: Cohere API, Azure, Bedrock, OCI oder privates Deployment können unterschiedliche IDs besitzen.

595. Problemhilfe: Command R alias funktioniert nicht mehr

Die ursprünglichen Command-R-Aliase wurden in der 2025er Deprecation-Welle abgelöst.

Auf einen live geführten Snapshot oder Command A/A+ migrieren und Antwortqualität erneut testen.

596. Problemhilfe: Kontextfenster überschritten

Gesamtzahl aus Systemtext, Chatverlauf, Dokumenten und Toolresultaten berechnen.

Retrieval reduzieren, Verlauf zusammenfassen oder ein Modell mit passendem Kontextfenster wählen.

597. Problemhilfe: Antwort wird bei 8K abgeschnitten

Input-Kontext und maximales Outputlimit sind getrennte Limits.

max_tokens beziehungsweise äquivalentes Ausgabelimit prüfen und gegebenenfalls ein Modell mit größerem Outputbudget wie A+ wählen.

598. Problemhilfe: RAG findet das richtige Dokument nicht

Fehler in Ingestion, Chunking, Embedding, Filterung oder Query Rewrite lokalisieren.

Recall der ersten Retrievalstufe messen, bevor Rerank oder Generator verändert werden.

599. Problemhilfe: Rerank verbessert nichts

Prüfen, ob der richtige Kandidat überhaupt in Top-N der ersten Suche enthalten ist.

Wenn Recall fehlt, kann Rerank das nicht reparieren; Retrievalbreite oder Querystrategie ändern.

600. Problemhilfe: Rerank ist zu langsam

Kandidatengröße, Dokumentlängen und Modellvariante prüfen.

Rerank 4 Fast, kleinere Top-N-Menge oder zweistufiges Ranking testen.

601. Problemhilfe: Embed-Suche liefert ähnliche aber falsche Treffer

Vektorsuche kann semantisch ähnliche, fachlich aber unpassende Dokumente bevorzugen.

Metadatenfilter, Hybrid Search und Rerank ergänzen.

602. Problemhilfe: PDF-Parsing vertauscht Lesereihenfolge

Mehrspaltige oder visuell komplexe Dokumente können Reihenfolgefehler erzeugen.

Parse-Ausgabe mit Bounding Boxes und Originalseite vergleichen; kritische Felder separat validieren.

603. Problemhilfe: Tabelle wird falsch extrahiert

Merged Cells, verschachtelte Header und Seitenumbrüche sind typische Fehlerquellen.

Tabellenstruktur anhand Originaldokument und Koordinaten prüfen; keine Buchungs- oder Finanzlogik ungeprüft übernehmen.

604. Problemhilfe: OCR erkennt Zahl falsch

Visuelle Ähnlichkeit von 0/O, 1/I oder Dezimaltrennzeichen kann zu Fehlern führen.

Zahlenfelder durch Plausibilitätsregeln, Checksummen oder zweiten Extraktionspfad validieren.

605. Problemhilfe: Transcribe verwechselt Eigennamen

ASR ist bei seltenen Namen und Fachbegriffen besonders fehleranfällig.

Domänenspezifische Tests und gegebenenfalls spezialisierte Sprachvariante einsetzen.

606. Problemhilfe: Transcribe Arabic auf falscher Sprache

Die Arabic-Variante ist spezialisiert, nicht automatisch universell besser.

Sprachrouting anhand realer Audiodaten etablieren.

607. Problemhilfe: Tool Call enthält ungültige Argumente

LLM-Ausgaben niemals direkt als vertrauenswürdige Funktionsparameter übernehmen.

JSON-Schema serverseitig validieren, Wertebereiche prüfen und Fehler kontrolliert an das Modell zurückgeben.

608. Problemhilfe: Agent ruft Tool in Schleife auf

Stopbedingungen und maximalen Schrittzähler prüfen.

Toolresultate eindeutig formulieren und Wiederholungen über Zustand oder Idempotency-Key erkennen.

609. Problemhilfe: Agent führt sensible Aktion ohne Freigabe aus

Berechtigungsmodell ist zu weit oder Tool ist falsch klassifiziert.

Schreibende und irreversible Aktionen in einen expliziten Approval-Pfad verschieben.

610. Problemhilfe: Connector liefert Dokument ohne Berechtigung

ACL-Synchronisierung zwischen Quellsystem und Retrieval prüfen.

Treffer vor Kontextübergabe autorisieren und nicht nur im UI ausblenden.

611. Problemhilfe: North findet alte Dokumentversion

Indexierungsstatus, Connector-Sync und Cache prüfen.

Versions- und Aktualitätsmetadaten in Retrieval sichtbar machen.

612. Problemhilfe: Compass findet zu viele irrelevante Treffer

Suchraum und Metadatenfilter sind zu breit.

Quellen nach Domäne, Zeitraum, Dokumenttyp oder Team einschränken und Rerank evaluieren.

613. Problemhilfe: Zitation verweist auf falsche Passage

Citation-Span und verwendeten Retrievalchunk vergleichen.

Aussage nur übernehmen, wenn die konkrete Passage sie tatsächlich stützt.

614. Problemhilfe: Modell halluziniert trotz RAG

RAG liefert Kontext, erzwingt aber keine korrekte Schlussfolgerung.

Antwort auf Grounded-only einschränken, fehlende Evidenz explizit erlauben und Zitate prüfen.

615. Problemhilfe: Command A+ braucht zu viel VRAM

Gesamtgewichte und KV-Cache trotz 25B aktiver Parameter berücksichtigen.

Unterstützte W4A4-Quantisierung, Tensor/Expert Parallelism oder Model Vault prüfen.

616. Problemhilfe: MoE-Modell ist langsamer als erwartet

Router, Expert Parallelism, Kommunikationskosten und Batchgröße können Effizienzvorteile aufzehren.

Runtime und Hardwaretopologie profilieren statt nur aktive Parameter zu betrachten.

617. Problemhilfe: North Mini Code schreibt auf falschen Branch

Repositorykontext wurde nicht ausreichend begrenzt.

Arbeitsbranch explizit setzen, Schreibrechte einschränken und vor Commit prüfen.

618. Problemhilfe: Codingagent committed Secret

Secrets lagen im lesbaren Workspace oder wurden in Diff aufgenommen.

Secret-Scanning vor Commit erzwingen und Credential-Dateien aus Agentenreichweite entfernen.

619. Problemhilfe: Codingagent installiert falsches Paket

Paketname wurde halluziniert oder Supply-Chain-Risiko übersehen.

Allowlist, Lockfile und Registryprüfung erzwingen.

620. Problemhilfe: Patch besteht Tests aber ist fachlich falsch

Tests decken die Geschäftslogik nicht vollständig ab.

Review gegen Anforderungen, zusätzliche Regressionstests und gegebenenfalls Property-Tests durchführen.

621. Problemhilfe: North Automation wird doppelt ausgeführt

Trigger oder Retrypfad ist nicht idempotent.

Idempotency-Key, deduplizierende Zustandslogik und eindeutige Run-ID einsetzen.

622. Problemhilfe: Automation bleibt hängen

Ein Schritt wartet auf externes System oder menschliche Freigabe.

Timeout, Retrystrategie und sichtbaren Pending-State definieren.

623. Problemhilfe: Model Vault Request ist langsamer als SaaS

Dedizierte Instanzgröße, Cold/Warm-State und Region prüfen.

Latenz unter realistischer Last messen; Isolation garantiert nicht automatisch geringere Einzellatenz.

624. Problemhilfe: VPC-Modell kann externe Tools nicht erreichen

Netzwerkegress ist bewusst eingeschränkt.

Nur notwendige Endpunkte freigeben oder Tools intern spiegeln; Security nicht durch pauschales Internet-Egress aufheben.

625. Problemhilfe: On-Prem Modell startet nicht

GPU-Treiber, CUDA, Container-Runtime und Modellformat müssen kompatibel sein.

Unterstützte Matrix dokumentieren und Änderungen einzeln testen.

626. Problemhilfe: Quantisierte Ausgabe ist deutlich schlechter

Quantisierung kann empfindliche Layer oder lange Kontexte stärker beeinflussen.

Referenz gegen BF16/FP16 auf eigenem Testset messen und alternative Quantisierung wählen.

627. Problemhilfe: A+ liefert andere Ergebnisse als A Reasoning

Es handelt sich um unterschiedliche Modellgenerationen und Architekturen.

Prompt, Toolset, Reasoningmodus und Datensatz neu evaluieren statt identisches Verhalten zu erwarten.

628. Problemhilfe: A+ hat kürzeren Input als Command A

A+ bietet 128K Input, Command A 256K.

Bei Long-Context-Anwendungen Retrieval, Chunking oder Modellwahl entsprechend anpassen.

629. Problemhilfe: Aya-Antwort ist in einer Sprache schwach

Multilingualer Durchschnitt sagt wenig über einzelne Sprachen aus.

Pro Sprache, Dialekt und Domäne ein separates Evaluationsset verwenden.

630. Problemhilfe: Tiny Aya verwechselt Sprachen

Kleine Modelle besitzen geringere Kapazität und Code-Mixing kann Routing erschweren.

Regionale Tiny-Aya-Variante und klaren Sprachkontext testen.

631. Problemhilfe: Übersetzung verändert Terminologie

Allgemeine Übersetzungsqualität garantiert keine Domänenterminologie.

Terminologieliste, Referenzkorpus und automatische Terminologiechecks verwenden.

632. Problemhilfe: Übersetzung verändert Zahlenformat

Lokalisierung kann Dezimal-, Datums- oder Einheitendarstellung verändern.

Kritische numerische Tokens separat validieren oder schützen.

633. Problemhilfe: Rerank 4 Pro kostet zu viel

Pro ist auf Qualität, nicht minimale Kosten optimiert.

Fast oder kleinere Kandidatenmenge gegen Qualitätsverlust benchmarken.

634. Problemhilfe: Embed-Vektoren nach Modellwechsel inkompatibel

Unterschiedliche Embeddingmodelle erzeugen andere Vektorräume und Dimensionen.

Index vollständig neu aufbauen; alte und neue Vektoren nicht ungeprüft mischen.

635. Problemhilfe: Search Index enthält gelöschte Dokumente

Delete-/Sync-Pipeline ist unvollständig.

Quell-IDs versionieren und Tombstones beziehungsweise Reconciliation-Läufe implementieren.

636. Problemhilfe: ZDR wird missverstanden

Zero Data Retention bezieht sich auf Speicherung, nicht automatisch auf alle Verarbeitungsschritte.

Vertrag, Deploymenttyp und technische ZDR-Dokumentation gemeinsam prüfen.

637. Problemhilfe: Private Deployment sendet trotzdem Telemetrie

Modellbetrieb und umgebende Infrastruktur sind unterschiedliche Netzwerkschichten.

Container, Monitoring, Paketmanager und Tools auf ausgehende Verbindungen prüfen.

638. Problemhilfe: SaaS-Daten sollen nicht fürs Training verwendet werden

Account- und Enterprise-Einstellungen sowie Vertrag sind maßgeblich.

Nicht aus einer allgemeinen Marketingaussage auf den konkreten Account schließen.

639. Problemhilfe: MCP-Tool liefert manipulative Instruktion

Toolresultate sind Daten, keine höher priorisierten Systemregeln.

Untrusted-Content-Grenze im Agentenharness erzwingen und sensible Aktionen separat bestätigen.

640. Problemhilfe: Webinhalt überschreibt Agentenziel

Indirekte Prompt Injection wurde nicht isoliert.

Webtext als zitiertes Beobachtungsmaterial behandeln, nicht als Steueranweisung.

641. Problemhilfe: Agent sendet Daten an falschen Connector

Toolauswahl oder Berechtigungen sind zu breit.

Connectoren nach Zweck trennen und Datenklassen vor Toolaufruf prüfen.

642. Problemhilfe: Retry erzeugt doppelte externe Aktion

Der Client wiederholt einen nicht idempotenten POST.

Idempotency-Key verwenden und Ergebnisstatus vor erneutem Schreiben prüfen.

643. Problemhilfe: 429 unter Last

Gemeinsame Rate Limits oder Kapazität sind erreicht.

Backoff, Queueing, Batch oder dedizierte Kapazität/Model Vault einsetzen.

644. Problemhilfe: Timeout bei langem Reasoning

Clienttimeout ist kürzer als Modell- oder Agentenlauf.

Streaming, asynchrone Joblogik oder realistische Timeoutbudgets verwenden.

645. Problemhilfe: Streamingparser verliert Events

Eventgrenzen werden falsch zusammengesetzt.

SDK verwenden oder SSE/Chunk-Protokoll exakt implementieren und fragmentierte Frames testen.

646. Problemhilfe: JSON-Ausgabe ist syntaktisch gültig aber fachlich falsch

Schema prüft Struktur, nicht Semantik.

Domänenregeln und Datenbankconstraints nach der Modellvalidierung anwenden.

647. Problemhilfe: Citation fehlt trotz Dokumenten

Prompt oder Endpointkonfiguration fordert keine Grounding-Metadaten an.

Zitationsfunktion explizit aktivieren und Dokumentformat prüfen.

648. Problemhilfe: RAG-Antwort verwendet veraltete Quelle

Retrievalranking berücksichtigt Aktualität nicht ausreichend.

Zeitmetadaten und Source-of-Truth-Priorisierung in Search einbauen.

649. Problemhilfe: North Agent sieht zu viele Daten

Connector- oder Workspaceberechtigungen sind zu weit.

Least Privilege und getrennte Datenräume pro Rolle etablieren.

650. Problemhilfe: Auditlog reicht nicht für Rekonstruktion

Nur Endantwort wurde protokolliert.

Tool Calls, Inputs, Modell-ID, Connectorquellen und Approvalentscheidungen versioniert erfassen.

651. Problemhilfe: Parse Markdown verliert exaktes Layout

Markdown repräsentiert semantische Struktur, nicht pixelgenaues Design.

Für Layouttreue Originaldatei und Bounding Boxes archivieren.

652. Problemhilfe: Bildanalyse übersieht kleines Detail

Auflösung, Bildtokenisierung oder visueller Fokus kann Detailinformation verlieren.

Ausschnitt vergrößern, Originalauflösung prüfen und kritische Beobachtung menschlich validieren.

653. Problemhilfe: Command A Vision ruft kein Tool auf

Die Vision-Variante unterstützt Tool Use nicht wie textbasierte Agentenmodelle.

Bildanalyse und Toolaktion in getrennte kontrollierte Schritte aufteilen oder A+ prüfen.

654. Problemhilfe: North Mini Code liefert gute Antwort, ändert aber nichts

Harness gewährt keine Schreib- oder Shelltools.

Modellfähigkeit und Agentenrechte getrennt prüfen.

655. Problemhilfe: North Mini Code löscht Datei

Agent verfügt über zu breite Dateirechte.

Sandbox, Pfadallowlist, Versionskontrolle und Approval für destructive operations einsetzen.

656. Problemhilfe: Rerank Score wird als Wahrscheinlichkeit gelesen

Relevanzscores sind modellinterne Rankingwerte, keine kalibrierten Wahrscheinlichkeiten.

Scores nur relativ im getesteten Setting interpretieren.

657. Problemhilfe: Embeddingdistanz wird als Sicherheit interpretiert

Nähe im Vektorraum misst semantische Ähnlichkeit, nicht Wahrheitsgehalt.

Fakten über Quellen und Regeln validieren.

658. Problemhilfe: Aya Vision erzeugt kein Bild

Aya Vision ist Vision-Language-Verstehen, nicht Bildgenerator.

Input-/Outputmodalitäten vor Integration prüfen.

659. Problemhilfe: Transcribe wird für Live-Telefonie zu langsam

Dateibasierte ASR und Streaming-Realtime-ASR sind unterschiedliche Betriebsmodi.

Latenzanforderung gegen tatsächlich unterstützten Endpoint testen.

660. Problemhilfe: Model Vault hat falsches Modell

Vault-Konfiguration und unterstützte Modellfamilie prüfen.

Modellversion beim Deployment explizit dokumentieren und Änderungen als Change behandeln.

661. Problemhilfe: Cloudanbieter hat ältere Cohere-Version

Hyperscaler-Rollouts folgen eigener Verfügbarkeit.

Plattformmatrix prüfen; nicht vom Cohere-SaaS-Modellkatalog auf Bedrock/Azure/OCI schließen.

662. Problemhilfe: Modell auf Azure hat andere ID

Cloudanbieter verwenden eigene Deployment- oder Model IDs.

Abstraktionsschicht im Client und Plattformmetadaten dokumentieren.

663. Problemhilfe: Migration von V1 auf V2 bricht Client

Request-/Response-Schema oder Feldnamen haben sich verändert.

Vertragstests und parallele Migration statt blindem SDK-Upgrade verwenden.

664. Problemhilfe: Legacy Fine-Tune ist nicht mehr erreichbar

Cohere hat ältere Fine-Tuning-Pfade 2025 abgekündigt.

Checkpoint exportierbar archivieren, Ersatzmodell evaluieren und neue Customization-Pfade prüfen.

665. Problemhilfe: Coral-Link funktioniert historisch nicht mehr

Coral wurde als frühere Produktoberfläche abgelöst.

Historische Dokumentation archivieren und aktuelle Workflows auf North/Compass abbilden.

666. Problemhilfe: North und Compass werden verwechselt

North ist breiterer Workspace/Agentenstack, Compass fokussiert Search/Discovery.

Anforderung zuerst in Arbeitsplatzautomatisierung versus End-to-End-Suche aufteilen.

667. Problemhilfe: Command A+ wird als North bezeichnet

Modell und Produkt sind getrennte Ebenen.

In Logs sowohl Modell-ID als auch North-/API-/Vault-Kontext protokollieren.

668. Problemhilfe: Open Weight wird als Open Source verstanden

Gewichtszugang und vollständige Offenheit von Daten, Code und Training sind unterschiedliche Kriterien.

Lizenz und tatsächlich veröffentlichte Artefakte einzeln prüfen.

669. Problemhilfe: Private Deployment wird als automatisch sicher verstanden

Fehlkonfiguration, ungeschützte Secrets oder kompromittierte Clients bleiben möglich.

Security-Härtung, Patchmanagement, Monitoring und Rollenmodell betreiben.

670. Problemhilfe: Antwort wirkt sicher, ist aber falsch

Sprachmodelle besitzen keine zuverlässige interne Wahrheitsanzeige.

Kritische Aussagen gegen Datenquelle, Retrievalbeleg oder deterministisches Tool prüfen.

671. Mythos: Cohere ist nur ein Chatbot

Cohere besteht aus Modell-, Retrieval-, Dokument-, Audio-, Deployment- und Workspace-Schichten.

North ist nur eine Produktschicht innerhalb dieses Stacks.

672. Mythos: Command A+ ist einfach Command A mit Pluszeichen

A+ wechselt auf Sparse MoE, integriert Vision und Reasoning und besitzt andere Kontext- und Outputlimits.

Es ist eine eigenständige Generation.

673. Mythos: 25B aktive Parameter bedeuten nur 25B Gewichte im Speicher

MoE aktiviert pro Token nur einen Teil der Experten, die Gesamtgewichte bleiben deutlich größer.

Speicherplanung muss Gesamtmodell, Quantisierung und KV-Cache berücksichtigen.

674. Mythos: Command A+ hat immer größeren Kontext als Command A

A+ hat 128K Input, Command A 256K.

Neuere Generation bedeutet nicht in jedem technischen Feld mehr.

675. Mythos: RAG beseitigt Halluzinationen

RAG verbessert Grounding, aber Retrieval und Schlussfolgerung können weiterhin falsch sein.

Quellenprüfung bleibt nötig.

676. Mythos: Rerank ist eine Suchmaschine

Rerank sortiert Kandidaten; es braucht normalerweise eine vorgelagerte Suche.

First-stage Retrieval und Reranking sind getrennte Funktionen.

677. Mythos: Embed beantwortet Fragen

Embed erzeugt semantische Repräsentationen.

Antwortgenerierung erfolgt in einer anderen Schicht.

678. Mythos: Parse ist nur OCR

Parse extrahiert zusätzlich Struktur, Tabellen, Formulare, Bilder und Positionen.

Es bleibt dennoch ein Dokumentparser und kein allgemeiner Chatassistent.

679. Mythos: North ist ein Modell

North ist ein Enterprise Workspace und Agentenprodukt.

Darunter können unterschiedliche Modelle und Retrievalkomponenten arbeiten.

680. Mythos: Compass ist North mit anderem Namen

Compass fokussiert Search/Discovery, North ist breiter.

Die Produkte können sich ergänzen.

681. Mythos: Aya ist Command in mehr Sprachen

Aya ist eine eigene Open-Science-Forschungsfamilie.

Training, Zielsetzung und Lizenzpfade unterscheiden sich.

682. Mythos: Tiny Aya ist nur quantisiertes Aya Expanse

Tiny Aya ist eine eigene kleine Modellfamilie mit regionalen Varianten.

Es ist nicht bloß eine Kompressionsdatei eines großen Checkpoints.

683. Mythos: Vision bedeutet Bildgenerierung

Command A Vision und Aya Vision verstehen Bilder als Eingabe.

Bildgenerierung ist eine andere Modalität.

684. Mythos: Transcribe ist ein LLM für Audiochat

Transcribe ist ASR: Audio hinein, Text heraus.

Dialoglogik liegt außerhalb des ASR-Modells.

685. Mythos: Apache 2.0 bedeutet automatisch sichere Nutzung

Die Lizenz erlaubt Nutzung, sagt aber nichts über Halluzinationen, Datenschutzkonfiguration oder Agentenrechte.

Betriebssicherheit bleibt Aufgabe des Deployments.

686. Mythos: Open Weight bedeutet Daten bleiben lokal

Nur lokales oder privates Hosting bestimmt den tatsächlichen Datenpfad.

Ein offenes Modell kann trotzdem über einen Cloudendpoint genutzt werden.

687. Mythos: VPC und On-Prem sind dasselbe

VPC nutzt Cloudinfrastruktur im kontrollierten Netzwerk, On-Prem eigene lokale Hardware.

Betriebs- und Jurisdiktionsrisiken unterscheiden sich.

688. Mythos: Model Vault ist normales Multi-Tenant-SaaS

Model Vault ist als dedizierte beziehungsweise single-tenant Inferenzplattform positioniert.

Es bleibt Cohere-verwaltet und ist daher nicht dasselbe wie kundengemanagtes On-Prem.

689. Mythos: ZDR bedeutet Daten werden gar nicht verarbeitet

Inference erfordert Verarbeitung; ZDR betrifft Aufbewahrung.

Verarbeitung, Retention und Training sind getrennte Fragen.

690. Mythos: Private Deployment braucht keine Security

Eigene Infrastruktur erhöht Kontrolle und Verantwortung.

Patchen, Zugangsschutz und Monitoring werden nicht überflüssig.

691. Mythos: Tool Use macht ein Modell zum autonomen Agenten

Tool Use ist eine Fähigkeit; ein Agent benötigt zusätzlich Orchestrierung, Zustand und Regeln.

Autonomie entsteht aus dem Gesamtsystem.

692. Mythos: Reasoning macht Antworten wahr

Reasoning kann komplexe Aufgaben verbessern, garantiert aber keine Wahrheit.

Verifikation bleibt notwendig.

693. Mythos: Rerank 4 Pro ist immer die beste Wahl

Fast kann bei hohen QPS wirtschaftlicher sein und im eigenen Korpus ausreichend genau.

Auswahl ist eine Systemoptimierung.

694. Mythos: Ein 128K-Prompt sollte immer vollständig gefüllt werden

Mehr Kontext kann Relevanz verwässern und Kosten erhöhen.

Retrieval und Kontextselektion bleiben sinnvoll.

695. Mythos: Ein Modellbenchmark entscheidet das beste Enterprise-System

Enterprisequalität hängt von Daten, Retrieval, Tools, Sicherheit, Kosten und Betrieb ab.

Ein einzelner Benchmark misst nur einen Ausschnitt.

696. Mythos: Cloudanbieter liefern immer dieselbe Cohere-Version

AWS, Azure, OCI und Cohere haben eigene Rollout- und ID-Pfade.

Verfügbarkeit muss pro Plattform geprüft werden.

697. Mythos: Aleph Alpha und Cohere sind jetzt technisch eine einzige Modellfamilie

Das 2026 angekündigte Zusammengehen ist Unternehmens- und Sovereignty-Kontext.

Bestehende Modellfamilien und APIs bleiben technisch unterscheidbar.

698. Mythos: North Mini Code ist nur Code Completion

Das Modell zielt auf agentische Softwareengineering-Aufgaben.

Completion ist nur ein Teil möglicher Codingarbeit.

699. Mythos: 3B aktive Parameter bedeuten Smartphone-Modell

Aktive MoE-Parameter sind nicht gleich Gesamtgewicht und Hardwarebedarf.

30B Gesamtparameter und Runtime bleiben relevant.

700. Mythos: Multilingual heißt gleiche Qualität in jeder Sprache

Sprachabdeckung und tatsächliche Qualität sind nicht identisch.

Pro Sprache und Domäne evaluieren.

701. Archivierung: Firmengründung 2019

Gründungsjahr, damalige Unternehmensdarstellung und Gründerrollen archivieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

702. Archivierung: Platform GA 2021

API-Dokumentation, frühe Generation-/Representation-Modelle und Beispielrequests sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

703. Archivierung: Frühe Command-Modelle

Modellnamen, Kontextfenster, Fine-Tuning-Pfade und Endpunkte dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

704. Archivierung: Rerank 2023

Erste Rerank-Dokumentation, Modell-ID und API-Schema aufbewahren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

705. Archivierung: Coral 2023

Screenshots und Produktbeschreibung als Vorläufer von North sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

706. Archivierung: RAG Chat 2023

Requestformat, Citationdarstellung und damalige Groundinglogik dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

707. Archivierung: Command R 03-2024

Checkpoint/ID, Kontext, RAG- und Tool-Use-Dokumentation sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

708. Archivierung: Command R+ 04-2024

Modell-ID, Deploymentpfade und Benchmarks getrennt archivieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

709. Archivierung: Aya 2024

Modell, Dataset, Lizenz und Evaluationssuite gemeinsam sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

710. Archivierung: Aya 23

8B und 35B als getrennte Checkpoints archivieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

711. Archivierung: Aya Expanse

8B/32B, Lizenz, Sprachliste und Chattemplate dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

712. Archivierung: Rerank 3 und 3.5

Rankingmodelle und API-Verhalten für Vergleichstests erhalten.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

713. Archivierung: Command R7B

Kleinen RAG-/Agentenpfad mit Modell-ID und Hardware dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

714. Archivierung: North EAP

Frühe Produktbeschreibung vom Januar 2025 separat vom späteren GA-Stand sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

715. Archivierung: Command A 03-2025

111B, 256K, Modell-ID und Servinganforderungen dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

716. Archivierung: Embed 4

Embeddingdimensionen, multimodale Eingaben und Indexparameter festhalten.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

717. Archivierung: Aya Vision

Checkpoint, Lizenz, Bildvorverarbeitung und Sprachtests sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

718. Archivierung: North GA

Produktfeatures, Connectoren, Governance und Deploymentoptionen dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

719. Archivierung: Command A Vision

Modell-ID, 128K, Bildlimits und fehlenden Tool-Use-Pfad archivieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

720. Archivierung: Command A Reasoning

Reasoningmodell, Outputlimit und Reasoningkonfiguration sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

721. Archivierung: Command A Translate

Sprachliste, Modell-ID und Terminologietests archivieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

722. Archivierung: Deprecation September 2025

Liste der abgekündigten Modelle und Endpunkte lokal erhalten.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

723. Archivierung: Rerank 4

Pro/Fast-Varianten, Kontext, Testkorpus und Rankingmetriken sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

724. Archivierung: Model Vault

Standard/Encrypted-Konzept, Isolation und ZDR-Dokumentation archivieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

725. Archivierung: Tiny Aya

Global/Earth/Fire/Water separat mit Lizenzen und Sprachfokus sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

726. Archivierung: Cohere Transcribe

Modellgewichte, ASR-Konfiguration, unterstützte Sprachen und Testaudio dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

727. Archivierung: Aleph-Alpha-Allianz

Ankündigung und technische Souveränitätsziele als Unternehmenskontext sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

728. Archivierung: Command A+

Gewichte, Apache-2.0-Lizenz, 218B/25B, Quantisierung und Chattemplate dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

729. Archivierung: North Mini Code

Gewichte, Harness, Toolset, Quantisierung und Repositorytests archivieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

730. Archivierung: Transcribe Arabic

Spezialisierte Modellversion und arabische Testdaten separat dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

731. Archivierung: North Automations

Workflowdefinitionen, Agentenversionen, Trigger und Approvalregeln sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

732. Archivierung: Parse v5

Modell-ID, 2,3B, Dateiformate, Markdownausgabe und Bounding Boxes dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

733. Archivierung: Reproduzierbare RAG-Tests

Korpusversion, Embeddingmodell, Reranker, Top-K und Prompt gemeinsam festhalten.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

734. Archivierung: Reproduzierbare Agententests

Modell, Tools, Rechte, Harness, Netzwerk und Startzustand versionieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

735. Archivierung: Cloud-Snapshots

Plattform-ID und Region auf AWS/Azure/OCI getrennt dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

736. Archivierung: Private Deployment

Containerimages, Treiber, Runtime, Modellhashes und Netzwerkregeln sichern.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

737. Archivierung: API-Schema

OpenAPI/SDK-Version, Request-/Responsebeispiele und Fehlermeldungen erhalten.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

738. Archivierung: Lizenzen

Lizenzdatei exakt zum jeweiligen Checkpoint archivieren, nicht aus späterem Modell ableiten.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

739. Archivierung: Benchmarkprotokoll

Hardware, Batch, Quantisierung, Promptset und Metrik dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

740. Archivierung: Datenschutz-Snapshot

Privacy Policy, Enterprise Commitments und DPA-Stand zum Testzeitpunkt dokumentieren.

Nur ein gemeinsam gesicherter Snapshot aus Modellartefakt, Lizenz, Runtime, Produkt- und APIstand ermöglicht später eine belastbare Reproduktion.

741. Vergleich mit OpenAI / ChatGPT

Cohere ist stärker auf Enterprise Retrieval, private Deployments und spezialisierte Retrievalmodelle ausgerichtet; ChatGPT ist eine breitere Consumer-/Business-Produktfamilie.

Verglichen werden sollten konkrete Modelle und Deploymentpfade, nicht nur Marken.

742. Vergleich mit Anthropic Claude

Claude fokussiert stark auf allgemeine Frontier-Assistenten und Coding; Cohere koppelt generative Modelle eng mit Embed, Rerank, Compass und privaten Enterprise-Deployments.

Bei agentischen Systemen sind Tool- und Berechtigungsmodelle wichtiger als ein isolierter Benchmark.

743. Vergleich mit Google Gemini

Gemini integriert eng in Googles Produkt- und Cloudökosystem; Cohere betont Cloudneutralität, VPC, On-Prem und Model Vault.

Multimodalität und Enterprise Search sollten separat verglichen werden.

744. Vergleich mit Mistral AI

Beide Anbieter betonen offene Modelle und souveräne Deployments. Cohere besitzt jedoch eine besonders ausgeprägte Retrieval-Produktlinie aus Embed/Rerank/Compass.

Mistral und Cohere unterscheiden sich in Modellarchitekturen, Lizenzen und Produktstacks.

745. Vergleich mit Z.ai / GLM

GLM setzt stark auf Coding- und Agentenmodelle sowie breite Consumer-/Developer-Produkte; Cohere fokussiert Enterprise Search, private Bereitstellung und North.

Open-Weight-Status allein beschreibt diese Unterschiede nicht.

746. Vergleich mit Alibaba Qwen

Qwen besitzt eine extrem breite offene Modellfamilie; Cohere ist enger auf Enterprise-Workloads, Retrieval und kontrollierte Deployments zugeschnitten.

Bei lokaler Nutzung sind Lizenz, Runtime und Hardware jeweils pro Modell zu prüfen.

747. Vergleich mit DeepSeek

DeepSeek ist stark modell- und open-weight-zentriert; Cohere bietet zusätzlich fertige Enterprise Search-, Workplace- und Deploymentprodukte.

Hosted Service und lokale Gewichte bleiben in beiden Ökosystemen getrennte Pfade.

748. Vergleich mit Perplexity

Perplexity ist primär Search-/Answer-/Agentenprodukt; Cohere liefert sowohl Retrievalbausteine als auch Foundation-Modelle und Enterprise-Workspaces.

Searchprodukt und Suchmodell dürfen nicht verwechselt werden.

749. Vergleich mit Meta Llama

Llama ist eine offene Modellfamilie innerhalb eines großen Consumer-/Social-Konzerns; Cohere positioniert Modelle und Produkte gezielt für Enterprise und Sovereignty.

Open Weight ist nur eine gemeinsame technische Eigenschaft, nicht dieselbe Produktstrategie.

750. Vergleich mit Microsoft Copilot

Copilot ist eine produktübergreifende Microsoft-Assistentenfamilie; North ist eine eigenständige Enterprise-AI-Plattform mit cloudneutraler und privater Deploymentstrategie.

Foundation-Modell und Benutzerprodukt müssen bei beiden Seiten getrennt werden.

751. Wohin Cohere 2026 zeigt

Der aktuelle Stack bewegt sich von einzelnen NLP-APIs zu einem vollständigen Enterprise-AI-System: offene beziehungsweise privat deploybare Modelle, spezialisierte Retrieval- und Dokumentmodelle, agentisches Coding, North Automations und dedizierte Inferenz.

Die interessanteste Entwicklung ist nicht nur ein größeres Modell, sondern die vertikale Integration aus Modell, Retrieval, Datenzugriff, Orchestrierung, Deployment und Governance.

752. Fazit: Vom NLP-API-Anbieter zum Sovereign-Enterprise-AI-Stack

Cohere begann mit leicht zugänglichen NLP-APIs, machte Embeddings und Reranking zu eigenen Produktlinien, etablierte mit Command R produktives RAG und bündelte ab 2025/2026 generative, multimodale, agentische und private Fähigkeiten in Command A+, North und Model Vault.

Für technische Bewertung bleibt die wichtigste Regel die Schichtentrennung: Command ≠ Aya ≠ Embed ≠ Rerank ≠ Parse ≠ Transcribe ≠ North Mini Code ≠ North ≠ Compass ≠ Model Vault.

Weiterführende interne Themen

Die übergreifende Methoden- und Sicherheitsseite bleibt KI-Werkzeuge. Für direkte technische Vergleiche stehen die großen Chroniken zu OpenAI / ChatGPT, Anthropic Claude, Google Gemini, xAI / Grok, Meta AI / Llama / Muse, Perplexity AI, DeepSeek, Alibaba Qwen, Microsoft Copilot, Mistral AI / Vibe und Z.ai / GLM bereit.