Das weckt Erinnerungen daran, wie ich Ende der 2000er-Jahre bei einem Anbieter von Fahrzeugnavigationssoftware gearbeitet und ein Modul zur Wegesuche entwickelt habe.
Dijkstra ist für die Routenberechnung in Navigationssystemen viel zu langsam und wird deshalb nicht verwendet; stattdessen nutzt man die heuristisch verbesserte Version, die A*-Suche (A Star). Wie ich nachgesehen habe, ist A* kein SSSP-, sondern ein SPSP-Algorithmus (Single-Pair Shortest Path).
markitdown ist zwar praktisch für die Konvertierung zwischen Formaten, aber bei PDF sollte man es auf keinen Fall verwenden, haha.
Für die Dokumentenextraktion gibt es bereits viele Ansätze mit multimodalen LLMs wie Gemini, und auch in Benchmarks schneiden sie ziemlich gut ab. Das Problem sind allerdings die Kosten.
Eher niedrigschwellig … wobei … für die Implementierung von Formularen eigentlich schon ein html-input-Tag reichen würde, man aber unnötig viel über State, JSX sowie unkontrollierte/kontrollierte Komponenten wissen muss und dabei viel Code erzeugt – ich vermute, dass genau solche Punkte die Motivation des Artikels waren.
Da ich nicht rauche, wusste ich erst nicht, worum es geht, aber Sie meinen wohl, dass für ein Wegwerfprodukt viel zu viele Ressourcen verbraucht werden.
Es klingt so, als würde man sagen, die bisherige Methode sei tot, nur weil es nun eine neue Alternative gibt.
Stimmt es wirklich, dass die bisherige Methode nicht mehr verwendet werden kann und man zwingend die neue Methode nutzen muss?
Ich konnte mich mit dem Konzept stark identifizieren und habe es am Wochenende in einem neuen Projekt ein wenig getestet, aber es funktioniert nicht so gut wie gedacht. Es scheint noch einiges an Verbesserungen zu brauchen. Der grobe Ablauf ist zunächst, wie schon mehrfach vorgestellt, folgender:
Verfassung schreiben → Spezifikation schreiben → Tasks schreiben → Implementierung
Das Problem ist:
Die Datei constitution.md ist zwar der zentrale Leitfaden dafür, "wie entwickelt werden soll", enthält aber nicht, "was diese App am Ende eigentlich sein soll"
spec.md ist ein Dokument, das eine einzelne Funktion beschreibt
Es gibt kein Master-Dokument dazu, "was diese App ist"
Wenn man die Diskussionen auf GitHub liest, scheint die Idee zu sein, dass eine chain of specs letztlich zur source of truth wird. Das wirkt etwas fragwürdig, ist aber ungefähr nachvollziehbar.
Über die Befehle /specify und /tasaks werden viele Dokumente als Artefakte erzeugt (also genau das gewünschte Ergebnis), aber dadurch wird der Kontext sehr schnell verbraucht (ich nutze Claude Code)
Sobald man mit der Implementierung beginnt, entfernt man sich vorübergehend wieder von Spec Kit und schließt die Umsetzung wie gewohnt im Gespräch mit Claude Code ab
Wenn der Kontext komplett aufgebraucht ist und man compaction ausführt oder eine neue Sitzung startet, vergisst es die von Spec Kit erzeugten Dokumente
Wenn man die in tasks.md definierten Arbeiten ausführt, überschreibt man mitunter Dinge, die man vorher sauber gebaut hatte, und beim Beheben von Bugs entstehen auch neue Funktionen, sodass man sich immer weiter von tasks.md entfernt. Ich verstehe nicht, welchen Sinn es hat, tasks.md dauerhaft aufzubewahren.
Zu folgendem Fazit bin ich vorerst gekommen:
Auch wenn am Ende etwas anderes herauskommt als ursprünglich gedacht, sollte man die Spezifikation zunächst fertigstellen und dann eine neue Spezifikation anlegen, um es schrittweise zu verbessern
Die erste Spezifikation wird zwangsläufig groß; für die Funktionen der App sollte man sie am besten gar nicht beschreiben und lieber nur Boilerplate erstellen
Wenn man etwas auf PoC-Niveau baut, ist es vermutlich besser, Spec Kit nicht zu verwenden
Dem stimme ich sehr zu. Selbst wenn etwas noch so gut gemacht ist, sind Eingriffe störend. Am besten ist es, wenn es wirkt, als wäre es nicht da, und erst dann auftaucht und hilft, wenn man es braucht — entscheidend dürfte dabei sein, wie passend es die jeweilige Situation einschätzt. Auch bei Menschen gibt es solche, die das gut können, und solche, die es nicht können; wenn künstliche Intelligenz das überwinden kann, dürfte das eine Revolution auslösen.
Genauer gesagt ist es bei Vulkan wohl korrekt zu sagen: „Die Vulkan-API, die die iGPU des Pi 5 unterstützt, wird von llama.cpp derzeit noch nicht unterstützt.“ Ich bin auch neugierig, welche Leistung möglich gewesen wäre, wenn das unterstützt worden wäre.
markitdown verwendet für das PDF-Parsing https://github.com/pdfminer/pdfminer.six und extrahiert Text oder eingebettete Bilder direkt aus der Datei. Allein beim Gedanken an OCR wird mir schon ganz schwindelig...
Für alle, die koreanische Prompts brauchen: Hier gibt es ins Koreanische übersetzte Prompts. Mit nur einem Klick werden sie direkt in ChatGPT und Claude eingefügt.
Als ein oder zwei fünfsekündige Werbespots liefen, habe ich sie noch mit dem Gedanken an ein gegenseitiges Miteinander komplett angesehen. Aber als sie mit endlosen aufeinanderfolgenden Anzeigen und Werbung mitten im Video eindeutig zu weit gegangen sind, habe ich sofort einen Adblocker installiert, haha.
Neulich habe ich gesehen, dass es bei civit.ai eine Bounty-Funktion gibt, und dachte zuerst, es handle sich um ein Bug-Bounty-Programm. Aber dort werden Funktionen tatsächlich öffentlich ausgeschrieben, zusammen mit einer Belohnung für die Umsetzung. Ein etwas ungewöhnliches Konzept, fand ich. Wenn man Geld hat, aber intern nicht die nötigen Fähigkeiten, könnte das gar nicht schlecht sein.
Das weckt Erinnerungen daran, wie ich Ende der 2000er-Jahre bei einem Anbieter von Fahrzeugnavigationssoftware gearbeitet und ein Modul zur Wegesuche entwickelt habe.
Dijkstra ist für die Routenberechnung in Navigationssystemen viel zu langsam und wird deshalb nicht verwendet; stattdessen nutzt man die heuristisch verbesserte Version, die A*-Suche (A Star). Wie ich nachgesehen habe, ist A* kein SSSP-, sondern ein SPSP-Algorithmus (Single-Pair Shortest Path).
Ich sage das als jemand, der so etwas selbst gebaut hat: Für Personalisierung braucht man eine Informationsmenge von bis zu über 2 Gigabyte.
markitdownist zwar praktisch für die Konvertierung zwischen Formaten, aber bei PDF sollte man es auf keinen Fall verwenden, haha.Für die Dokumentenextraktion gibt es bereits viele Ansätze mit multimodalen LLMs wie Gemini, und auch in Benchmarks schneiden sie ziemlich gut ab. Das Problem sind allerdings die Kosten.
Auch so etwas wie
doclingist gut.Die Funktionen oder der Ansatz wirken ähnlich wie bei Atlas: https://atlasgo.io/
Ich kann den drei zentralen Fallstricken sehr gut nachfühlen. Schon ein einziger Gatekeeper führt oft zu mehreren problematischen Effekten.
Eher niedrigschwellig … wobei … für die Implementierung von Formularen eigentlich schon ein
html-input-Tag reichen würde, man aber unnötig viel über State, JSX sowie unkontrollierte/kontrollierte Komponenten wissen muss und dabei viel Code erzeugt – ich vermute, dass genau solche Punkte die Motivation des Artikels waren.Da ich nicht rauche, wusste ich erst nicht, worum es geht, aber Sie meinen wohl, dass für ein Wegwerfprodukt viel zu viele Ressourcen verbraucht werden.
Die Erhabenheit von Karma -47, lol
Es klingt so, als würde man sagen, die bisherige Methode sei tot, nur weil es nun eine neue Alternative gibt.
Stimmt es wirklich, dass die bisherige Methode nicht mehr verwendet werden kann und man zwingend die neue Methode nutzen muss?
Ich konnte mich mit dem Konzept stark identifizieren und habe es am Wochenende in einem neuen Projekt ein wenig getestet, aber es funktioniert nicht so gut wie gedacht. Es scheint noch einiges an Verbesserungen zu brauchen. Der grobe Ablauf ist zunächst, wie schon mehrfach vorgestellt, folgender:
Verfassung schreiben → Spezifikation schreiben → Tasks schreiben → Implementierung
Das Problem ist:
constitution.mdist zwar der zentrale Leitfaden dafür, "wie entwickelt werden soll", enthält aber nicht, "was diese App am Ende eigentlich sein soll"spec.mdist ein Dokument, das eine einzelne Funktion beschreibt/specifyund/tasakswerden viele Dokumente als Artefakte erzeugt (also genau das gewünschte Ergebnis), aber dadurch wird der Kontext sehr schnell verbraucht (ich nutze Claude Code)tasks.mddefinierten Arbeiten ausführt, überschreibt man mitunter Dinge, die man vorher sauber gebaut hatte, und beim Beheben von Bugs entstehen auch neue Funktionen, sodass man sich immer weiter vontasks.mdentfernt. Ich verstehe nicht, welchen Sinn es hat,tasks.mddauerhaft aufzubewahren.Zu folgendem Fazit bin ich vorerst gekommen:
Hahahahahahahaha
Dem stimme ich sehr zu. Selbst wenn etwas noch so gut gemacht ist, sind Eingriffe störend. Am besten ist es, wenn es wirkt, als wäre es nicht da, und erst dann auftaucht und hilft, wenn man es braucht — entscheidend dürfte dabei sein, wie passend es die jeweilige Situation einschätzt. Auch bei Menschen gibt es solche, die das gut können, und solche, die es nicht können; wenn künstliche Intelligenz das überwinden kann, dürfte das eine Revolution auslösen.
Genauer gesagt ist es bei Vulkan wohl korrekt zu sagen: „Die Vulkan-API, die die iGPU des Pi 5 unterstützt, wird von
llama.cppderzeit noch nicht unterstützt.“ Ich bin auch neugierig, welche Leistung möglich gewesen wäre, wenn das unterstützt worden wäre.doclingist auch gut.Wow! Ein Ultraschallschneider!
markitdown verwendet für das PDF-Parsing https://github.com/pdfminer/pdfminer.six und extrahiert Text oder eingebettete Bilder direkt aus der Datei. Allein beim Gedanken an OCR wird mir schon ganz schwindelig...
Es ist teurer und langsamer als gpt-oss, daher frage ich mich, warum es trotzdem so viele Leute nutzen..
Für alle, die koreanische Prompts brauchen: Hier gibt es ins Koreanische übersetzte Prompts. Mit nur einem Klick werden sie direkt in ChatGPT und Claude eingefügt.
https://gongbuhow.com/posts/chatgpt-students-100-use-cases/
Als ein oder zwei fünfsekündige Werbespots liefen, habe ich sie noch mit dem Gedanken an ein gegenseitiges Miteinander komplett angesehen. Aber als sie mit endlosen aufeinanderfolgenden Anzeigen und Werbung mitten im Video eindeutig zu weit gegangen sind, habe ich sofort einen Adblocker installiert, haha.
Neulich habe ich gesehen, dass es bei civit.ai eine Bounty-Funktion gibt, und dachte zuerst, es handle sich um ein Bug-Bounty-Programm. Aber dort werden Funktionen tatsächlich öffentlich ausgeschrieben, zusammen mit einer Belohnung für die Umsetzung. Ein etwas ungewöhnliches Konzept, fand ich. Wenn man Geld hat, aber intern nicht die nötigen Fähigkeiten, könnte das gar nicht schlecht sein.