Ich stimme dem, was in diesem Artikel vorgeschlagen wird, voll und ganz zu, und gleichzeitig stimme ich auch dem von Ihnen angesprochenen Problem zu.
Tatsächlich ist das auch ein Punkt, über den ich selbst nachdenke.
Es war zwar je nach Squad unterschiedlich, aber wenn man die Teammitglieder aktiv in die Sprint-Planung einbezogen hat, trat das von Ihnen erwähnte Problem nicht auf. Während wir den Kontext des Projekts geteilt und die sich in jedem Sprint verändernde Situation gemeinsam transparent gemacht haben, damit alle die sich ändernden Aufgaben ausreichend verstehen konnten, habe ich zugleich gefordert, die Arbeit sehr fein zu unterteilen.
Wie Sie gesagt haben: Betrachtet man aus Managementsicht den Fortschritt, die Messung der Arbeitsgeschwindigkeit, den Umgang mit unerwarteten Situationen und die Opportunitätskosten, wenn Arbeitsergebnisse nicht wie beabsichtigt ausfallen, dann zeigt sich am Ende doch, dass es besser vorangeht, wenn man die Arbeit in kleine Teile aufteilt.
Nicht nachvollziehbar. Das hat nicht einmal das Coding-Niveau eines Grundschülers, geschweige denn akademisches Niveau — warum teilt man so etwas überhaupt ...
Als jemand, der im Bereich Life Sciences arbeitet, möchte ich kurz meine Nutzungsergebnisse teilen.
Es werden zwei Research-Modi angeboten.
Quick summary
Die benötigte Zeit liegt bei etwa 5–6 Minuten (basierend auf einer 4070 ti super, 16GB, Mistral sowie Gemma 3:12b).
Es gibt Halluzinationen, daher werden Referenzen zwar direkt erzeugt, aber bei den Refs, die im Dokument verlinkt sind, scheint die Quelle eindeutig zu sein.
Es gibt die Tendenz, Antworten auf Fragen mit Fokus auf neue Technologien zu formulieren. Insbesondere wird versucht, einen Bezug zu AI herzustellen.
Detailed Report
Die benötigte Zeit liegt bei etwa 1 Stunde (4070 ti super 16GB, Gemma 3:12b).
Es ist im Grunde so, als würde ein einzelnes Review-Paper erstellt. Allerdings gibt es das Problem, dass die Zahl der Referenzen stark zurückgeht. Selbst wenn der Inhalt stimmt, fehlt dann die Belegbarkeit, daher ist hier etwas Verbesserung nötig. (Offenbar wird eine Art iterative Überarbeitung durchgeführt, um die Textqualität zu erhöhen, und dabei gehen die Ref-Links verloren.)
Allerdings liefert es definitiv Inhalte mit höherer Qualität als Quick summary.
In der Config-Datei lassen sich verschiedene Einstellungen vornehmen. Man kann die zu durchsuchende Datenbank auf PubMed beschränken und so die Qualität der Materialien weiter erhöhen. Außerdem kann man festlegen, wie viele Texte auf einmal durchsucht werden und wie viele Chunks bei der Nutzung von RAG erstellt werden sollen.
Wenn man berücksichtigt, dass es sich derzeit um Version 0.01V handelt, ist es äußerst beeindruckend, dass sich auf einer lokalen Maschine Berichte in diesem Umfang erzeugen lassen. Gerade im Bereich Life Sciences verwenden Chatbots oft verallgemeinernde Beschreibungen, aber die mit diesem Programm erstellten Berichte nutzen eine sehr wissenschaftliche Ausdrucksweise.
Das Programm unterstützt derzeit kein Koreanisch. Selbst wenn man Fragen auf Koreanisch stellt, wird der Bericht auf Englisch ausgegeben.
Außerdem gibt es beim Export als PDF das Problem, dass Koreanisch in der PDF-Datei nicht angezeigt wird.
Wenn nur das Problem gelöst wird, dass Refs während der Berichterstellung verschwinden, sowie das Halluzinationsproblem, halte ich es für ein wirklich leistungsstarkes Werkzeug.
Diesem Kommentar stimme ich sehr stark zu. Es bestand die Gefahr, dass Micromanagement bei technischen Aspekten aufkommt. Das ist wirklich nicht einfach.
Wenn man auf die Unterstützung regulärer Ausdrücke verzichtet und dann trotzdem nur doppelt so schnell wie ripgrep ist, ist der praktische Nutzen eher begrenzt.
Ich werde wohl einfach weiter ripgrep mit Regex-Unterstützung benutzen.
Persönlich ist es bei ts in manchen Fällen so, dass die Typen sehr komplex werden … es gibt Fälle, in denen ich fast aufgebe (und dann einfach any verwende). Das liegt wohl daran, dass mir das Verständnis der Sprache fehlt, oder? Je nach Situation verschwende ich wirklich viel Zeit damit, einfach nur die roten Wellenlinien loszuwerden.
Wir bemühen uns zwar, 80 % der Arbeit und 20 % Puffer einzuplanen, aber ich frage mich jedes Mal, nach welchem Maßstab man das festlegen soll … Manchmal denke ich auch, dass man es vielleicht einfach nach Zeit bemessen sollte.
Als ich eine Zeit lang, etwa ein Jahr, in Shanghai lebte, war ich einmal zu Besuch in Hangzhou (damals, um mir so etwas wie eine Impressionen-Show anzusehen). Die Stadt war sauber und auch die Landschaft am Westsee war schön, sodass ich dachte, es wäre wirklich ein großartiger Ort zum Leben. Offenbar ist es inzwischen auch ein guter Ort geworden, um Unternehmen zu gründen.
Ich stimme dem, was in diesem Artikel vorgeschlagen wird, voll und ganz zu, und gleichzeitig stimme ich auch dem von Ihnen angesprochenen Problem zu.
Tatsächlich ist das auch ein Punkt, über den ich selbst nachdenke.
Es war zwar je nach Squad unterschiedlich, aber wenn man die Teammitglieder aktiv in die Sprint-Planung einbezogen hat, trat das von Ihnen erwähnte Problem nicht auf. Während wir den Kontext des Projekts geteilt und die sich in jedem Sprint verändernde Situation gemeinsam transparent gemacht haben, damit alle die sich ändernden Aufgaben ausreichend verstehen konnten, habe ich zugleich gefordert, die Arbeit sehr fein zu unterteilen.
Wie Sie gesagt haben: Betrachtet man aus Managementsicht den Fortschritt, die Messung der Arbeitsgeschwindigkeit, den Umgang mit unerwarteten Situationen und die Opportunitätskosten, wenn Arbeitsergebnisse nicht wie beabsichtigt ausfallen, dann zeigt sich am Ende doch, dass es besser vorangeht, wenn man die Arbeit in kleine Teile aufteilt.
Nicht nachvollziehbar. Das hat nicht einmal das Coding-Niveau eines Grundschülers, geschweige denn akademisches Niveau — warum teilt man so etwas überhaupt ...
neue Technologienzu formulieren. Insbesondere wird versucht, einen Bezug zu AI herzustellen.In der Config-Datei lassen sich verschiedene Einstellungen vornehmen. Man kann die zu durchsuchende Datenbank auf PubMed beschränken und so die Qualität der Materialien weiter erhöhen. Außerdem kann man festlegen, wie viele Texte auf einmal durchsucht werden und wie viele Chunks bei der Nutzung von RAG erstellt werden sollen.
Wenn man berücksichtigt, dass es sich derzeit um Version 0.01V handelt, ist es äußerst beeindruckend, dass sich auf einer lokalen Maschine Berichte in diesem Umfang erzeugen lassen. Gerade im Bereich Life Sciences verwenden Chatbots oft
verallgemeinernde Beschreibungen, aber die mit diesem Programm erstellten Berichte nutzen eine sehr wissenschaftliche Ausdrucksweise.Das Programm unterstützt derzeit kein Koreanisch. Selbst wenn man Fragen auf Koreanisch stellt, wird der Bericht auf Englisch ausgegeben.
Außerdem gibt es beim Export als PDF das Problem, dass Koreanisch in der PDF-Datei nicht angezeigt wird.
Wenn nur das Problem gelöst wird, dass Refs während der Berichterstellung verschwinden, sowie das Halluzinationsproblem, halte ich es für ein wirklich leistungsstarkes Werkzeug.
Hahaha
Ich war von den vielen Plugins in Obsidian irgendwann ermüdet,
bin dann zu Reflect gewechselt und bin damit hochzufrieden.
Irgendwann habe ich angefangen, mich weniger mit TS zu beschäftigen, aber wenn ich solche Nachrichten sehe, werde ich doch wieder neugierig?
Deshalb halte ich mir den Freitagnachmittag komplett als Zeit für eigene Entwicklungsprojekte frei!
Diesem Kommentar stimme ich sehr stark zu. Es bestand die Gefahr, dass Micromanagement bei technischen Aspekten aufkommt. Das ist wirklich nicht einfach.
Wenn man auf die Unterstützung regulärer Ausdrücke verzichtet und dann trotzdem nur doppelt so schnell wie ripgrep ist, ist der praktische Nutzen eher begrenzt.
Ich werde wohl einfach weiter ripgrep mit Regex-Unterstützung benutzen.
GOAT.. krass
Chinas Aufstieg ist echt heftig.
Persönlich ist es bei
tsin manchen Fällen so, dass die Typen sehr komplex werden … es gibt Fälle, in denen ich fast aufgebe (und dann einfachanyverwende). Das liegt wohl daran, dass mir das Verständnis der Sprache fehlt, oder? Je nach Situation verschwende ich wirklich viel Zeit damit, einfach nur die roten Wellenlinien loszuwerden.Wir bemühen uns zwar, 80 % der Arbeit und 20 % Puffer einzuplanen, aber ich frage mich jedes Mal, nach welchem Maßstab man das festlegen soll … Manchmal denke ich auch, dass man es vielleicht einfach nach Zeit bemessen sollte.
Als ich eine Zeit lang, etwa ein Jahr, in Shanghai lebte, war ich einmal zu Besuch in Hangzhou (damals, um mir so etwas wie eine Impressionen-Show anzusehen). Die Stadt war sauber und auch die Landschaft am Westsee war schön, sodass ich dachte, es wäre wirklich ein großartiger Ort zum Leben. Offenbar ist es inzwischen auch ein guter Ort geworden, um Unternehmen zu gründen.
Es gibt zwar keine Angaben zur koreanischen Leistung, aber nach dem Ausprobieren sieht es nicht schlecht aus.
Wenn es Funktionen zur Umgehung von Anti-Bot-Maßnahmen hätte, könnte es wohl zum Gewinner des Marktes werden.
Die Debatte scheint ziemlich heiß zu sein – Anders Hejlsberg hat persönlich einen Kommentar hinterlassen.
https://github.com/microsoft/typescript-go/…
Ja, genau das!
Jemand, der sich wünscht, dass beim Kompilieren mit TypeScript das Ergebnis direkt als Binärdatei herauskommt
Vielen Dank für den Hinweis auf dieses gute Material.