> Es schien genau richtig für eine Führungsrolle zu sein, aber solche zusätzlichen Aufgaben wurden abgelehnt.
> Wenn der Autor eine neue Herausforderung für Wachstum vorschlug ...
Ist es aus der Sicht eines Technikers nicht Wachstum, das, was man gut kann, noch besser zu machen?
Egal in welchem Buch oder welchen Zitaten man nachschaut,
zu Punkt 3 steht es immer so da,
in der Realität aber
warum fragt man so etwas
warum wird das erst jetzt angesprochen
fragt man sogar so etwas
die dreifache Kombination und die Möglichkeit, als minderwertiger Partner wahrgenommen zu werden
Der Beitrag behandelt eher nur einen groben Überblick als wirklich praktische Tipps. Wenn ich noch ein paar Hinweise zur Entwicklung von LLM-basierten agentischen Systemen bzw. Agenten ergänzen darf: LLMs basieren letztlich auf Transformern (d. h. probabilistischem Schlussfolgern; sie verstehen auf Basis des aktuellen Tokens/States den nächsten Token nicht wirklich kontextuell/semantisch und geben das nächste Wort nicht „bewusst“ aus, sondern erzeugen Outputs probabilistisch). Deshalb liefern sie selbst mit gutem System-Prompt oft nicht die gewünschte Antwort (z. B. wenn man eine Antwort im JSON-Format verlangt und gelegentlich eine } fehlt). Daher ist es Pflicht, immer mehrere regex-basierte Fallback-Funktionen hinzuzufügen.
Und wenn man einen System-Prompt für strukturierte Outputs schreibt, verwendet man in der Regel eher ein Non-Reasoning-Modell. Je länger der Kontext wird, desto häufiger treten Halluzinationen auf, daher ist es oft besser, mehrere System-Prompts zu erstellen und zu chainen.
Wenn man einen Service entwickelt, können verschiedene Fehler auftreten, deshalb ist es entscheidend, die Service-Architektur modular und fault-tolerant zu entwerfen (z. B. den Supervisor-Agenten asynchron und die übrigen Agenten synchron), besonders bei agentischen Systemen bzw. Agenten, bei denen häufig unerwartete Outputs auftreten.
Deshalb sollte man von Anfang an beim Schreiben des Codes möglichst das SRP einhalten und deklarativ arbeiten; ich würde sagen, dass ein funktionaler Ansatz sinnvoll ist (= keine Side Effects und ein intuitiver Flow).
Je nachdem, ob man LLMs über eine API nutzt oder die Modelle selbst serven will, sieht es etwas anders aus. Falls man jedoch ein SLM oder LLM selbst serven möchte, sollte man das Model Serving nicht auf demselben Server betreiben, auf dem auch das Backend gehostet wird. Es ist fault-toleranter und besser, IO-bound Tasks und CPU-bound Tasks (d. h. Tasks, die eine GPU benötigen, Matrixmultiplikationen usw.) auf getrennten Servern zu platzieren (z. B. CPU-bound Tasks auf Runpod hosten).
Es gibt noch viele weitere Entwicklungstipps, aber ich höre hier auf, bevor es zu lang wird.
Sie haben schon eine grottige automatische Übersetzung in die koreanische Übersetzung hineingepfuscht, und jetzt haben sie sich wohl noch weiterentwickelt. Die automatische Übersetzung konnte man schon nicht aufhalten, also werden wir uns wohl auch den grottigen KI-Mist komplett antun!
Ich hasse AI-Funktionen, besonders Dienste, die im Hintergrund warten und angeblich helfen wollen, wirklich.
Wenn sie remote ausgeführt werden, gibt es das Problem, dass meine Informationen preisgegeben werden; wenn sie lokal ausgeführt werden, verbrauchen sie die Ressourcen meines Computers (CPU, Arbeitsspeicher, Akku, ...).
Das stimmt genau, haha
Das ist, als würde man ein Auto mit einem Marathon vergleichen..
hahaha „Möge die Funktion doch einfach existieren“
Ich stimme dir vollkommen zu!
Hahahahaha
Soll ich das wohl halluzinationsgetriebene Entwicklung nennen ...?;;
> Es schien genau richtig für eine Führungsrolle zu sein, aber solche zusätzlichen Aufgaben wurden abgelehnt.
> Wenn der Autor eine neue Herausforderung für Wachstum vorschlug ...
Ist es aus der Sicht eines Technikers nicht Wachstum, das, was man gut kann, noch besser zu machen?
Vielen Dank für Ihre freundlichen Worte!!
Vielleicht ging es eher um das im Verhältnis zu mehr Verantwortung und Arbeit nicht steigende Gehaltsniveau und die Behandlung?
Das ist ziemlich wahrscheinlich.
Natürlich wird ein guter Leader freundlich zuhören und
das Problem präzise lösen.
Egal in welchem Buch oder welchen Zitaten man nachschaut,
zu Punkt 3 steht es immer so da,
in der Realität aber
warum fragt man so etwas
warum wird das erst jetzt angesprochen
fragt man sogar so etwas
die dreifache Kombination und die Möglichkeit, als minderwertiger Partner wahrgenommen zu werden
Ich arbeite derzeit ebenfalls an einem Computer-Use-Agenten namens UseDesktop
https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq
usedesktop.com
und stimme dem größtenteils zu.
Der Beitrag behandelt eher nur einen groben Überblick als wirklich praktische Tipps. Wenn ich noch ein paar Hinweise zur Entwicklung von LLM-basierten agentischen Systemen bzw. Agenten ergänzen darf: LLMs basieren letztlich auf Transformern (d. h. probabilistischem Schlussfolgern; sie verstehen auf Basis des aktuellen Tokens/States den nächsten Token nicht wirklich kontextuell/semantisch und geben das nächste Wort nicht „bewusst“ aus, sondern erzeugen Outputs probabilistisch). Deshalb liefern sie selbst mit gutem System-Prompt oft nicht die gewünschte Antwort (z. B. wenn man eine Antwort im JSON-Format verlangt und gelegentlich eine
}fehlt). Daher ist es Pflicht, immer mehrere regex-basierte Fallback-Funktionen hinzuzufügen.Und wenn man einen System-Prompt für strukturierte Outputs schreibt, verwendet man in der Regel eher ein Non-Reasoning-Modell. Je länger der Kontext wird, desto häufiger treten Halluzinationen auf, daher ist es oft besser, mehrere System-Prompts zu erstellen und zu chainen.
Wenn man einen Service entwickelt, können verschiedene Fehler auftreten, deshalb ist es entscheidend, die Service-Architektur modular und fault-tolerant zu entwerfen (z. B. den Supervisor-Agenten asynchron und die übrigen Agenten synchron), besonders bei agentischen Systemen bzw. Agenten, bei denen häufig unerwartete Outputs auftreten.
Deshalb sollte man von Anfang an beim Schreiben des Codes möglichst das SRP einhalten und deklarativ arbeiten; ich würde sagen, dass ein funktionaler Ansatz sinnvoll ist (= keine Side Effects und ein intuitiver Flow).
Je nachdem, ob man LLMs über eine API nutzt oder die Modelle selbst serven will, sieht es etwas anders aus. Falls man jedoch ein SLM oder LLM selbst serven möchte, sollte man das Model Serving nicht auf demselben Server betreiben, auf dem auch das Backend gehostet wird. Es ist fault-toleranter und besser, IO-bound Tasks und CPU-bound Tasks (d. h. Tasks, die eine GPU benötigen, Matrixmultiplikationen usw.) auf getrennten Servern zu platzieren (z. B. CPU-bound Tasks auf Runpod hosten).
Es gibt noch viele weitere Entwicklungstipps, aber ich höre hier auf, bevor es zu lang wird.
Ich hoffe, das hilft jemandem.
Wie wäre es mit einem Dienst, den man auf einem privaten Remote-Server installiert?
Sie haben schon eine grottige automatische Übersetzung in die koreanische Übersetzung hineingepfuscht, und jetzt haben sie sich wohl noch weiterentwickelt. Die automatische Übersetzung konnte man schon nicht aufhalten, also werden wir uns wohl auch den grottigen KI-Mist komplett antun!
Na gut, CGI ist das eine, aber die Reaktion auf JSP überrascht mich echt, haha.
Ist JSP etwa schon zu so einem antiken Relikt geworden?
Ich hasse AI-Funktionen, besonders Dienste, die im Hintergrund warten und angeblich helfen wollen, wirklich.
Wenn sie remote ausgeführt werden, gibt es das Problem, dass meine Informationen preisgegeben werden; wenn sie lokal ausgeführt werden, verbrauchen sie die Ressourcen meines Computers (CPU, Arbeitsspeicher, Akku, ...).
Ich denke, das wird eine gute Referenz sein.
Ein aus Russland stammender Entwickler ist von Yandex zu Riot gewechselt und nun zu JPMorganChase.
Hahahaha, das ist so lustig.
Es fühlt sich stark so an, als würde nur der Name geändert.