Heutzutage können Coding-Agenten die eigenen Schwächen ausgleichen, deshalb denke ich, dass die Einstiegshürde sinken kann, wenn man die eigenen Stärken genau kennt und sie gut nutzen kann.
Auch bei mir war Dokumentation immer ein Problem, aber seit ich einen Teil davon an einen Coding-Agenten delegiere, ist die Belastung geringer geworden, und während ich diese dokumentierten Unterlagen überprüfe, habe ich das Gefühl, nach und nach auch einen Blick für gute Dokumentation zu entwickeln.
Vielen Dank fürs Lesen! Früher gab es vieles, worum sich Menschen direkt kümmern mussten – Dokumentation, Testfälle, Validierung und so weiter. Da man inzwischen aber ziemlich viele dieser Aufgaben gemeinsam mit AI-Coding-Agents erledigen kann, scheint der Betriebsaufwand für Open Source deutlich geringer geworden zu sein als früher!
Stimmt, wenn man nur die Clipboard-History betrachtet, gibt es viele Überschneidungen. Aber Raycast hat neben dem Clipboard noch viele andere Funktionen, sodass es sich für mich etwas überladen angefühlt hat.
Worauf ich geachtet habe, sind diese Punkte:
Zunächst soll es leichtgewichtig sein und nur die Clipboard-History verwalten. Aktuell sind es etwa 2 MB.
Außerdem kann man gespeicherte Inhalte in der Detailansicht bearbeiten. Das war praktisch, wenn ich mehrere Prompts geprüft und vorab ein wenig angepasst habe.
Auch Suche und Foldering waren mir wichtig. Ich habe versucht, die Fälle abzudecken, in denen man bei der Arbeit Informationen nur einmal braucht oder sie später ungern wieder suchen möchte.
Die Suche funktioniert über Inhalt, Tags, Titel usw.
Später möchte ich ermöglichen, Funktionen oder Layouts direkt über Plugins hinzuzufügen, aber das ist noch nicht konkret ausgearbeitet.
Ich halte Raycast ebenfalls für eine gute App und möchte daran arbeiten, dass es eine Auswahl je nach persönlichem Geschmack sein kann.
Das Schwierigste bei solchen Tools ist nicht das Aufbauen, sondern das Wegwerfen; auffällig ist, dass der „Garden“ in einen eigenen Lifecycle ausgelagert wurde.
Kontext, den man einem Agenten gibt, ist mit der Zeit nicht einfach nur nutzlos, sondern schädlich. Wenn Menschen ein Dokument lesen, haben sie ein Gefühl dafür: „Das klingt nach einem alten Stand.“ Ein Modell hat dieses Gefühl nicht und übernimmt eine Invariante, die vor drei Monaten wahr war, so, als wäre sie auch heute noch wahr. Code bricht wenigstens beim Kompilieren, aber ein Wiki liegt still und leise falsch.
Deshalb frage ich mich, ob auf einer Seite vermerkt wird, auf welchen Stand sie sich bezieht und auf welcher Grundlage sie geschrieben wurde. Die Entscheidung, sie als Markdown im Repository abzulegen und in Git reviewen zu lassen, halte ich in dieser Hinsicht für richtig. Im Diff sieht man aber nur, wann sich das Dokument geändert hat, nicht, bis wann sein Inhalt noch gültig ist.
Bei 1.700 Einträgen ist eine Performance-Diskussion praktisch bedeutungslos; egal ob direkt im Frontend verarbeitet oder mit Backend, beides erscheint sofort. Deshalb sollte das Entscheidungskriterium nicht die Geschwindigkeit sein, sondern ob bestehende Python-Logik neu geschrieben werden muss oder nicht.
Nach diesem Maßstab passt Streamlit am besten. Man kann die Matching-Logik unverändert importieren, und wenn die Oberfläche nur aus fünf selectboxen und einer Ergebnistabelle besteht, muss man keinen Frontend-Code schreiben. Lädt man es in die Streamlit Community Cloud hoch, bekommt man kostenlos einen teilbaren Link, und wenn JSON zur Laufzeit eingelesen wird, werden durch einfaches Austauschen der Datei auch die neuesten Daten übernommen.
Statisches HTML ist zwar einfacher zu deployen, dafür muss die Python-Logik aber nach JS übertragen werden; wenn die Punkteberechnung auch nur etwas komplexer ist, gehen für dieses Portieren schnell ein paar Tage drauf. Wenn das Ziel ist, noch diese Woche etwas Funktionsfähiges zu zeigen, scheint es besser, dieses Risiko nicht einzugehen.
Ein Punkt noch: Streamlit wirkt eher wie ein Tool als wie ein Produkt. Wenn die Demo für interne Entscheidungsträger ist und es darum geht zu prüfen, ob bei einer Eingabe tatsächlich etwas erscheint, ist das egal; bei einer Demo für externe Kunden sollte man diesen Punkt aber berücksichtigen.
Oh … Bei Show-GN-Beiträgen wollte ich schon immer nicht nur ein schlichtes „Ich habe etwas gebaut“, sondern auch solche Einblicke sehen — deshalb freut es mich umso mehr, jetzt so einen Beitrag zu lesen, haha.
Es entspricht wohl der menschlichen Psychologie, dass man lieber alles einer einzigen Person gibt und erwartet, dass sie sich um alles gut kümmert, statt für jeden einzelnen Fall einen Experten zu suchen und ihm nur einen begrenzten Aufgabenbereich zu überlassen.
Ist es da nicht fast unvermeidlich, dass auch bei LLMs die Belohnungsfunktion so gestaltet wird, dass sie einfach alles annimmt, was man ihnen hinwirft?
Selbst bei einem öffentlichen Benchmark habe ich zum ersten Mal so konkrete Zahlen gesehen. Vielen Dank.
Das Verhältnis von 159 / 76 / 3.197 Fällen ist mir besonders aufgefallen. Dass die nicht beurteilbaren Fälle (keine ID) so überwältigend viele sind, bedeutet letztlich, dass die meisten Duplikate in einem Bereich liegen, in dem die Nachverfolgung selbst nicht möglich ist — und es bestätigt erneut, dass man sich nicht einfach mit „es gibt ja Audit-Logs“ in Sicherheit wiegen sollte.
Die Ausrichtung, Erzeugung (POST) zu priorisieren, deckt sich exakt mit unserem Design. Genau deshalb wollten wir in unserer Hash Chain den Idempotency Key zuerst an das Erzeugungs-Event hängen.
Den Vorschlag mit der E-Mail-Message-ID werde ich direkt übernehmen. Schon allein die Ergänzung „Entity-ID in der Antwort verpflichtend“ in der Spezifikation interner Tools verändert die Prüfbarkeit der Audit-Logs deutlich. Wenn man die ID in der Hash Chain als Anker verwendet, lässt sich auch rein rechnerisch prüfen, ob ein Duplikat vorliegt.
Konnten Sie zufällig feststellen, auf welche Tool-Typen sich die 3.197 Fälle „keine ID“ konzentriert haben? Mich würde interessieren, wie viele Tools außer E-Mail nur „Erfolg/Fehlschlag“ zurückgeben.
Es ist ein ziemlich erfreuliches Gefühl, jemanden zu treffen, der etwas Ähnliches baut!
Ich habe schon vor der großen Claude-Ära ziemlich viel Zeit in Rust investiert, indem ich damit APIs und auch CLIs gebaut habe!
Erst vor relativ kurzer Zeit kam mir der Gedanke, tmux ersetzen zu müssen. Daher ist es noch nicht lange her, dass ich tmux selbst ersetzt habe, aber ich habe auch einen Multiplexer gebaut und ab dem zweiten Tag die Nutzung von tmux auf ein Minimum reduziert!
Ich denke, neben dem Reifegrad war ein großer Faktor auch, dass ein Fallback auf andere Tools statt meines eigenen Tools eher zu einem Ausweichort wurde und ich deshalb vielleicht nicht mit voller Hingabe weiterentwickelt habe.
Dass es dann vier Monate gedauert hat, lag wohl auch daran, dass es, wie Sie gesagt haben, lange gedauert hat, die Funktionen nach meinem Geschmack in eine Form zu erweitern, die mehrere Menschen nutzen können, und dass es auch einiges an Mut brauchte, das öffentlich zu machen.
Und was die Motivation für ein privat betriebenes Projekt angeht, während Programme wie orca von Unternehmen unterstützt werden, bin ich eher positiv eingestellt.
Natürlich gibt es kaum eine größere Motivation als finanzielle Belastung, aber ich habe meinen gesamten Workflow auf die Tools abgestimmt, die ich selbst nutze. Wenn ich also sofort arbeiten will, muss ich dieses Tool verbessern, und deshalb investiere ich auch meine freie Zeit so weit wie möglich in die Verbesserung dieser Tools.
Natürlich gibt es das Problem, dass alles vorbei ist, sobald meine Motivation nachlässt, aber um genau das zu verhindern, habe ich meinen Workflow absichtlich auf meine Tools optimiert, damit es gar nicht erst so weit kommt!
Persönlich denke ich, dass im Vergleich zu konkurrierenden Tools schon jetzt nicht die Technik fehlt, sondern nur das Marketing; deshalb war auch die Veröffentlichung, um Feedback zu bekommen, ein ziemlich großer Schritt.
Das GPU-Rendering habe ich weniger wegen der Unterstützung für Windows umgesetzt, sondern eher als technische Herausforderung und zur Optimierung für Programme, die den Terminalbildschirm vollständig ausfüllen.
Persönlich nutze ich Windows schon lange nicht mehr für die Entwicklung, daher habe ich die Unterstützung für dieses OS nicht besonders tiefgehend bedacht, aber inzwischen gibt es wohl eine ziemlich solide Grundlage, sodass es einen Versuch wert sein könnte.
Mein Ziel ist einfach, dass für meine gesamte Entwicklung am Ende nur noch copad ausreicht, und dafür habe ich auch ein Plugin-System eingebaut!
Deshalb versuche ich, Funktionen, die eine GUI benötigen, so weit wie möglich direkt in copad zu implementieren.
Bei der Rendering-Methode gibt es zwar recht große Unterschiede, aber aus Sicht der Endnutzer fühlt sich der Unterschied tatsächlich nicht so groß an, sodass es mir fast etwas unangenehm ist, das im Detail vorzustellen. Wie Sie gesagt haben, leben wir wohl in einer Zeit, in der mit sinkenden Produktionskosten am Ende das am besten ist, was einem am besten liegt..!
Ich habe es noch nicht in einem echten Produktivservice einsetzen können. Diese Zahlen stammen alle aus öffentlichen Benchmark-Traces, deshalb sollte ich diese Einschränkung wohl zuerst erwähnen.
Trotzdem gibt es eine Beobachtung, die für das Design eines Idempotency Keys hilfreich sein könnte.
Um „zweimal aufgerufen“ vs. „zweimal ausgeführt“ zu unterscheiden, habe ich die Entity-IDs in den Antworten verglichen. Wenn bei zwei Aufrufen mit denselben Parametern die Antwort-IDs unterschiedlich sind, wurden tatsächlich zwei Objekte erzeugt; wenn sie gleich sind, hat die API das selbst herausgefiltert.
Nach dem Toolathlon-Benchmark entfielen bei doppelten Aufrufen von Tools mit Zustandsänderung auf:
Fälle mit unterschiedlicher ID (tatsächliche doppelte Erstellung): 159
Fälle mit gleicher ID (API dedup): 76
Keine ID vorhanden, daher nicht beurteilbar: 3.197
Dabei zeigte sich ein Muster. Alle 159 Fälle mit unterschiedlicher ID waren reine Erstellungs-Tools (Dokument erstellen, Spreadsheet erstellen, Datei-Upload, Quiz erstellen). Dagegen gab es bei Aktualisierungsarten (patch, update, enroll) keinen einzigen Fall mit unterschiedlicher ID. Sie verwiesen auf dasselbe Zielobjekt, es wurde also nichts neu erzeugt.
Wenn Sie also einen Idempotency Key einführen, sollte die Erstellungsseite (POST) vermutlich Priorität haben. Bei Aktualisierungen wirkte es oft so, als seien sie ohnehin auf natürliche Weise idempotent.
Und das zuvor erwähnte E-Mail-Problem taucht hier erneut auf. Beim Versand von E-Mails bestand die Antwort nur aus der Zeichenkette „Erfolg“, daher war ein ID-Vergleich unmöglich. Selbst wenn man einen Idempotency Key anbringt, lässt sich allein anhand des Traces nicht prüfen, ob er tatsächlich funktioniert hat. Wenn Sie interne Tools entwerfen, wäre es schon für die Prüfung im Audit-Log ausreichend, im Versandergebnis eine Message-ID zurückzugeben. Das scheint auch gut zu dem von Ihnen erwähnten Hash-Chain-Ansatz zu passen.
Noch einmal zur Einschränkung: Die obigen Zahlen stammen vollständig aus Benchmark-Traces, daher ist unklar, ob im realen Betriebsumfeld dieselben Verhältnisse gelten. Falls Sie einmal Traces laufen lassen, würde mich interessieren, wie stark die Ergebnisse davon abweichen.
Deshalb ist es am besten, geschlossene LLMs möglichst günstig auf den Markt zu bringen. Wenn der Zugang zu leistungsfähiger Intelligenz hoch ist, sinken ganz natürlich die Anreize, Open-Weight-Modelle zu entwickeln, und die technologische Führungsrolle kann auch bei normalen Institutionen liegen. Aber ausgerechnet Anthropic ist doch der exklusivste Anbieter am Markt, oder?
Heutzutage können Coding-Agenten die eigenen Schwächen ausgleichen, deshalb denke ich, dass die Einstiegshürde sinken kann, wenn man die eigenen Stärken genau kennt und sie gut nutzen kann.
Auch bei mir war Dokumentation immer ein Problem, aber seit ich einen Teil davon an einen Coding-Agenten delegiere, ist die Belastung geringer geworden, und während ich diese dokumentierten Unterlagen überprüfe, habe ich das Gefühl, nach und nach auch einen Blick für gute Dokumentation zu entwickeln.
Vielen Dank fürs Lesen! Früher gab es vieles, worum sich Menschen direkt kümmern mussten – Dokumentation, Testfälle, Validierung und so weiter. Da man inzwischen aber ziemlich viele dieser Aufgaben gemeinsam mit AI-Coding-Agents erledigen kann, scheint der Betriebsaufwand für Open Source deutlich geringer geworden zu sein als früher!
@xguru Der Link scheint falsch zu sein~
Stimmt, wenn man nur die Clipboard-History betrachtet, gibt es viele Überschneidungen. Aber Raycast hat neben dem Clipboard noch viele andere Funktionen, sodass es sich für mich etwas überladen angefühlt hat.
Worauf ich geachtet habe, sind diese Punkte:
Zunächst soll es leichtgewichtig sein und nur die Clipboard-History verwalten. Aktuell sind es etwa 2 MB.
Außerdem kann man gespeicherte Inhalte in der Detailansicht bearbeiten. Das war praktisch, wenn ich mehrere Prompts geprüft und vorab ein wenig angepasst habe.
Auch Suche und Foldering waren mir wichtig. Ich habe versucht, die Fälle abzudecken, in denen man bei der Arbeit Informationen nur einmal braucht oder sie später ungern wieder suchen möchte.
Die Suche funktioniert über Inhalt, Tags, Titel usw.
Später möchte ich ermöglichen, Funktionen oder Layouts direkt über Plugins hinzuzufügen, aber das ist noch nicht konkret ausgearbeitet.
Ich halte Raycast ebenfalls für eine gute App und möchte daran arbeiten, dass es eine Auswahl je nach persönlichem Geschmack sein kann.
Vielen Dank für das Feedback.
Das Schwierigste bei solchen Tools ist nicht das Aufbauen, sondern das Wegwerfen; auffällig ist, dass der „Garden“ in einen eigenen Lifecycle ausgelagert wurde.
Kontext, den man einem Agenten gibt, ist mit der Zeit nicht einfach nur nutzlos, sondern schädlich. Wenn Menschen ein Dokument lesen, haben sie ein Gefühl dafür: „Das klingt nach einem alten Stand.“ Ein Modell hat dieses Gefühl nicht und übernimmt eine Invariante, die vor drei Monaten wahr war, so, als wäre sie auch heute noch wahr. Code bricht wenigstens beim Kompilieren, aber ein Wiki liegt still und leise falsch.
Deshalb frage ich mich, ob auf einer Seite vermerkt wird, auf welchen Stand sie sich bezieht und auf welcher Grundlage sie geschrieben wurde. Die Entscheidung, sie als Markdown im Repository abzulegen und in Git reviewen zu lassen, halte ich in dieser Hinsicht für richtig. Im Diff sieht man aber nur, wann sich das Dokument geändert hat, nicht, bis wann sein Inhalt noch gültig ist.
Bei 1.700 Einträgen ist eine Performance-Diskussion praktisch bedeutungslos; egal ob direkt im Frontend verarbeitet oder mit Backend, beides erscheint sofort. Deshalb sollte das Entscheidungskriterium nicht die Geschwindigkeit sein, sondern ob bestehende Python-Logik neu geschrieben werden muss oder nicht.
Nach diesem Maßstab passt Streamlit am besten. Man kann die Matching-Logik unverändert importieren, und wenn die Oberfläche nur aus fünf
selectboxen und einer Ergebnistabelle besteht, muss man keinen Frontend-Code schreiben. Lädt man es in die Streamlit Community Cloud hoch, bekommt man kostenlos einen teilbaren Link, und wenn JSON zur Laufzeit eingelesen wird, werden durch einfaches Austauschen der Datei auch die neuesten Daten übernommen.Statisches HTML ist zwar einfacher zu deployen, dafür muss die Python-Logik aber nach JS übertragen werden; wenn die Punkteberechnung auch nur etwas komplexer ist, gehen für dieses Portieren schnell ein paar Tage drauf. Wenn das Ziel ist, noch diese Woche etwas Funktionsfähiges zu zeigen, scheint es besser, dieses Risiko nicht einzugehen.
Ein Punkt noch: Streamlit wirkt eher wie ein Tool als wie ein Produkt. Wenn die Demo für interne Entscheidungsträger ist und es darum geht zu prüfen, ob bei einer Eingabe tatsächlich etwas erscheint, ist das egal; bei einer Demo für externe Kunden sollte man diesen Punkt aber berücksichtigen.
Es scheint, als würde fast alles unterstützt, was es auch in Raycast gibt — worin genau liegen denn die Unterschiede?
Oh … Bei Show-GN-Beiträgen wollte ich schon immer nicht nur ein schlichtes „Ich habe etwas gebaut“, sondern auch solche Einblicke sehen — deshalb freut es mich umso mehr, jetzt so einen Beitrag zu lesen, haha.
Es entspricht wohl der menschlichen Psychologie, dass man lieber alles einer einzigen Person gibt und erwartet, dass sie sich um alles gut kümmert, statt für jeden einzelnen Fall einen Experten zu suchen und ihm nur einen begrenzten Aufgabenbereich zu überlassen.
Ist es da nicht fast unvermeidlich, dass auch bei LLMs die Belohnungsfunktion so gestaltet wird, dass sie einfach alles annimmt, was man ihnen hinwirft?
Selbst bei einem öffentlichen Benchmark habe ich zum ersten Mal so konkrete Zahlen gesehen. Vielen Dank.
Das Verhältnis von 159 / 76 / 3.197 Fällen ist mir besonders aufgefallen. Dass die nicht beurteilbaren Fälle (keine ID) so überwältigend viele sind, bedeutet letztlich, dass die meisten Duplikate in einem Bereich liegen, in dem die Nachverfolgung selbst nicht möglich ist — und es bestätigt erneut, dass man sich nicht einfach mit „es gibt ja Audit-Logs“ in Sicherheit wiegen sollte.
Die Ausrichtung, Erzeugung (POST) zu priorisieren, deckt sich exakt mit unserem Design. Genau deshalb wollten wir in unserer Hash Chain den Idempotency Key zuerst an das Erzeugungs-Event hängen.
Den Vorschlag mit der E-Mail-Message-ID werde ich direkt übernehmen. Schon allein die Ergänzung „Entity-ID in der Antwort verpflichtend“ in der Spezifikation interner Tools verändert die Prüfbarkeit der Audit-Logs deutlich. Wenn man die ID in der Hash Chain als Anker verwendet, lässt sich auch rein rechnerisch prüfen, ob ein Duplikat vorliegt.
Konnten Sie zufällig feststellen, auf welche Tool-Typen sich die 3.197 Fälle „keine ID“ konzentriert haben? Mich würde interessieren, wie viele Tools außer E-Mail nur „Erfolg/Fehlschlag“ zurückgeben.
Derzeit wird noch optimiert, daher dürfte alles im Laufe dieser Woche fertig werden und dann etwas aufgeräumter aussehen :)
Sie haben ja schon die Umschaltfunktion auf Koreanisch hinzugefügt :)
Vielen Dank
Es ist ein ziemlich erfreuliches Gefühl, jemanden zu treffen, der etwas Ähnliches baut!
Ich habe schon vor der großen Claude-Ära ziemlich viel Zeit in Rust investiert, indem ich damit APIs und auch CLIs gebaut habe!
Erst vor relativ kurzer Zeit kam mir der Gedanke,
tmuxersetzen zu müssen. Daher ist es noch nicht lange her, dass ichtmuxselbst ersetzt habe, aber ich habe auch einen Multiplexer gebaut und ab dem zweiten Tag die Nutzung vontmuxauf ein Minimum reduziert!Ich denke, neben dem Reifegrad war ein großer Faktor auch, dass ein Fallback auf andere Tools statt meines eigenen Tools eher zu einem Ausweichort wurde und ich deshalb vielleicht nicht mit voller Hingabe weiterentwickelt habe.
Dass es dann vier Monate gedauert hat, lag wohl auch daran, dass es, wie Sie gesagt haben, lange gedauert hat, die Funktionen nach meinem Geschmack in eine Form zu erweitern, die mehrere Menschen nutzen können, und dass es auch einiges an Mut brauchte, das öffentlich zu machen.
Und was die Motivation für ein privat betriebenes Projekt angeht, während Programme wie orca von Unternehmen unterstützt werden, bin ich eher positiv eingestellt.
Natürlich gibt es kaum eine größere Motivation als finanzielle Belastung, aber ich habe meinen gesamten Workflow auf die Tools abgestimmt, die ich selbst nutze. Wenn ich also sofort arbeiten will, muss ich dieses Tool verbessern, und deshalb investiere ich auch meine freie Zeit so weit wie möglich in die Verbesserung dieser Tools.
Natürlich gibt es das Problem, dass alles vorbei ist, sobald meine Motivation nachlässt, aber um genau das zu verhindern, habe ich meinen Workflow absichtlich auf meine Tools optimiert, damit es gar nicht erst so weit kommt!
Persönlich denke ich, dass im Vergleich zu konkurrierenden Tools schon jetzt nicht die Technik fehlt, sondern nur das Marketing; deshalb war auch die Veröffentlichung, um Feedback zu bekommen, ein ziemlich großer Schritt.
Das GPU-Rendering habe ich weniger wegen der Unterstützung für Windows umgesetzt, sondern eher als technische Herausforderung und zur Optimierung für Programme, die den Terminalbildschirm vollständig ausfüllen.
Persönlich nutze ich Windows schon lange nicht mehr für die Entwicklung, daher habe ich die Unterstützung für dieses OS nicht besonders tiefgehend bedacht, aber inzwischen gibt es wohl eine ziemlich solide Grundlage, sodass es einen Versuch wert sein könnte.
Mein Ziel ist einfach, dass für meine gesamte Entwicklung am Ende nur noch copad ausreicht, und dafür habe ich auch ein Plugin-System eingebaut!
Deshalb versuche ich, Funktionen, die eine GUI benötigen, so weit wie möglich direkt in copad zu implementieren.
Bei der Rendering-Methode gibt es zwar recht große Unterschiede, aber aus Sicht der Endnutzer fühlt sich der Unterschied tatsächlich nicht so groß an, sodass es mir fast etwas unangenehm ist, das im Detail vorzustellen. Wie Sie gesagt haben, leben wir wohl in einer Zeit, in der mit sinkenden Produktionskosten am Ende das am besten ist, was einem am besten liegt..!
Samsung, das interne Beratungsprotokolle in den Disziplinarordnern der Personalabteilung sammelte, ist eben wirklich ein global führendes Unternehmen.
Ich habe es noch nicht in einem echten Produktivservice einsetzen können. Diese Zahlen stammen alle aus öffentlichen Benchmark-Traces, deshalb sollte ich diese Einschränkung wohl zuerst erwähnen.
Trotzdem gibt es eine Beobachtung, die für das Design eines Idempotency Keys hilfreich sein könnte.
Um „zweimal aufgerufen“ vs. „zweimal ausgeführt“ zu unterscheiden, habe ich die Entity-IDs in den Antworten verglichen. Wenn bei zwei Aufrufen mit denselben Parametern die Antwort-IDs unterschiedlich sind, wurden tatsächlich zwei Objekte erzeugt; wenn sie gleich sind, hat die API das selbst herausgefiltert.
Nach dem Toolathlon-Benchmark entfielen bei doppelten Aufrufen von Tools mit Zustandsänderung auf:
Fälle mit unterschiedlicher ID (tatsächliche doppelte Erstellung): 159
Fälle mit gleicher ID (API dedup): 76
Keine ID vorhanden, daher nicht beurteilbar: 3.197
Dabei zeigte sich ein Muster. Alle 159 Fälle mit unterschiedlicher ID waren reine Erstellungs-Tools (Dokument erstellen, Spreadsheet erstellen, Datei-Upload, Quiz erstellen). Dagegen gab es bei Aktualisierungsarten (
patch,update,enroll) keinen einzigen Fall mit unterschiedlicher ID. Sie verwiesen auf dasselbe Zielobjekt, es wurde also nichts neu erzeugt.Wenn Sie also einen Idempotency Key einführen, sollte die Erstellungsseite (
POST) vermutlich Priorität haben. Bei Aktualisierungen wirkte es oft so, als seien sie ohnehin auf natürliche Weise idempotent.Und das zuvor erwähnte E-Mail-Problem taucht hier erneut auf. Beim Versand von E-Mails bestand die Antwort nur aus der Zeichenkette „Erfolg“, daher war ein ID-Vergleich unmöglich. Selbst wenn man einen Idempotency Key anbringt, lässt sich allein anhand des Traces nicht prüfen, ob er tatsächlich funktioniert hat. Wenn Sie interne Tools entwerfen, wäre es schon für die Prüfung im Audit-Log ausreichend, im Versandergebnis eine Message-ID zurückzugeben. Das scheint auch gut zu dem von Ihnen erwähnten Hash-Chain-Ansatz zu passen.
Noch einmal zur Einschränkung: Die obigen Zahlen stammen vollständig aus Benchmark-Traces, daher ist unklar, ob im realen Betriebsumfeld dieselben Verhältnisse gelten. Falls Sie einmal Traces laufen lassen, würde mich interessieren, wie stark die Ergebnisse davon abweichen.
Das ist also ein Korb für Screenshots.
Einen ähnlichen JIT-Compiler-Ansatz verfolgt numba, aber hier wirkt die Abdeckung größer.
Wenn sie einfach etwas wie gps oss 120b herausbringen würden, wirkte das zumindest einigermaßen überzeugend – aber na ja.
Deshalb ist es am besten, geschlossene LLMs möglichst günstig auf den Markt zu bringen. Wenn der Zugang zu leistungsfähiger Intelligenz hoch ist, sinken ganz natürlich die Anreize, Open-Weight-Modelle zu entwickeln, und die technologische Führungsrolle kann auch bei normalen Institutionen liegen. Aber ausgerechnet Anthropic ist doch der exklusivste Anbieter am Markt, oder?