Semantic Views brauchen eine IDE: Wir stellen vor: Semantic Studio

Wenn ein KI-Agent jemandem eine falsche Antwort gibt, kann es den ganzen Nachmittag dauern, von der Request-ID im Monitoring zur eigentlichen Ursache des Fehlers zu gelangen, auch wenn die Lösung selbst meist einfach ist, sobald man sie gefunden hat.

Oft hängen Probleme mit Agenten mit schlechten Metrikdefinitionen oder einer anderen Anweisung zusammen, meist innerhalb eines Semantic View. Vor ein oder zwei Jahren begannen Semantic Views bei Snowflake als Kontext für eine einzelne Bereitstellung von Snowflake Cortex Analyst, und man ging davon aus, dass ein oder zwei Personen die Daten gut genug kennen würden, um sie zu pflegen. Aber da Datenagenten immer beliebter werden, werden Semantic Views jetzt von jedem Agenten und jedem BI-Tool gelesen, das eine Metrik berührt, sodass eine einzeilige Änderung alle auf einmal betreffen kann. Der Editor, den wir für diese erste Zielgruppe entwickelt haben, war eine einzelne Seite im KI/ML-Bereich der Snowsight-Benutzeroberfläche, etwas losgelöst von all den anderen Arbeiten, die Datenexperten durchführten.

Wir freuen uns, ankündigen zu können, dass Semantic Studio, die IDE für Semantic Views, jetzt allgemein verfügbar ist. Es bringt die Erstellung von Semantic Views in Workspaces, neben die SQL-Skripte, Notebooks- und dbt-Projekte, die Ihr Team dort bereits hat, und fügt tiefe Snowflake CoCo-Integrationen, Git-Versionierung und UX-Verbesserungen hinzu.

Testen Sie Semantic Studio noch heute in Snowflake | Lesen Sie die Dokumentation

In der Vergangenheit war die Behebung von Problemen in Agenten ein mehrstufiger Prozess. Die erste Station war die Überprüfung des Monitorings, damit Sie die Details der Anfrage finden und ihre Request-ID abrufen konnten. Von dort aus öffneten Sie den Agent-Trace, um herauszufinden, welches Tool verantwortlich war. Die Eingrenzung bedeutete, das generierte SQL zu lesen und es mit einer Abfrage zu vergleichen, die Sie selbst geschrieben hätten.

Der Editor für Semantic Views befand sich in einem anderen Bereich von Snowsight und wurde am Anfang der Datei geöffnet, da die Benutzeroberfläche keinen Kontext dazu hatte, welchen Agentenfehler Sie gerade behoben haben. Die Überprüfung einer Hypothese über eine Metrik bedeutete, semantisches SQL gegen eine Definition auszuführen, die Sie noch nicht gespeichert hatten. Also öffneten Sie ein Worksheet und schrieben die Abfrage, die der Agent generiert hätte, von Hand. Wenn es funktionierte, gingen Sie zurück zum Editor, zurück zum Agenten und zurück zum Monitoring, um dies zu bestätigen.

Vier Oberflächen flossen in einen einzeiligen Fix ein, und die Arbeit, sie zu verbinden, lag bei Ihnen.

Unsere interne Telemetrie zeigte, dass mehr als die Hälfte aller Agentenentwickler zwischen der Benutzeroberfläche für Semantic Views und der Agenten-Admin-Benutzeroberfläche hin und her wechselten. Als wir die Entwickler fragten, was die Wartung so schwierig machte, beschrieben sie eher diese Arbeit als die Bearbeitung selbst.

All das zu korrelieren, ist eine Arbeit, die Sie am liebsten einem Coding-Agenten überlassen würden. Semantic Studio platziert Semantic Views in Workspaces, wo CoCo im Bereich neben dem Editor ausgeführt wird. Tabs sind keine Seitenladevorgänge, sodass sich der Wechsel zwischen einer Definition, einer Auswertung und dem Ergebnis dieser Auswertung viel schneller anfühlt.

Die Sitzung beginnt immer noch am selben Ort, mit einer Request-ID aus dem Monitoring. Wenn Sie CoCo einfach die ID geben, kann es Ihnen sagen, welche Metrik die Zahl erzeugt hat und warum, da es Zugriff auf die Agentenkonfiguration, die ausgeführte Abfrage und die Protokolle zusammen hat. Die Antwort verwendet natürliche Sprache, und Sie können es dann einfach bitten, Korrekturen an Ihrer Semantic Views vorzunehmen.

Es ist einfacher, dieser Antwort zu vertrauen, wenn eine Definition neben den Daten steht, die sie erzeugt. Eine Definition kann jederzeit einfach überprüft werden, indem man CoCo fragt, was sie zurückgibt, anstatt den Ausdruck zu lesen und sich das Ergebnis vorzustellen.

Der Fix kommt als Diff (ein Vergleich, der zeigt, was hinzugefügt, entfernt oder geändert werden würde), den Sie akzeptieren oder ablehnen können. Er wird im visuellen Editor oder in YAML angezeigt, und beide bleiben immer synchron.

Jeder andere Agent und jedes andere Dashboard, das diese Metriken liest, erhält die Änderung ebenfalls, sodass der letzte Teil des Nachmittags damit verbracht wird, sie sorgfältig zu implementieren. In Workspaces ist ein Semantic View eine Datei in einem Repository, das Ihrem Team gehört, was sie zu einer Version macht, die Sie hochstufen, anstatt zu einem Live-Objekt, das Sie überschreiben. Wenn Sie das Auswertungsset zuerst gegen die bearbeitete Ansicht ausführen, erfahren Sie, ob die Fragen, die früher funktioniert haben, immer noch funktionieren.

Von da an ist es derselbe Workflow wie bei allem anderen, was das Team bereitstellt. Die Änderung wird als Pull Request gesendet, sodass jemand anderes das Diff und die Begründung dahinter liest und CI die Auswertungen beim Zusammenführen ausführen kann. Die Bereitstellung zeigt genau, was sich ändern wird, und wartet auf eine Bestätigung, und eine Datei kann separat auf Entwicklung, Staging und Produktion verweisen. Danach befindet sich die Änderung mit einem Autor und einem Grund im Verlauf, und Sie können sie rückgängig machen.

Wenn Sie nun einen Semantic View in Snowsight öffnen, gelangen Sie zu Semantic Studio. Testen Sie Semantic Studio in Ihrem Konto oder lesen Sie die Dokumentation für weitere Informationen.