はてなブックマーク

久しぶりに、Railsについて「設定より規約だなぁ」という発言を目にして、「規約よりアノテーションがいいし、AIに不利」みたいなツッコミをしたわけです。 ということで、どのようにAIに不利かまとめてみます。 一応、いまのRailsについてはAIがかなり学習しているので、Opusなどではかなり的確に扱えているようです。 なので「AIに扱えるようにならない」という意味ではないです。 規約ベースのフレームワークとは ここでは例えばmodelフォルダの下にUserという名前のクラスを作るとusersというテーブルへのマッピングになる、というような規約の話です。 アノテーションベースであれば、Userというクラスに@Tableというアノテーションを付けるとuserというテーブルへのマッピングになります。ただ、ここでUserというクラスがuserというテーブルに対応するというところは規約ベースになって

NVIDIAから新しいモデル、Nemotron 3 Nanoが出ていました。30BのMoEでアクティブパラメータは3B。つまり30B-A3Bです。 試してみたら、かなり賢いんだけど、コーディングの長いやりとりをしてたら過去のコードをうろ覚えになってて変な挙動をしてました。 どうやら、Transformerの代わりに使ってるMamba 2だとそういう挙動になるみたい。自信がないので、こうやって書いたら、だれかが間違いを指摘してくれるはずメソッド。 追記：30Bモデルの主戦場になるのは、言語処理的な単機能部品だと考えると、長いやり取りは不要なので、かなり強いモデルではないかと思います。また別にブログかきます。たぶん。 Nemotron 3 Nemotronはこちらにブログが。 Inside NVIDIA Nemotron 3: Techniques, Tools, and Data That

LLMにやさしいSui言語が話題だった。 で、「ヤサシクナイヨ」とか書いてたのだけど、それならSui言語にやさしいLLMを作ってみるのはどうか。 LLMにやさしい言語SuiはLLMにやさしくなさそう - きしだのHatena まあ、ファインチューンという金槌を持ってウロウロしてるところにSui言語という釘を見つけたので打ってみましょう、ということで。 データセットを作る 最初はCodeNetのコードをSuiに変換してデータセット作ろうかと思ったのだけど、Suiで書くにはちょっとコードが複雑すぎるのでやめた。 簡単な問題をChatGPTに作ってもらう。 整理して80件になった。まあデータセットとしては少なすぎるけど、今回は小さいモデルを学習させるだけなのでどうにかなるはず。(追記：どうにかならなかった・・) そしてgpt-oss-120bにコードを書いてもらう。 コードはここ。「さくらのAI

LLMにやさしい言語という謳い文句の言語、Suiが話題。 けどこれ、LLMにあまりやさしくなんじゃなかろうか。 https://github.com/TakatoHonda/sui-lang 9月にこういうエントリを書いてます。 AI専用のプログラミング言語は現れない - きしだのHatena ここで理由として挙げたのは、この4点です。 すでにAIは独自の言語を持っている 低レベルな記述にはコストがかかる 意味の記述が必要であることに変わりはない 作っても学習させるのが大変 この4点にあてはまっていると思います。 追記: あと、こういうことも10月に書いてます。 AIが読み書きするコードも読みやすいほうがいい(トランスフォーマの特性の考慮やリーダブルコードについて追記) - きしだのHatena 去年の4月ですが、こういうことも書いてました。 AIがコードを書くようになるなら、AIだけに理

SB Institutionから日本の情報に特化した画像言語モデル、Sarashina-2.2-Vision-3Bが出ていたので試したところ、性能の高さは感じたものの、VRAM 16GBで動かすのがつらかったのでまとめました。 Sarashina2.2-Vision-3B: コンパクトかつ性能が高いVLMの公開 - SB Intuitions TECH BLOG ※ use_cache=Trueつけたら解決！12GBで動きそうです。追記しています。 GradioでのUI とりあえず、いろいろ試すたびにコードいじるのは面倒なので、gradioでUIをつけました。 ChatGPTに「gradioで、画像と短文を入力したら長文が返ってくるシステムのUIを作りたい。実際の処理はこちらで書くので、generate_text(intput_txt, image_pil)関数がある前提で画面構築のスクリ

