Ich wollte vor allem sagen, dass das sehr nach AI klingt und es auch keine Referenzen gibt; daher würde ich es begrüßen, wenn solche Beiträge nicht geteilt würden.
Ich hatte auch sofort an die Kosten gedacht, und offenbar unterscheiden sie sich je nach Auflösung der Eingabebilder tatsächlich stark. Außerdem hatte ich über den Zusammenhang zwischen der Größe der Eingabebilder und der Verarbeitungsgeschwindigkeit überhaupt nicht nachgedacht – das ist wirklich interessant. Wenn man zuschneidet, wird also sogar die Verarbeitung schneller.
Und die Verbesserung der Genauigkeit ist wirklich beeindruckend!
Obwohl die Leistung von VLMs stark besser geworden ist, kommen sie dennoch bislang noch nicht an die Leistung eines YOLO-Modells heran, das für einen einzigen Zweck trainiert wurde?
Vielen Dank, dass Sie Ihre in der Praxis gewonnenen Erfahrungen und Ihr Know-how schriftlich festgehalten haben.
Falls ich auf ein ähnliches Problem stoßen sollte, werde ich mir Ihre Methoden auf jeden Fall als Referenz ansehen.
Das spüre ich in letzter Zeit auch oft..
Ich vermute, dass viele Blogbeiträge nicht mit den eigenen Erfahrungen plus der Hilfe von AI
geschrieben werden.
Die Texte sind einfach zu logisch aufgebaut und zu leicht lesbar.
1) Zweifel an der Glaubwürdigkeit des Textes: riecht nach Marketing/AI-Generat
Kernaussage
„Das ist zu sauber wie ein Lehrstück aufgebaut“ → es entsteht der Verdacht, dass der Text auf Sätze optimiert ist, die HN als ‘Moralstück’ mag
Im Haupttext kleben überall Links zu kostenpflichtigen Materialien, daher war die Stimmung stark: „Ist das am Ende nicht einfach ein Verkaufstext?“
Der exzessive Einsatz von Listen und ein Stil mit Emojis wurden als Signal für „AI slop“ bezeichnet, also hastig herausgepumpter AI-Content
Treffendes Zitat (Übersetzung)
„Wirkt so, als wäre das Ganze nur da, um dir die verlinkten kostenpflichtigen Materialien zu verkaufen. Und mit all den Listen fühlt es sich nach AI slop an.“
(Original: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)
Kurzfazit
Noch vor der Frage, ob der Inhalt stimmt oder nicht, war Reaktion Nr. 1: zu viel Verkaufsgeruch + zu viel AI-Geruch.
2) Kritik an Leadership/Architekt: Das Problem war nicht die Technik, sondern die ‘Entscheidungsstruktur’
Kernaussage
„Ein Architekt in einem Team aus vier Leuten?“ – schon das allein fanden viele ein Warnsignal
Vor allem ein Architekt, der nicht codet, bzw. eine abgetrennte DevOps-Rolle wurde stark als Bottleneck + CV-Optimierung gesehen
Der Tenor war: Nicht Microservices haben die Firma fast ruiniert, sondern eine Struktur, in der niemand Verantwortung für Deployment, Betrieb und Schadensbegrenzung übernimmt
Hartes Zitat (Übersetzung)
„Architekten, deren Job darin besteht, ‘Regeln’ und ‘Patterns’ festzulegen, ohne selbst irgendetwas umzusetzen, sind fast immer eine schlechte Idee. Konzentriert euch einfach aufs Ausliefern. Wenn jemand nicht mal zehn Zeilen Code schreiben würde, aber die Entscheidungen monopolisiert, geht das schief.“
(Original: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)
Kurzfazit
Ziemlich stark war die Sichtweise: Nicht MSA war das Problem, sondern ein Rollendesign mit Entscheidungsmacht ohne Verantwortung.
3) Business-Perspektive: War MSA wirklich die Ursache für das Scheitern des Startups?
Kernaussage
Einige Kommentare glaubten schon das Framing „an der Architektur gescheitert“ grundsätzlich nicht
Das Kernargument: Wenn PMF, Nachfrage und Kundenbindung schwach sind, scheitert man unabhängig vom Stack
Besonders an Details wie „Die Kunden springen ab, weil es zwei Tage langsamer wurde?“ wurde festgemacht, ob das Produkt ursprünglich überhaupt genug Wert hatte
Zudem wurde auf einen inneren Widerspruch des Textes hingewiesen: erst „MSA hat das Startup umgebracht“, dann im Fazit „aber es hat überlebt?“ → Verdacht auf erzählerische Übertreibung
Treffendes Zitat (Übersetzung)
„Ziemlich sicher hat euer Startup ein Produkt umgebracht, das die Leute nicht wollten. Das ist ungefähr so unsinnig wie zu behaupten, Python statt Go habe euer Startup getötet.“
(Original: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)
Kurzfazit
Die Perspektive war klar vorhanden: Architektur könnte nur ein Vorwand sein, und die eigentliche Ursache lag bei Markt, Produkt und Cashflow.
4) Technische Einsichten: Erfahrungsbasierte Ratschläge zu Monolith vs. MSA (der tatsächlich hilfreiche Teil)
Kernaussage
„MSA hat eine Fixkosten-Steuer in Form von Betriebs- und Komplexitätsaufwand“ → für kleine Teams kann das fatal sein, so die Erfahrung vieler
Wichtige Stichworte: Premature distribution (zu frühe Verteilung), modularer Monolith/Modulith, und „Grenzen (boundaries) muss man sich verdienen“
Es wurden auch realistische Bedingungen genannt, unter denen MSA sinnvoll wird: wenn das Team wächst und Konflikte, Deployments oder organisatorische Probleme tatsächlich auftreten
Umgekehrt lautete ein weiterer Rat: Performance- und Skalierungsprobleme nicht reflexhaft mit „MSA“ lösen wollen, sondern zuerst auf Algorithmen, Bottlenecks, Sharding und Partitionierung schauen
Hartes Zitat (Übersetzung)
„Nicht Microservices haben das Startup umgebracht, sondern ‘zu frühe Verteilung’. Ihr habt aufgeteilt, bevor echte Grenzen entstanden waren, und damit nur Latenz- und Abstimmungskosten erzeugt. Fangt mit einem modularen Monolithen an, verdient euch eure Grenzen und extrahiert dann.“
(Original: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)
Kurzfazit
Das war die Lehre, mit der sich die Community tatsächlich identifizieren konnte: „Startet mit einem Monolithen und trennt Services erst dann, wenn Grenzen ‘natürlich’ entstehen.“
Gesamturteil der Community in einem Satz
Den meisten war klar: „Wir sind nicht Netflix“ – gleichzeitig war aber auch der Verdacht stark, dass dieser Text selbst eine Erzählung ist, die genau diese Netflix-Krankheit verkauft (= Marketing/AI).
Die Formulierung „Umwandlung in ein Strukturproblem“ war wohl etwas abstrakt.
Was ich in dem Beitrag sagen wollte, ist:
Before: „Labeling = Personaleinsatz = Kosten proportional zum Aufwand“
After: „Labeling = Pipeline = nach dem initialen Aufbau minimale variable Kosten“
Das heißt, ich habe ein einmaliges Kostenproblem in ein Problem des Systemaufbaus verwandelt.
Die Formulierung „ein neues Arbeitsmodell geschaffen“ trifft es auch!
Genauer gesagt könnte man sagen, dass „menschliche Arbeit durch eine Software-Pipeline ersetzt“ wurde, haha
Hallo, vielen Dank, dass Sie den Artikel mit Interesse gelesen haben!
Ich stimme dem von Ihnen angesprochenen Punkt zu. Dass ein VLM zwar leistungsfähiger als YOLO ist, durch Fehlklassifikationen von YOLO aber wichtige Informationen verloren gehen können, ist ein berechtigter Einwand. Trotzdem haben wir uns aus den folgenden Gründen für einen Crop-Schritt entschieden.
Erstens die Kostenfrage. Wenn man dem VLM das gesamte Bild direkt übergibt, steigen die Kosten durch die Verarbeitung hochauflösender Bilder stark an. Das war der wichtigste Grund für die Einführung des Croppings.
Zweitens die Verarbeitungsgeschwindigkeit.
Um große Datensätze in einer realistischen Zeit zu verarbeiten, war diese Geschwindigkeitssteigerung unverzichtbar.
Drittens die Verbesserung der Genauigkeit.
Cropping erhöht im Gegenteil sogar die Urteilsgenauigkeit des VLM. Ein Gesamtbild enthält oft zugleich komplexe Hintergründe, mehrere Charaktere, Text und Deko-Objekte, wodurch das VLM verwirrt sein kann, welches Objekt es eigentlich beurteilen soll. Es kann zum Beispiel unklar sein, ob es sich um einen Charakter auf einem Poster im Hintergrund, die Hauptfigur als Plüschtier oder einen anderen daneben stehenden Charakter handelt. Mit Cropping hingegen wird nur das Zielobjekt klar isoliert, sodass sich das VLM bei seiner Beurteilung ausschließlich auf dieses Objekt konzentrieren kann.
Natürlich werden Probleme wie übersehene Erkennungen oder False Positives von YOLO dadurch nicht vollständig gelöst. Wir haben dieses Problem jedoch abgeschwächt, indem wir den confidence threshold von YOLO auf 0.5 gesetzt haben, um den Recall zu erhöhen, und anschließend False Positives in den Schritten CLIP-Filtering und Verifier-Validierung herausfiltern. Außerdem konnten wir durch die Verarbeitung großer Datenmengen statistisch genügend hochwertige Daten sichern, selbst wenn es vereinzelt zu übersehenen Erkennungen kam.
Letztlich war das Ziel, einen praktischen Pipeline-Ansatz zu entwickeln, der Kosten, Geschwindigkeit und Genauigkeit in ein ausgewogenes Verhältnis bringt, und der Crop-Schritt hatte in allen drei Punkten einen positiven Effekt.
Hallo winterjung, vielen Dank für Ihr Interesse an meiner Arbeit. Für die Zuverlässigkeit verwende ich den Confidence-Wert, den das VLM (GPT-4o) direkt zurückgibt. Wie Sie erwähnt haben, gibt es die Einschränkung, dass die Grundlage für die Berechnung der Confidence von GPT-4o unklar und nicht reproduzierbar ist. Aus praktischer Sicht habe ich es jedoch so umgesetzt, dass im letzten Verifizierungsschritt (Verifier) auf Basis eines Schwellenwerts entschieden wird, ob eine Verifizierung durchgeführt wird, unter der Annahme, dass die vom VLM zurückgegebene Confidence bis zu einem gewissen Grad korrekt ist.
Ich wusste überhaupt nicht, dass beim Modell got-4o-mini die Tokens für Bildeingaben übermäßig teuer sind. Danke für den Hinweis. Ich habe das sofort im Code berücksichtigt. haha
Ja, dies ist tatsächlich ein Artikel, der die Architektur erklärt, also wie das Produkt aufgebaut ist.
Da es mit Version 1.0 stabilisiert wurde und die Docs aufgeräumt wurden, habe ich die Gelegenheit genutzt, auch den Artikel zu überarbeiten.
Es ist auch eine gute Idee, komplett auf die Sprache C3 umzusteigen. Es ist ein Projekt, das die C-Syntax nur minimal verändert und moderne Funktionen hinzufügt, sodass die Umstellung leichtfällt.
Beim Titel klickt man vermutlich nicht einmal darauf … aber ich fand das einen der interessantesten Texte über die Beziehungen zwischen den USA und China, die ich in letzter Zeit gelesen habe.
Es wird jedes Jahr im November veröffentlicht, aber dieses Jahr teile ich es etwas spät.
Technologieprognosen des Amazon-CTO für die Zeit ab 2025
Technologieprognosen des Amazon-CTO für die Zeit ab 2024
Technologieprognosen des Amazon-CTO für die Zeit ab 2023
Technologieprognosen des Amazon-CTO für die Zeit ab 2022
Ich wollte vor allem sagen, dass das sehr nach AI klingt und es auch keine Referenzen gibt; daher würde ich es begrüßen, wenn solche Beiträge nicht geteilt würden.
Ausgezeichnet ^^
Vielen Dank für Ihre Antwort.
Ich hatte auch sofort an die Kosten gedacht, und offenbar unterscheiden sie sich je nach Auflösung der Eingabebilder tatsächlich stark. Außerdem hatte ich über den Zusammenhang zwischen der Größe der Eingabebilder und der Verarbeitungsgeschwindigkeit überhaupt nicht nachgedacht – das ist wirklich interessant. Wenn man zuschneidet, wird also sogar die Verarbeitung schneller.
Und die Verbesserung der Genauigkeit ist wirklich beeindruckend!
Obwohl die Leistung von VLMs stark besser geworden ist, kommen sie dennoch bislang noch nicht an die Leistung eines YOLO-Modells heran, das für einen einzigen Zweck trainiert wurde?
Vielen Dank, dass Sie Ihre in der Praxis gewonnenen Erfahrungen und Ihr Know-how schriftlich festgehalten haben.
Falls ich auf ein ähnliches Problem stoßen sollte, werde ich mir Ihre Methoden auf jeden Fall als Referenz ansehen.
Das spüre ich in letzter Zeit auch oft..
Ich vermute, dass viele Blogbeiträge nicht mit den eigenen Erfahrungen plus der Hilfe von AI
geschrieben werden.
Die Texte sind einfach zu logisch aufgebaut und zu leicht lesbar.
Hm ... irgendetwas wirkt seltsam.
Ich glaube, dieser Text wurde mit KI geschrieben.
1) Zweifel an der Glaubwürdigkeit des Textes: riecht nach Marketing/AI-Generat
Kernaussage
Treffendes Zitat (Übersetzung)
Kurzfazit
2) Kritik an Leadership/Architekt: Das Problem war nicht die Technik, sondern die ‘Entscheidungsstruktur’
Kernaussage
Hartes Zitat (Übersetzung)
Kurzfazit
3) Business-Perspektive: War MSA wirklich die Ursache für das Scheitern des Startups?
Kernaussage
Treffendes Zitat (Übersetzung)
Kurzfazit
4) Technische Einsichten: Erfahrungsbasierte Ratschläge zu Monolith vs. MSA (der tatsächlich hilfreiche Teil)
Kernaussage
Hartes Zitat (Übersetzung)
Kurzfazit
„Startet mit einem Monolithen und trennt Services erst dann, wenn Grenzen ‘natürlich’ entstehen.“
Gesamturteil der Community in einem Satz
Den meisten war klar: „Wir sind nicht Netflix“ – gleichzeitig war aber auch der Verdacht stark, dass dieser Text selbst eine Erzählung ist, die genau diese Netflix-Krankheit verkauft (= Marketing/AI).
Weil die USA immer noch genug IPv4 haben. Bei uns ist es ja genauso.
iptime-Router unterstützen ja kein IPv6.
Wenn man sich die IPv4-Preise ansieht, kann man nur seufzen, aber ausreichend ist es wohl ...
Es ist brauchbarer, als man denkt, aber weil die Unterstützung durch Drittanbieter auf dem Mac besser ist, nutzt man es am Ende doch nicht .. haha
Vielen Dank für den guten Hinweis!
Die Formulierung „Umwandlung in ein Strukturproblem“ war wohl etwas abstrakt.
Was ich in dem Beitrag sagen wollte, ist:
Before: „Labeling = Personaleinsatz = Kosten proportional zum Aufwand“
After: „Labeling = Pipeline = nach dem initialen Aufbau minimale variable Kosten“
Das heißt, ich habe ein einmaliges Kostenproblem in ein Problem des Systemaufbaus verwandelt.
Die Formulierung „ein neues Arbeitsmodell geschaffen“ trifft es auch!
Genauer gesagt könnte man sagen, dass „menschliche Arbeit durch eine Software-Pipeline ersetzt“ wurde, haha
Hallo, vielen Dank, dass Sie den Artikel mit Interesse gelesen haben!
Ich stimme dem von Ihnen angesprochenen Punkt zu. Dass ein VLM zwar leistungsfähiger als YOLO ist, durch Fehlklassifikationen von YOLO aber wichtige Informationen verloren gehen können, ist ein berechtigter Einwand. Trotzdem haben wir uns aus den folgenden Gründen für einen Crop-Schritt entschieden.
Erstens die Kostenfrage. Wenn man dem VLM das gesamte Bild direkt übergibt, steigen die Kosten durch die Verarbeitung hochauflösender Bilder stark an. Das war der wichtigste Grund für die Einführung des Croppings.
Zweitens die Verarbeitungsgeschwindigkeit.
Um große Datensätze in einer realistischen Zeit zu verarbeiten, war diese Geschwindigkeitssteigerung unverzichtbar.
Drittens die Verbesserung der Genauigkeit.
Cropping erhöht im Gegenteil sogar die Urteilsgenauigkeit des VLM. Ein Gesamtbild enthält oft zugleich komplexe Hintergründe, mehrere Charaktere, Text und Deko-Objekte, wodurch das VLM verwirrt sein kann, welches Objekt es eigentlich beurteilen soll. Es kann zum Beispiel unklar sein, ob es sich um einen Charakter auf einem Poster im Hintergrund, die Hauptfigur als Plüschtier oder einen anderen daneben stehenden Charakter handelt. Mit Cropping hingegen wird nur das Zielobjekt klar isoliert, sodass sich das VLM bei seiner Beurteilung ausschließlich auf dieses Objekt konzentrieren kann.
Natürlich werden Probleme wie übersehene Erkennungen oder False Positives von YOLO dadurch nicht vollständig gelöst. Wir haben dieses Problem jedoch abgeschwächt, indem wir den confidence threshold von YOLO auf 0.5 gesetzt haben, um den Recall zu erhöhen, und anschließend False Positives in den Schritten CLIP-Filtering und Verifier-Validierung herausfiltern. Außerdem konnten wir durch die Verarbeitung großer Datenmengen statistisch genügend hochwertige Daten sichern, selbst wenn es vereinzelt zu übersehenen Erkennungen kam.
Letztlich war das Ziel, einen praktischen Pipeline-Ansatz zu entwickeln, der Kosten, Geschwindigkeit und Genauigkeit in ein ausgewogenes Verhältnis bringt, und der Crop-Schritt hatte in allen drei Punkten einen positiven Effekt.
Hallo winterjung, vielen Dank für Ihr Interesse an meiner Arbeit. Für die Zuverlässigkeit verwende ich den Confidence-Wert, den das VLM (GPT-4o) direkt zurückgibt. Wie Sie erwähnt haben, gibt es die Einschränkung, dass die Grundlage für die Berechnung der Confidence von GPT-4o unklar und nicht reproduzierbar ist. Aus praktischer Sicht habe ich es jedoch so umgesetzt, dass im letzten Verifizierungsschritt (Verifier) auf Basis eines Schwellenwerts entschieden wird, ob eine Verifizierung durchgeführt wird, unter der Annahme, dass die vom VLM zurückgegebene Confidence bis zu einem gewissen Grad korrekt ist.
Ich wusste überhaupt nicht, dass beim Modell got-4o-mini die Tokens für Bildeingaben übermäßig teuer sind. Danke für den Hinweis. Ich habe das sofort im Code berücksichtigt. haha
Wirkt, als würde nur um des Kritisierens willen kritisiert.
Ja, dies ist tatsächlich ein Artikel, der die Architektur erklärt, also wie das Produkt aufgebaut ist.
Da es mit Version 1.0 stabilisiert wurde und die Docs aufgeräumt wurden, habe ich die Gelegenheit genutzt, auch den Artikel zu überarbeiten.
Es ist auch eine gute Idee, komplett auf die Sprache C3 umzusteigen. Es ist ein Projekt, das die C-Syntax nur minimal verändert und moderne Funktionen hinzufügt, sodass die Umstellung leichtfällt.
Das ist wohl ein Begleitartikel zu https://de.news.hada.io/topic?id=25061, den Sie auf ShowGN gepostet haben.
Beim Titel klickt man vermutlich nicht einmal darauf … aber ich fand das einen der interessantesten Texte über die Beziehungen zwischen den USA und China, die ich in letzter Zeit gelesen habe.
Das ist interessant …