「全体がリンク先の有料資料を売るために作られたように見える。リストだらけでAI slopっぽさがある。」
（原文: 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.）
「実際に何も実装しないのに“ルール”だの“パターン”だのを決めるアーキテクトは、ほぼ常に悪手だ。とにかく出荷に集中しろ。コードを10行も書かない人間が意思決定を独占すると失敗する。」
（原文: 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...）
「スタートアップを殺したのは、人々が欲しがらない製品を作ったことだろう。PythonかGoかでスタートアップが死んだと言うのと同じくらい筋が通らない。」
（原文: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...）
「スタートアップを殺したのはマイクロサービスではなく、『早すぎる分散』だ。本物の境界が生まれる前に分割してしまい、レイテンシと調整コストだけを払うことになった。モジュラーモノリスから始めて、境界を稼ぎ取ってから切り出すべきだ。」
（原文: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.）
少しは支援もしつつ……最近使っているんですが、面白いです。
Cをやっていて不便だった点だけを改善しようとしている感じで、そこがいいですね。
公式ドキュメントはまだあまり成熟しておらず、
（あれこれ機能を調べようとすると、思いがけない場所に書かれていることが多いです……）
StackOverflow の将来が気になる
Excalidraw は本当に素晴らしいです
さあ、これでMSA狂信者たちが押し寄せてきます
では、上に挙げられたサイトの記事を翻訳して提供するサービスを...
要約を分かりやすく読ませていただきました。ありがとうございます。
Hacker News に投稿された記事です。私が投稿する記事の大半は Hacker News に掲載された内容です。
https://news.ycombinator.com/item?id=46469845
おっしゃる通りです……。Hacker News の参照元を載せるようにしますね。
毎年11月に上がってくるのですが、今年は共有が少し遅れましたね。
Amazon CTOの2025年以降の技術予測
Amazon CTOの2024年以降の技術予測
Amazon CTOの2023年以降の技術予測
Amazon CTOの2022年以降の技術予測
私が言いたかったのは、あまりにもAIっぽく、参考資料もないので、このような文章は共有しないでほしいという意見です。
素晴らしいです ^^
ご回答ありがとうございます。
私もコストの問題が気になっていたのですが、やはり入力画像の解像度によって費用が大きく変わるのですね。さらに、入力画像のサイズと処理速度の関係はまったく考えていなかったので興味深いです。クロップすると処理速度まで速くなるのですね。
そして、精度向上には本当に驚きました！
VLMの性能はかなり向上しましたが、それでもまだ、単一の目的のために学習されたYOLOモデルの性能は超えられないのでしょうか？
実際の現場で得られたノウハウを文章として残してくださり、ありがとうございます。
私も似たような問題に出会ったら、使われていた方法をぜひ参考にしてみます。
私も最近よく感じることですが..
多くのブログの記事は、本人の経験 + AIの助けを借りて
書いているのではないかと推測しています。
あまりにも文章が論理的で、読みやすく書かれているので。
うーん…何かおかしい気がします。
この記事、AIで書かれたようですね。
1) 文章の信頼性への疑い: マーケティング/AI生成物っぽい臭いがする
要旨
痛烈な引用（翻訳）
ひとこと評
2) リーダーシップ/アーキテクト批判: 問題は技術ではなく『意思決定構造』だった
要旨
痛烈な引用（翻訳）
ひとこと評
3) ビジネス観点: スタートアップ失敗の原因は本当にMSAだったのか？
要旨
痛烈な引用（翻訳）
ひとこと評
4) 技術的洞察: モノリス vs MSA の経験ベースの助言（本当に役立つ部分）
要旨
痛烈な引用（翻訳）
ひとこと評
「モノリスで始めて、境界が“自然に”生まれたときだけサービスを分離しろ。」
コミュニティ総評ひとこと
「私たちはNetflixではない」には大半が同意していたが、同時に「この文章自体が“Netflix病”を売り込むための物語（=マーケティング/AI）かもしれない」という疑いも強かった。
米国ではまだ十分な IPv4 があるからです。韓国もそうです。
iptimeルーターはIPv6をサポートしていませんよね
IPv4の価格を見るとため息しか出ないのに、十分だなんて…
思ったより実用的ですが、サードパーティー対応はMacのほうが優れているので、結局使わなくなりますね..（笑）
ご指摘ありがとうございます！
「構造問題への転換」という表現は、やや抽象的だったかもしれません。
私が記事でお伝えしたかったのは、
Before: "ラベリング = 人手投入 = コスト比例"
After: "ラベリング = パイプライン = 初期構築後は変動費を最小化"
つまり、一回限りのコスト問題をシステム構築の問題に変えた、ということです。
「新しい作業モデルを作った」という表現もその通りです！
より正確には、「人の労働をソフトウェアパイプラインで置き換えた」と言えるかと思います（笑）
こんにちは、記事を興味深く読んでいただきありがとうございます！
ご指摘の点には共感します。VLMがYOLOより高性能である一方、YOLOの誤判定によって重要な情報が失われる可能性があるという点は、その通りです。ただ、以下の理由からクロップ工程を入れました。
1つ目はコストの問題です。VLMに画像全体を直接入力すると、高解像度画像の処理によってコストが急激に増加します。これがクロップを導入した最大の理由でした。
2つ目は処理速度の問題です。
大規模データセットを現実的な時間内で処理するには、このような速度向上が不可欠でした。
3つ目は精度の向上です。
クロップはむしろVLMの判断精度を高めます。画像全体には複雑な背景、複数のキャラクター、テキスト、装飾品などが一緒に含まれているため、VLMがどのオブジェクトを判定すべきか混乱することがあります。たとえば、背景のポスターにいるキャラクターなのか、メインのぬいぐるみなのか、隣にある別のキャラクターなのかが明確でないケースが生じます。一方でクロップを使えば対象オブジェクトだけを明確に分離できるため、VLMはそのオブジェクトのみに集中して判断できるようになります。
もちろん、YOLOの見逃しや誤検出の問題が完全に解決されるわけではありません。しかし、YOLOのconfidence thresholdを0.5に設定してrecallを高め、その後のCLIPフィルタリングとVerifierの検証段階で誤検出を除外する形で、この問題を緩和しました。また、大規模データを処理しているため、一部に見逃しが発生しても、統計的には十分な量の高品質データを確保できました。
結果として、コスト・速度・精度のバランスが取れた実用的なパイプラインを構築することが目標であり、クロップ工程はこの3つの側面すべてで良い効果をもたらしました。