情報を右から左に流すだけのIT土管はAIに作れるので、その情報たちから新たな価値を生むのが、ITエンジニアの仕事になるのではないかなと思います。 2004年に広まったWeb 2.0は、CGM(Consumer Generated Media: ユーザー生成コンテンツ)という言葉を生みました。 それまでは、広く共有されるコンテンツというのはマスコミのような一部の集団がつくってメディアに一方的に流すものでした。Web 2.0では、ブログやSNS、写真、動画共有など、一般消費者がアップロードしたコンテンツが、広く共有されるようになりました。 日本でも、はてなやmixi、pixiv、ニコニコ動画のようなサービスが始まりました。 こういったサービスは、結局のところ、ユーザーが入力したデータを他のユーザーに表示させる、いわば IT土管 になっています。 それでも、2015年くらいまでは、多数が同時に投

Spring AIからはデフォルトでLM Studioに接続できませんが、reactor-netty-httpへのdependencyを追加することで接続できるようになります。 この解決方法です。 https://github.com/spring-projects/spring-ai/issues/2445#issuecomment-3066995797 まずOpenAIをdependencyに加えたプロジェクトを作成します。 application.propertiesに接続用の設定を記述します。api-keyは本来不要ですが、無いとエラーになるのでtempにしておきます。 spring.ai.openai.base-url=http://localhost:1234/ spring.ai.openai.api-key=temp spring.ai.openai.chat.option

Mac Studioを借りたのでいろいろクソデカ言語モデルを試したところ、GLM-4.5-Airがいいなとなってます。 試したモデルこちら。 モデル パラメータ数 アクティブ thinking 画像 時期 URL GPT-oss 120B 120B 5B o x 2025/8 OpenAI hf link Qwen3 235B-A22B-2507-thinking 235B 22B o x 2025/8 Alibaba hf link Qwen3-VL 235B-A22B-thinking 235B 22B o o 2025/9 Alibaba hf link Qwen3-Next-80B 80B 3B o x 2025/9 alibaba hf link Qwen3 Coder 480B 480B 35B x x 2025/7 alibaba hf link Qwen3 Coder 30

DeepSeek-OCRの仕組みが面白いので遊んでしまっている。 最初に試したときは、純粋にOCRさせてますね。きれいな心をしている。 画像でテキストをトークン圧縮するDeepSeek-OCRがいろいろすごい - きしだのHatena そして前回はランダムな文字列を読ませて誤認識を誘ってみた。 DeepSeek-OCRにはランダム文字列が読めない - きしだのHatena もう２つ、弱点ぽいところをついてみる。 その前に、DeepSeek-OCRの構造を確認。 https://arxiv.org/abs/2510.18234 ここで、DeepEncoderがSAM->Conv->CLIPってなってるのがキモ。 SAM(Segment Anything Model)は、画像の領域分けをする仕組み。 GitHub - facebookresearch/segment-anything: The

DeepSeek-OCRの精度が高くて驚いたところですが、仕組み的にランダムな文字列での認識率がかなり落ちるんではないかと試してみたところ、やっぱりかなり悪かったです。 DeepSeek-OCRについてはこちら。 画像でテキストをトークン圧縮するDeepSeek-OCRがいろいろすごい - きしだのHatena DeepSeek-OCRは、画像をトークン化したほうがテキストをトークン化するより情報圧縮できるんでは、というアイデアを試すために、トークン化した画像をテキストに戻してみたらOCRとして精度があがった、というものです。 ここで、「画像のほうが情報量が多いのにトークン化したら容量増えるのでは？」ってなりますが、情報量が多いのは画像を画像として復元する場合で、画像についてお話するために必要十分な情報としてであればそこまで多くならないはずです。 テキストのトークン化は、よくある文字の並び

おとといくらいにDeepSeek-OCRというのが出てました。 https://github.com/deepseek-ai/DeepSeek-OCR ただのOCRじゃなくて、「テキストを画像にしたほうがトークンサイズを小さくできるのでは？」というのをやっていて、テキストを画像にしてトークン化したものをテキストトークンに戻すというのをやってたらOCRになったという感じですね。 LLMの開発効率化に革新？ 中国DeepSeekが「DeepSeek-OCR」発表 “テキストを画像化”でデータ圧縮：Innovative Tech（AI+） - ITmedia AI＋ 中身的には、3Bでアクティブパラメータが0.6BのMoEモデルに0.4Bの画像エンコーダーを載せた画像言語モデルです。 導入や使い方は、モデルのページに書いてあります。 何も考えずに最新のTransformers 4.57.1を入れ

