DeepSeekが視覚対応モデル公開、解像度800×800の制約にHNで賛否
DeepSeekが新しい実験モデル「v4-flash-vision-exp」を公開し、ついに画像入力に対応した。Hacker Newsでは、これまでのテキスト専用モデルが自分に視覚があると勘違いして的外れな処理をしていたという体験談のほか、画像を800×800ピクセル相当に縮小する仕様ではOCRやフロントエンド開発の検証用途には物足りないという指摘が相次いだ。
DeepSeekの新しい実験的モデル「v4-flash-vision-exp」に関するドキュメント
出典: api-docs.deepseek.com / 元記事はこちら
「大きい画像はアスペクト比を保ったまま縮小され、リサイズ後の総ピクセル数はだいたい800×800相当になる」とあるけど、OCRとかいろんな用途にはもう少し解像度が要る。A4用紙まるごと突っ込むケースとか。
DeepSeek v4 Flash 0731は自分に視覚があると思い込んで、実は見えないと気づくとテキストベースの画像解析ツールをでっち上げる、という話をよく聞く。だとしたら今回のアップデートはありがたい。実際自分も0731に「スクリーンショットは見るな」と指示しないと、画像を読もうとしてセッションが壊れてた。
>>4 うちでも3つの別プロジェクトで、ピクセルを解析して視覚を再現しようとしてた。
これでベンチマークが少し上がったらしい: リンク参照
おめでとう!DeepSeekについに目がついた。暗黒時代もこれで終わりだ。
>>6 むしろこれから始まるのかもね。どの人生観を信じるか次第だけど。
みんなこういうモデルの視覚機能を何に使ってる?監視用途はまあ分かるとして、もっと「まともな」使い道ってある?
>>8 HNで一番よく聞くのはフロントエンド開発全般。次に多いのが紙の書類のOCR。
>>8 うちのプロダクトは雇用主と労働者を会話型エージェントでつなぐもの。ユーザーは画像でのやり取りが大好きで、履歴書、書類、現場の写真とか。履歴書やオファーを写真で送る形式もかなり人気。普段使いのDeepseek Flashはその写真が見えないから、画像モデルを別に使ってエージェントに文脈を理解させてる。
>>8 エージェント型のグラフィックデザインツールを作ってるので、モデルが自分の作業結果を確認するのに視覚がかなり役立つ。テキストオンリー版と比べてもう改善を感じてる。
興味深い。DeepSeekの創業者は、マルチモーダルには注力しないと明言して、テキストオンリーだけでAGIに到達できると考えていたんじゃなかったっけ?
>>10 それを言ってたのはDarioで、しかも画像生成についての話だったと思う。
800×800は64万ピクセル、0.64メガピクセル。1995年のSuper VGA(約0.79メガピクセル)より低い。それなりの用途には使えるけど、分水嶺になるのはその3倍くらい、1080p相当だと思う。それなら小さい文字や細かいディテール以外はほぼ何でもいける。
>>11 でもツールを使えるモデルなら、クロップやズームのツールを使って自分が見えていると思ったものを検証するはずでは。
>>11 自分は普段小さいスクリーンショットをLLMに渡してるから、この用途なら問題なさそう。画面全体を渡すと多くのLLMが混乱するみたいだし。
これオープンウェイトで出る?
>>12 たぶん彼らの「Thinking with Visual Primitives」論文がベースになってて、その論文ではウェイトを公開すると書かれてたはず
>>12 出ると思う。オープンにするのはDeepSeekの一貫した伝統だから
>>12 自分もそこ知りたい。もし出ないとしたら、自前でホストしてるdeepseek flashに視覚機能を後付けする良い方法を知ってる人いる?
>>2 うわ、800×800だと使えない用途が結構出てくるな
>>13 それでも案外大丈夫かも。最近のvLLM勢は、細部が見えないと判断すると、システムにあるImageMagickやPILなんかを勝手に使って部分画像を切り出し「ズームイン」する。
>>13 実験版だからという可能性もある。正式版でもっと大きい入力を許すようになっても驚かないし、いずれ出るpro版でそうなるかもしれない。
>>13 「flash」の速さを取るか細部を取るか。どっちか一つ。
>>3 分割して食わせればいいのでは?
>>14 それはそれで難しくて、どこで分割するか判断するのは?
>>31 少なくともいくつかの言語では、テキストは行(と段落)ごとに分かれて書かれていることが多いし。
>>31 分割自体をモデルにやらせればいい。その判断をするだけなら800×800pxの画像で十分足りるはず。
>>17 フロントエンド開発?ちょっとピンとこない。作業中のウェブページをモデルに解析させてるってこと?それともテスト用?
>>32 開発ループを完結させるため。視覚がないと、モデルは自分が作ったものが見た目通りに表示されてるか確認できず、推測するしかない。
>>32 もちろんQA用。エージェントにCDP経由で本番プロダクトへのアクセスを与えて、スクリーンショットを撮らせて結果を確認させる。FigmaにCDPで読み書きアクセスさせるやり方もあって、そこでも視覚モデルはかなり役立つ。
>>32 OMPで視覚モデルを使う定番の流れは、フロントエンドのコードを書いて、サーバーを立ち上げて、ヘッドレスブラウザでスクリーンショットを撮って確認し反復すること。これがすごくうまくいく。でもDeepSeek V4 Flashを使ってると、代わりに毎回「ページを読み込んで自分で確認してください」と言われる。
>>17 でもOCRにはもっと向いたモデルがあって、自分はmlx-community/PaddleOCR-VL-8bitを使ってる
>>33 時には元の「誤字」をそのまま残したいこともあれば、逆に「直して」ほしいこともある。OCR専用モデルはだいたいどちらか一方しかできなくて、VLMの場合は「直す」方に寄りがち。マルチモーダルLLMなら指示するだけでいい(ただしちゃんと従うかはモデルごとに評価が必要だけど)。
>>26 普通はこんな感じで視覚モデルをMCPサーバーとして追加すればいい: リンク参照
>>30 Geminiの「flash」モデルにはメディア解像度のオプションがあって、スクリーンショット用の高解像度オプションもある。
>>36 値段はどのくらい?
>>31 分割する時に少し重ねればいいのでは?
>>31 その部分は小さくて安いモデルにやらせればいいんじゃない?
>>35 それだと文脈を失わない?特に0とO、1とI、1とl、Iとlみたいに見分けにくい文字の組み合わせがあるフォントだと。
>>46 そこはグリッドクロップで対応するはず。その段階でディテールは保持されて、そのあと低解像度の全体画像を参照しながら論理的に再結合される。ただ最低でもトークン消費は2倍になる。
※本記事は5ch(Hacker News)スレッド「DeepSeek-v4-flash-vision-exp」より抜粋・要約して構成しています。
まだコメントはありません。