タグ: #ai
GPU・LLM・MLOps・Kubernetes、そしてマインドセット · 214 件
みんなのためのAI 第6回 — 111万パラメータの拡散モデルで単語から数字を描く
"zero" と書けば0を描く条件付き拡散モデルを111万パラメータで作りました。ノイズを混ぜる forward は数式1行、復元する reverse はその1行を400回逆にたどるだけです。第5回で L1 損失が色を褪せさせた問題を拡散がどう回避するのか、そしてなぜモデルがノイズを予測するよう学習されるのかを、実際の生成結果で確認します。
2026-08-24 · 15 分で読めます #ai#diffusion#ddpm#generative#pytorchみんなのためのAI 第5回 — 47万パラメータの U-Net で白黒写真に色をつける、そしてなぜ色が褪せたのか
シリーズ最小の47万パラメータ U-Net で CIFAR-10 の白黒画像をカラーに復元しました。形は正確に保たれましたが色が目に見えて褪せています。これはモデルの容量の問題ではなく L1 損失を選んだ結果です。skip connection が何を運ぶのか、そして回帰損失がなぜ彩度を殺すのかを実際の結果画像で確認します。
2026-08-23 · 14 分で読めます #ai#computer-vision#unet#colorization#pytorchみんなのためのAI 第4回 — 137万パラメータで画像に文をつける、そして第3回のバグがここになかった理由
CNN エンコーダとトランスフォーマーデコーダをつないで、Fashion-MNIST の画像にキャプションをつけるモデルを作りました。137万パラメータ、10分の学習でラベル的中率91%です。エンコーダ・デコーダ構造で cross-attention が何をするのか、そして第3回で正解率を7.5%に落とした EOS バグがなぜこのコードになかったのかを、2つの関数を並べて確認します。
2026-08-22 · 12 分で読めます #ai#captioning#multimodal#transformer#pytorchみんなのためのAI 第3回 — 損失0.0017なのに正解率7.5%、犯人はパディング1マスだった
画像と質問を一緒に受け取って答える VQA モデルを148万パラメータで作りました。学習損失は0.0017まで落ちたのに正解率は7.5%。ランダムより悪い数値です。原因はモデルではなく正解を作るコード1行で、直したら99.5%になりました。なぜ低い損失が良いモデルを保証しないのか、その罠をどう見抜くのかを実際の出力で確認します。
2026-08-21 · 14 分で読めます #ai#vqa#multimodal#debugging#pytorchみんなのためのAI 第1回 — 1600万パラメータの言語モデルを15分でゼロから学習させる
GPU 1枚で言語モデルをゼロから学習させます。TinyStories データセットと1600万パラメータのデコーダ専用トランスフォーマーで、15分で読める英語の童話を生成しました。因果マスクがなぜ必要か、重み共有が何を節約するのか、perplexity 8 が実際にどんな文章を意味するのかを、実際の学習ログと生成結果で確認します。RTX 3090 実測。
2026-08-19 · 15 分で読めます #ai#llm#transformer#pytorch#hands-onAIエンジニア会議の英語: 分からないと言いながら信頼を失わない方法
AIチームの会議でいちばんよく必要になる英語は、確信を表す言葉ではなく、不確実性を信頼感をもって表す言葉です。評価結果とその限界を一緒に伝えること、原因がまだ不明な回帰の報告、指標は上がったのに品質は上がっていないとき、ラベリングの意見の相違、コストと遅延のトレードオフ、研究の日程と製品の日程の衝突、非技術の利害関係者への不確実性の説明、他人の実験への異議、再現できないときまで、場面別の表現を整理しました。ヘッジ表現の強さの目盛りと、ア
2026-08-16 · 50 分で読めます #english#business-english#meeting#ai#llmAIツールと働くことを一つの技術として — 委譲の線引きと検証の手順
AIツールをうまく使う、という言い方は、何を委ね、結果をどう判定したかを抜くと何も意味しません。この記事は、委譲の可否を難易度ではなく検証費用で分ける基準、委ねる前に四行で書く委譲カード、結果を受け取ったあと読む順序を変える検証手順、そして生産性がむしろ落ちる四つのパターンを扱います。無作為化対照試験と大規模な開発者調査の数字を引きつつ、その数字が何を語っていないかも書きました。特定の製品の話はしません。高いまま残る技術シリーズの第8回
2026-08-15 · 14 分で読めます #career#skills#ai#verification#engineering-practice私たちが実際に知っていることと知らないこと — キャリア予測の扱い方
エンジニアの将来についての文章は、たいてい二種類です。心配するなという慰めか、いま準備しなければ取り残されるという警告か。どちらも誰にも裏づけられない予測を事実のように語る点で同じ文章です。この記事は観測されたことと予測されたことを切り分けるところから始めます。広く引用された2013年のオックスフォードの研究が実際に何を計算したのか、1964年にもほぼ同じ警告があったこと、そしてこの分野の予測が構造的に外れる理由を見たうえで、わからない
2026-08-15 · 13 分で読めます #career#ai#uncertainty#forecasting#job-security何が高いまま残るのか — 生成が安くなるとき値が上がる四つ
エンジニアはこれから何を準備すべきかという問いに、道具のリストで答えると、その答えは二年で古びます。この記事は別の軸を提案します。値が残る技術とは、検証が高いままの技術だということです。生成コストと検証コストを二軸に置いて四つの枠を描くと、自動化がどこを先に食べ、どこに人が残るのかが一枚に整理されます。この枠組みには反転が一つあります。エンジニアの仕事は検証を高いまま保つことではなく、高い検証を安くする仕組みを設計することであり、その設
2026-08-15 · 13 分で読めます #career#skills#ai#craft#engineering-cultureジュニアがとくに不安な理由 — 入口の階段が変わったということ
ジュニアの不安は性格ではなく位置から来ます。代替可能性を最も指摘される層でありながら、証拠は最も少なく、比較対象は最も多い場所だからです。この記事はAIがジュニアの仕事をするという言葉のどこまでが観測でどこからが予測かを分けたうえで、本当の問題は仕事が消えることではなく、シニアへ上がる階段がまだ設計し直されていないことだと指摘します。そして、その状況で人が学ぶべき順序と、楽な道が階段を自分で消してしまう仕組みを扱います。キャリア不安シリ
2026-08-15 · 12 分で読めます #career#junior-developer#ai#learning#entry-level韓国の開発ブログ名文キュレーション 3 — AIとML実務、直接開いて確認した14本
AIとMLを実務で扱う韓国語記事から、具体的で再現可能な14本を選びました。LangChainによるRAGパイプラインの全工程、埋め込みとベクトル類似度から見た意味検索の原理、ベクトルデータベース7種の比較、pgvectorからQdrantへの移行記録、OllamaからvLLMへ移してスループットを上げた過程、LLMサービングの指標のトレードオフ、使用量トラッカーの自作記、Transformer論文のレビューとコード実装、BERTの整理
2026-08-12 · 24 分で読めます #curation#큐레이션#ai#llm#ragFDE（Forward Deployed Engineer）とは何か — 顧客の現場に配置されるエンジニア
Palantirが生み出し、いまOpenAIとAnthropicが競って採用している職種、Forward Deployed Engineer（FDE）を丁寧に整理します。本社ではなく顧客の現場に配置され、製品と顧客システムの間のラストワンマイルをコードでつなぐ仕事とは何か。ソリューションアーキテクト・セールスエンジニア・コンサルタント・サポートエンジニアとの違いを表で切り分け、未完成のプラットフォームであるほど現場のエンジニアリングが製
2026-08-12 · 11 分で読めます #career#fde#forward-deployed-engineer#ai#job-searchテキスト生成オープンモデルをサイズ別に選ぶ
オープンなテキスト生成モデルを選ぶとき、サイズは性能の等級ではなく配置の制約です。この記事はオンデバイス向けの小型、GPU1枚に載せる中型、サーバが必要な大型に分け、各区分で実際に確認したモデルのパラメータ、コンテキスト、ライセンスを整理し、MoEのメモリ計算がなぜ違うのか、コンテキスト拡張がなぜ無料ではないのか、カードが要求する実行条件を無視すると何が壊れるのかを説明します。オープンモデルガイドシリーズ第2回です。
2026-08-12 · 11 分で読めます #ai#llm#huggingface#open-source-llm#text-generationライセンスと配備: 類型の読み方と量子化配布物の出所確認
オープンモデルのlicenseフィールドに書かれた短い識別子は目次にすぎず、実際の条件は全文にあります。この記事は2026-08-12に実際に出会ったライセンス類型を整理し、コミュニティライセンスと非商用条件が何を求めるのか、ゲートの掛かったリポジトリが配備パイプラインでなぜ問題になるのか、そしてGGUFのような量子化配布物の出所をどう確認すべきかを説明します。オープンモデルガイドシリーズ最終回の第8回です。
2026-08-12 · 12 分で読めます #ai#llm#huggingface#open-source-llm#licenseコードモデルの選び方: 補完と対話、FIM、ライセンス
コードモデルは、エディタ内でカーソル位置を埋める補完用と、質問に答える対話型という別の製品です。この記事は2026-08-12に確認したオープンなコードモデルのパラメータ、コンテキスト、FIM対応の記載、ライセンスを整理し、ベースモデルに対話をさせるとなぜ失敗するのか、コードモデルでライセンスがなぜ特に慎重を要するのかを説明します。オープンモデルガイドシリーズ第7回です。
2026-08-12 · 12 分で読めます #ai#llm#huggingface#open-source-llm#code-llm音声モデルの選び方: STTとTTSの実践基準
音声モデルはテキストモデルと違い、対応言語、音声長の制約、リアルタイム性、話者分離の要否が先に決まり、その後にモデルが決まります。この記事は2026-08-12に確認したSTTとTTSのオープンモデルのパラメータ、ライセンス、対応言語、音声制約を整理し、リアルタイムという語をどう分解すべきか、カードに書かれた幻覚と同意に関する警告がなぜ設計制約になるのかを説明します。オープンモデルガイドシリーズ第5回です。
2026-08-12 · 12 分で読めます #ai#huggingface#open-source-llm#speech-to-text#text-to-speech韓国語に対応するオープンモデルとトークナイザのコスト
韓国語対応という表記は、その言語を処理するという意味であって上手だという保証ではありません。この記事は2026-08-12に確認した韓国語特化・バイリンガル・多言語のオープンモデルのカード値を整理し、トークナイザが韓国語をどう分割するかがなぜそのままコストとコンテキスト消費になるのか、そしてそれを自分で測る方法を説明します。韓国語モデルで特に分かれるライセンス類型も扱います。オープンモデルガイドシリーズ第4回です。
2026-08-12 · 11 分で読めます #ai#llm#huggingface#open-source-llm#korean-nlpビジョンとマルチモーダル: 画像理解、OCR、VLMの選び方
ビジョンモデルはひとつのカテゴリではありません。対話型VLM、OCR専用、文書構造化、画像検索用の埋め込みは別物で、互いを代替しません。この記事は2026-08-12に確認した各カテゴリのオープンモデルのカード値を整理し、解像度や複数画像の扱いといった実際の制約、そしてカードが明記する禁止用途も扱います。オープンモデルガイドシリーズ第6回です。
2026-08-12 · 12 分で読めます #ai#huggingface#open-source-llm#vision-language-model#ocrHugging Faceのモデルカードの読み方: 何を信じ、何を疑うか
Hugging Faceのモデルカードで実際に判断材料になる項目は、ライセンス、パラメータ数、コンテキスト長、intended use、limitations、学習データの6つです。この記事は各項目が何を意味し何を隠すのか、ダウンロード数といいね数がなぜ品質指標にならないのか、そしてカードに書かれていない項目をどう扱うべきかを、2026-08-12に実際に確認したモデルページの事例で整理します。オープンモデルガイドシリーズ第1回です。
2026-08-12 · 12 分で読めます #ai#llm#huggingface#open-source-llm#model-card埋め込みとリランカー、RAGで実際に重要なもの
RAGを作るとき埋め込みモデルの選択を左右するのは、リーダーボードの順位ではなく次元、最大入力長、接頭辞の規約、多言語対応の表記、そしてリランカーとの役割分担です。この記事は2026-08-12に確認した埋め込み・リランカーモデルの実際のカード値を整理し、MTEBのスコアが何を語らないのか、日本語や韓国語の文書を扱うときに何を自分で測るべきかを説明します。オープンモデルガイドシリーズ第3回です。
2026-08-12 · 12 分で読めます #ai#llm#huggingface#open-source-llm#embedding