AIが読むんだから読みやすくする必要はないんでは、という話が流れてきた。 けど、実際にはAIにも読みやすさは大事だと思う。 データ形式によって、そのデータに関する回答精度がどうかわるかという調査がある。 Which Table Format Do LLMs Understand Best? (Results for 11 Formats) HTMLまでの上位5形式はキーワードによってレコードが区別される。JSON以降は記号や改行によってレコードが区別される。また、上位４形式ではキーと値が一緒に書かれる。 このように、表現形式でAIによる読み取りの精度は変わる。GPT-4.1-nanoなので失敗しやすいということはあるだろうけど、どう書いても同じというわけではない。 OpenAI公式のGPT-5コーディングチートシートでも、構造はMarkdownよりXMLがいいと書いてあるし。というか、恐ら

AIが賢くなると、AIにわかりやすく人間には理解困難なプログラミング言語が出てくるのでは、みたいな話をよく聞きます。 ただ、次の点から、AI専用の言語は現れないだろうなと思います。 意味の記述が必要であることに変わりはない すでにAIは独自の言語を持っている 低レベルな記述にはコストがかかる 作っても学習させるのが大変 意図の記述が必要であることに変わりはない プログラムを書くときには、「ここを3回繰り返そう」とか「この一連の処理の塊を、この部分だけパラメータで変更可能にしつつまとめよう」とか「xとyをまとめて扱うようにしよう」といった意図をもって処理を書きます。そうすると、その意図が直接書ける言語のほうがいいです。 また、ここでは整数だけ扱うとか、文字列を扱うとか、xとyをまとめたデータを扱うとか、そういったデータ内容を明示すると、プログラムが失敗しにくくなるだけではなく理解もしやすくな

PLaMo翻訳のGGUFをmmngaさんが公開されています。 https://huggingface.co/mmnga/plamo-2-translate-gguf PLaMo翻訳のプロンプトは次のような指定をする必要があります。 <|plamo:op|>dataset translation <|plamo:op|>input lang=English Write the text to be translated here. <|plamo:op|>output lang=Japanese で、plamo-2-translate-ggufには次のようなプロンプトテンプレートが設定されています。 これ、LM StudioのチャットUIで使うにはいいのだけど、APIで使おうとするとうまく動かせません。 ということで、手動にしてEmptyに。 そうするとこんな感じのクラスを用意すればPLaM

AIとやりとりしてると、こんな感じでさっきのバグを再現してしまって「アホか！」って暴言吐きたくなることありますね。 で、このエントリのときに、こういうチャットは捨てて やりなおしたほうがいいと書きました。 AIに激詰めしてしまうのはAIだからじゃなく、そのくらい言わないとわからなそうだから - きしだのHatena なんでそうなるかというと、まずトランスフォーマーのアテンションという単語ごとの関係を見る仕組みがあります。 で、バグコードが続くとき、非常に雑にアテンションを書くとこんな感じで、間違ったコードを強調しあってしまうのですね。どのくらい注目してるか、というのを書いてます。 / / 結構 たくさん / 結構 / 結構 / たくさん 結構 / アテンションではそのトークンが否定されたかどうかをあまり気にできないので、こうなると、トランスフォーマーさんはこの方向のコードが大事なので似たよ

AIプログラムの開発、つまり、AIにコードを書かせるのではなくて、LLMを呼び出したりRAGを実装したりエージェントを作ったりといったAIを組み込むプログラミングの演習をしたいときに、参加者のPCに十分なリソースを前提とできないことは多いと思います。 Java AIプログラミング記事でQwen3 1.7B Q4_K_Mを選んだ 先月gihyo.jpの連載で、「JavaでAIプログラミングをはじめよう」という記事を出しました。 「JavaでAIプログラミングをはじめよう」という短期連載をgihyo.jpで出しました - きしだのHatena そのときに、読者のPCにGPUが載ってたりMacであることだったりは前提にできないので、なるべく必要なリソースが少ないモデルを選ぶ必要があって、最終的にQwen3 1.7BのQ4_K_Mを選びました。初回に、LM Studioとあわせた導入方法を載せてま

CerebrasがQwen3 Coderのホストをして2000tok/secを出してるという話があって、試したいなぁと思ってたのですよ。 Qwen3 Coder 480B is Live on Cerebras ただ、$50/monや$200/monの定額プランは早々に売り切れ。 けど、1M tok/dayまで無料という噂を聞いて、使ってみることにしました。 で、以前つくった雑なエージェントを試す。 Tool Useが効かないDevstralでコーディングエージェントを作る - きしだのHatena そしたら、3秒でSpring BootでのTODOアプリが！これ、ほんとにこの速さで生成してます。 といいつつ実際に計測すると2000tps出ないんでは、とか思ってたら逆で、2600tok/sec出ていました。 いま、Claude Sonnet 4は70tpsくらいですね。 https://o

GoFの「デザインパターン」の「終わりに」という章の「終わりに」という項は次のようになっています。 もっとも良い設計は、全体がたくさんのデザインパターンをぴったりとつなぎ合わせて、組み合わせてできているものである GoFのデザインパターンのコンセプトは、パターンのカタログを提示することだけではなくて、その構成を使って多くのパターンを見出してほしいというものでした。 けど、名前をつけてカタログ化するほどのパターンは、コンピュータの高性能化とネットワークの普及に応じて変化したソフトウェアアーキテクチャを整理したものが多く粒度が大き目で、GoFのデザインパターンの想定した粒度のようなものはあまり共有されいません。 実際のところパターンは数多くあるものの、粒度が小さく変化も大きく、デザインパターンとして名前をつけて整理をして共有するのが難しい。 そうすると、Erich Gammaのいう「全体がたく

みなさん、AIコーディングしてますか？そうですよね、やってますよね。 みなさん、AIに激詰めしてますか？罵声あびせてますか？やってますよね。 「おめーは何回いえばわかるんだ」みたいなことを、そんなこと書いても意味ないとわかってるのにやってしまいますよね。 ぼくは性格が悪いので、嫌味をいいがちです。 まあ、そうするとキレ気味に「お疲れさまでした！」って言ってくるので、AIかわいい。 これはGPT-4oだったけど、Claude Sonnet 4に聞き直して解決しました。GPT-5ならちゃんと目的完遂できたかもしれません。 で、生身の人間には言わなそうなことを口走ってしまうことも多いわけですね。 でもこれ、「相手がAIだから何をいってもいい」っていうことじゃないように思います。さっきも書いたとおり、AIってわかってれば、そんなこと言っても意味ないことがわかるはず。 そうではなくて、ここまでのやり

llama.cppにMoEに適したCPU/GPUの振り分けのオプションが入って、LM Studioでもそのオプションに対応したことによって、MoEモデルであるGPT-ossが少ないGPUメモリでもそれなりに動くようになりました。拡大するとわかりますが、LM Studioの右下の表示によると、メインメモリは12GBくらい使います。 14tok/sec出ています。 CPUだけで動かすと10tok/secだったので、5割マシですね。 0.3.23.0に「Force Model Expert weight onto CPU」というスイッチが入っているので、これをOnにするとExpertのウェイトがすべてCPUに乗るようになります。アテンションはGPUで。 詳しくはリリースノートにありますが、llama.cppの--n-cpu-moeの仕組みを使ってるとのこと。 https://lmstudio.a

GPT-5が出ましたね。コーディング能力もめっちゃあがってる！みたいなことが書いてあるので、いろいろ試してみました。 開発者向け GPT-5 のご紹介 | OpenAI 結論を書いておくと、GPT-5のコーディング能力は確かにあがってSonnet 4と同等くらいになってるけど、ChatGPTというサービスがコーディングツールとして使い物にならなくなっていました。 チャットUIでコード書くならClaude。 マリオ なんかマリオができるという話だったので、やってみました。 javaのswingでリアルなマリオのようなゲームを作って。 1ソースで完結して。 背景もかわいいほうがいい。 だいぶいいですね。背景かわいいし、スコア表示もゲームっぽい。 GPT-4oではこうだったので、かわいさが増してます。敵もコインもなくジャンプするだけのゲームだったし。 ちなみにSonnet 4。敵を踏んで潰すのも

技評さんのサイトで「JavaでAIプログラミングをはじめよう」という短期連載をやってました。 LLMを動かして接続してRAGやMCPも組んでひととおりやってみるという連載になってます。 JavaでAIプログラミングをはじめよう 記事一覧 | gihyo.jp ● 初回は、LM Studioを使ってQwen3 1.7Bをローカルで動かしてHttpClientで呼び出すという、準備的な回。 今ならGPT-oss 20Bでもいいかもしれないけど、Qwen3 1.7Bのほうがどんな環境でも動くんじゃないかと思います。 JavaでLLMにアクセスしてみよう | gihyo.jp ● 第2回は、定番ライブラリのLangChain4jを使うという回。 LangChain4jを使ってみよう | gihyo.jp ● 第3回はFunction CallingとRAGです。 ちなみに、技評さんのサイトでダウン

OpenAIのオープンモデルが来ました。 120Bと20B。どちらもMoEで、アクティブパラメータはそれぞれ5.1B、3.6Bです。 そして4bit浮動小数点での量子化があるので、120Bは80GBのVRAM、20Bは16GBのVRAMで動きます。 Introducing gpt-oss | OpenAI LM Studioで動かす。早い！速い！ LM Studioに即来ていました。早い！ 最新版にしてllama.cppも更新が必要です。 追記: 0.3.22-b1で正式にgpt-ossに対応したようです。記事を書いた時点での0.3.21-b4では対応が不完全だったらしい。 起動時にgpt-oss-20bのダウンロードを勧めてきますね。 ということで、RTX4060 Ti 16GBで動かしました。71token/sec！速い！ 17000トークンまでならVRAMに載りそう。 送信時にRea

Qwen3のアップデートがいろいろ出ていて、ベンチマークですごい結果を出したりしています。 けど、実際に使うと全然そんな性能が出てる気しないです。 これたぶん、コンテキストが長くなったときの性能劣化が激しいんじゃないかと思います。 なので、ベンチマークや、ちょっとプロンプト一発投げて返答を見ると性能よさそうに見えるんだけど、実際に使うとダメということになるんだと思います。 Qwen3 30Bアップデートとコーディングモデル Qwen3のアップデートは、先日の235Bに続いて、30B-A3Bのnon-thinkingモデルと、それをベースにしたコーディングモデルが出ていました。 Qwen/Qwen3-30B-A3B-Instruct-2507 · Hugging Face Qwen/Qwen3-Coder-30B-A3B-Instruct · Hugging Face 235Bについては、な

いまだにオブジェクト指向とか言ってるのか、という話ですが、いまだに「プログラミングの勉強はじめました。オブジェクト指向が目標です！」みたいなのがThreadsに流れてきたりして、いつまでも無くならんなぁと思うわけですよ。 で、まあオブジェクト指向を勉強してしまいたくなるのは仕方がないとして、オブジェクト指向推しの本でのサンプルがだいたいヒドいのが問題だなと思ったわけです。 アプリケーションを見据えていない オブジェクト指向の例として、自転車クラスだとか勇者クラスだとか定義するサンプルをみかけます。 自転車クラスを作る例の場合、車輪クラスがありサドルクラスがありペダルクラスがあり、ブレーキクラスはブレーキシュークラスやブレーキキャリパークラスを内包するな、みたいなことをやりますね。JSONでやれ。 という感じで、単にJSONなど構造データのマッピングになりさがってたりします。 あと、現実の写

去年くらいに作ったRAGなどAI関連のシステムを、単に今年4月のモデルに差し替えるだけで性能向上した、というのはいろいろなところであるように思います。 コーディングエージェントが、一部先進的な人だけではなく広く使われだしたのも、2月のClaude 3.7や5月にClaude 4による性能向上があってこそだと思います。 ただ、こういった、モデルを差し替えるだけでなんでも性能向上するというのは終わりつつある気がします。 2004年ごろまで続いたCPUのクロック向上が終わって、CPUを差し替えるだけで何でも性能向上する時代が終わったときに「フリーランチは終わった」と言われました。マルチコアによる並列化で性能を出すようになると、コードを並列対応に書きかえないと性能があがらなくなります。 同様に、AIも「フリーランチは終わった」になりつつあるんじゃないでしょうか。 「フリーランチは終わった」というの