NEGABARO AI
AI/MLの核心コンセプトをまとめた技術百科事典
🧱 基礎
ニューラルネットワーク
ニューロンを模倣したコネクショニスト学習モデル
入力データを複数の層（layer）の重みで変換し、逆伝播（backpropagation）で誤差を減らしていく学習方式
Transformer
Self-Attentionベースの並列処理アーキテクチャ
「Attention Is All You Need」 — RNNの逐次処理の限界をSelf-Attentionメカニズムで解決し、入力シーケンス全体を並列処理するアーキテクチャ
AI前処理の難易度 — テキスト、画像、オーディオ、ビデオ、3Dの順に難しくなる
model(input)は1行だが、そのinputを作る前処理は分野ごとに全く違う
AIは全部model(input)→outputだが、inputを作る前処理の難易度が分野ごとに違う。テキスト（トークン化=ルックアップ）が最も簡単で、画像（リサイズ+正規化）、オーディオ（STFT+メル）、ビデオ（フレーム抽出+時間軸）、3D（点群+ボクセル）の順に難しくなる。AI勉強を始めるならテキストから。
テキストAI事前学習モデルカタログ — 3行コードでできる12のこと
感情分析からコード生成まで — HuggingFace pipeline 1行で済むモデルリストと難易度
テキストは前処理がトークン化（ルックアップテーブル）だけでAI入門に最適。HuggingFace pipelineで感情分析、翻訳、要約、質疑応答、テキスト生成、コード生成、NER、類似度比較など12種を3行コードで実行可能。タスク別推薦モデル、サイズ、難易度を整理。
HuggingFace pipeline() — AIモデルのnpmが動く仕組み
Hubに100万以上のモデルが登録され、pipeline()が名前で自動ダウンロードし推論まで行う
HuggingFace HubはAIモデルのnpmだ。誰でもモデルをアップロードでき、pipeline()が名前だけで重み・トークナイザー・設定を自動ダウンロードする。テキスト、オーディオ、画像、ビデオ — タスク名を変えるだけで同一インターフェースで100万以上のモデルを使える。
ラップAIモデルカタログ — 歌詞生成、ライム検出、フロー分析まで
GPT-2ラップファインチューニングモデル + pronouncingライム分析 + 実行可能コード全部
HuggingFaceにラップ歌詞生成モデルが複数ある。GPT-2をラップ歌詞でファインチューニングしたモデルをpipeline()で直接実行でき、pronouncingライブラリでライム検出・音節分析も可能。歌詞生成→ライムチェック→フロー分析まで全部コードでできる。
🏋️ トレーニング
プレトレーニング（事前学習）
大規模データで汎用知識を学習する段階
インターネット規模のテキストデータで次トークン予測（Next Token Prediction）を繰り返し、言語の文法・事実・推論能力などの汎用知識を習得する過程
ファインチューニング
事前学習モデルを特定タスクに合わせて再学習
Pre-trainedモデルの重みを特定ドメインやタスクのデータで追加学習し、汎用モデルを専門家モデルに変換する過程
RLHF
人間フィードバックに基づく強化学習
Reinforcement Learning from Human Feedback — 人間の評価者がモデル応答をランク付けし、この選好データで報酬モデルを学習した後、強化学習（PPO）でモデルを整列させる方法
DPO（Direct Preference Optimization）
報酬モデルなしで直接選好最適化
RLHFの複雑な強化学習パイプライン（報酬モデル＋PPO）を省略し、選好データでLLMを直接更新する簡素化された整列技法
LoRA（Low-Rank Adaptation）
少数のパラメータのみ学習する効率的なFine-tuning
元モデルの重みを固定し、低ランク（low-rank）行列2つを追加して少ないパラメータでFine-tuning効果を出す技法。GPUメモリを大幅に節約
推論 vs ファインチューニング — 他人のモデルを使うことと自分のモデルを作ることの違い
pipeline()は出前注文、ファインチューニングはレシピを受け取って自分の味に調整すること
推論は他人が訓練したモデルをそのまま使うこと。ファインチューニングはそのモデルを自分のデータで再訓練して自分のモデルを作ること。ゼロから訓練するのではなく、すでによく訓練されたモデルをベースに微調整するだけなので、ノートPCのGPU1つでもできる。感情分析がファインチューニング入門に最適。
世界一シンプルなファインチューニング理解 — 合体ではなく調整だ
66M個の数字を少し変えること。データをモデルに注入するのでも、モデル同士を合体するのでもない
ファインチューニングはデータをモデルに合体することでも、モデル同士を足すことでもない。完成済みモデルの重み（66M個の数字）を自分のデータを見せながら微調整すること。大学卒業生にOJTを施すようなもの — 教科書を読み直すのではなく、既存の知識の上に新しい業務を教えること。
LoRA — 66M個を全部変えず、1M個のアダプターだけ挿す
ファインチューニングの効率的代替 — ベースモデルは固定し、小さい行列2つだけ訓練
ファインチューニングは66M個の数字を全部調整する。LoRAはベースモデルを凍結し、横に小さいアダプター（1M個）だけ訓練する。品質は同等で訓練時間・メモリ・保存容量が大幅に減る。スマホにケースを付けるようなもの — 本体を変えるのではなくケースだけ交換。
RAG — モデルを再訓練せず「参考資料」を添付する方法
検索（Retrieval）+ 生成（Generation）— モデルの重みは変えず外部知識をプロンプトに添付
RAG（Retrieval-Augmented Generation）はモデルの重みを一切変えない。代わりに質問が来たら関連文書を検索してプロンプトに添付してからモデルに渡す。試験にオープンブック参考資料を持ち込むようなもの。ファインチューニングと違い、データが変わったら文書を更新するだけ。
モデルマージ — 本当に2つのモデルを「合体」する唯一の方法
韓国語モデル+コーディングモデル=韓国語でコーディングするモデル？重みの平均で合体
モデルマージはAIで唯一「合体」に該当する技法だ。2つのモデルの重みを平均して1つにする。韓国語モデルとコーディングモデルを合わせると韓国語でコーディングするモデルになるかもしれない。訓練なしで合体するのでGPUも不要。ただし実験的で結果は保証されない。
⚡ 推論
プロンプトエンジニアリング
プロンプト設計でLLMの能力を最大限引き出す
LLMに最適な入力（プロンプト）を設計して望む出力を誘導する技術。モデルの重みを変えずに入力だけで性能を最大化
RAG（検索拡張生成）
検索で外部知識を注入して精度向上
LLMが回答を生成する前に、関連文書をベクトルDBから検索（Retrieval）してプロンプトに添付し生成（Generation）する方式。学習データにない最新/専門知識も活用可能
Chain-of-Thought（CoT）
段階的推論で複雑な問題を解決
LLMに「ステップバイステップで考えよう（Let's think step by step）」と指示し、中間推論過程を明示的に生成させるプロンプティング技法。数学、論理、コーディング等の複雑な問題で性能が大幅向上
Function Calling（ツール利用）
LLMが外部ツールを呼び出して実際の作業を実行
LLMがテキスト生成の代わりに構造化された関数呼び出し（JSON）を出力し、外部API/DB/計算機等のツールを実行して結果を活用する機能。AI Agentの核心メカニズム
📈 スケーリング & 最適化
量子化（Quantization）
モデルの重みを低精度に変換して軽量化
FP32（32ビット）やFP16（16ビット）で保存されたモデル重みをINT8（8ビット）またはINT4（4ビット）に変換し、モデルサイズとメモリ使用量を1/2〜1/8に削減する最適化技法
知識蒸留（Knowledge Distillation）
大型モデルの知識を小型モデルに伝達
大きなモデル（Teacher）の出力分布（soft label）を小さなモデル（Student）が模倣するよう学習させ、小型モデルが大型モデルの性能に近づく技法
Mixture of Experts（MoE）
必要な専門家のみ活性化して効率的スケーリング
1つの巨大なモデルの代わりに、複数の専門家（Expert）ネットワークの一部のみ活性化して処理する構造。全パラメータは大きいが実際の計算は一部のみ実行
投機的デコーディング（Speculative Decoding）
小型モデルで予測草案を作成し大型モデルが検証
高速な小型モデル（Draft Model）が複数トークンを一度に生成し、低速な大型モデル（Target Model）がまとめて検証/修正して推論速度を2〜3倍向上させる技法
🎨 マルチモーダル
🤖 エージェント & ツール活用
AIエージェント
LLMが自律的に計画しツールを使用してタスクを実行
LLMを「脳」として、計画策定→ツール呼び出し→結果観察→次の行動決定を繰り返し、複雑なタスクを自律的に実行するシステム
MCP（Model Context Protocol）
AIと外部ツールを接続する標準プロトコル
Anthropicが公開したオープンプロトコルで、AIモデルと外部ツール（DB、ファイル、API）を標準化された方式で接続。USB-Cのように「一つの規格で全てのツール」を接続
評価駆動開発（Eval-Driven Development）
評価（Eval）ベースでAIシステムを反復改善
プロンプト、モデル、RAGパイプライン等の変更が性能に与える影響を自動化された評価（Eval）で測定し、データに基づいて改善する開発方法論
🛡️ 安全性 & アラインメント
AIアラインメント（整列）
AIを人間の意図と価値観に合わせて動作させる
AIシステムが人間の望む通りに行動することを保証する研究分野。「役に立ち（Helpful）、無害で（Harmless）、正直な（Honest）」システムを目標とする
Constitutional AI（CAI）
憲法（原則）でAI自身を改善させる方法
Anthropicが開発したアラインメント技法。人間が直接フィードバックする代わりに、AIに「憲法（原則）」を与えて自ら応答を批判・修正させ、RLHFの人的労働を大幅に削減した方法
ハルシネーション（幻覚）
AIが事実ではない内容をもっともらしく生成する現象
LLMが学習データにない、または事実ではない情報を自信を持って生成する現象。次トークン予測という学習方式の本質的な限界に起因する
🎙️ 音声 & オーディオAI
オーディオトークン化（Neural Audio Codec）
オーディオを離散トークンに変換してLLMのように処理
連続的なオーディオ波形をVQ-VAEベースのコーデック（EnCodec、SoundStream等）で離散トークンシーケンスに変換し、テキストのようにTransformerで生成・理解できるようにする技術
音声モデルの進化
ルールベース → ディープラーニングパイプライン → トークンベース → 統合マルチモーダル
音声合成（TTS）技術の発展史: 第1世代（ルール/連結合成） → 第2世代（統計的パラメトリック） → 第3世代（ディープラーニングメルスペクトログラムパイプライン） → 第4世代（トークンベースLLM方式） → 未来（統合マルチモーダル）
GPT-SoVITS 実践分析
Pre-trainingとFine-tuningが実際のコードでどう動作するか
GPT-SoVITSオープンソースプロジェクトを通じてPre-training（事前学習）とFine-tuning（微調整）が実際のコードでどう実装されるか分析するケーススタディ
Demucsコード分析 — 1つの曲をボーカル・ドラム・ベース・ギターに分離する方���
Meta/Facebook ResearchのHybrid Transformerソース分離モデル — アーキテクチャ、推論パイプライン、実践活用
DemucsはMeta（Facebook Research）が作ったオープンソース音源分離モデルだ。完成した1曲をボーカル、ドラム、ベース、ギター（other）の4ステムに分離する。現行バージョンhtdemucsは時間ドメインエンコーダー・デコーダーと周波数ドメインTransformerを組み合わせたハイブリッドアーキテクチャだ。
Mel-Band RoFormer Karaokeモデル分析 — リードボーカルだけを抽出する913MBの秘密
RoPE + メルスケール周波数分解 + 階層的時間・周波数Transformer — コードと設定まで
UVRコミュニティのaufr33+viperxが訓練したMel-Band RoFormer Karaokeモデルは913MBのPyTorchチェックポイントだ。リードボーカルのみ分離しバッキングボーカルは伴奏に残すカラオケ専用モデル。60個のメルバンドで周波数を分解し、時間・周波数軸を交互に処理する階層的Transformerが核心。SDR 10.1956。
UVR Mel-Band RoFormer vs Demucs — 音源分離モデル比較分析
カラオケ専用2ステム vs 汎用4ステム — アーキテクチャ、学習データ、性能、実践選択基準
最もよく使われる2つの音源分離モデルの比較。UVR Mel-Band RoFormer Karaokeはリードボーカルのみ分離する913MBカラオケ専用モデル、Demucs htdemucsはボーカル・ドラム・ベース・ギターの4ステムに分離する80MB汎用モデルだ。用途が違う。
音源分離2分ガイド — DemucsとUVR Karaokeをローカルですぐ実行する
実測ベース比較 — インストール、実行、処理時間、出力ファイルまで実際に動かした結果
DemucsとUVR Karaokeをローカルで直接インストールして動かした。Demucs：pip install 1行＋実行1行、モデル80MB、10秒音声を10秒で処理。UVR Karaoke：モデル913MB、同じ音声を43秒で処理。簡単なのはDemucs、カラオケ品質はUVR。
オーディオAIの共通基盤技術 — Demucs、Mel-Band RoFormer、GPT-SoVITSが共有するもの
STFTスペクトログラム、Transformerアテンション、エンコーダー・デコーダー、PyTorch — オーディオAIの共通DNA
音源分離（Demucs、Mel-Band RoFormer）と音声合成（GPT-SoVITS）は目的が違うが基盤技術が同じだ。STFTでオーディオを周波数ドメインに変換し、Transformerで長距離依存性を捉え、エンコーダー・デコーダーで分解/復元する。この共通DNAを理解すればオーディオAI全体が見える。
オーディオAI Hello World — 事前学習モデルで5分でやる7つのプロジェクト
pip install 1行+コード3行で音源分離、音声認識、TTS、ピッチ検出、音楽生成まで
訓練なし、GPUなし、コード3行でオーディオAIを体験できる。音源分離、音声認識、TTS、ピッチ検出、音楽タギング、音分類、音楽生成 — 全部事前学習モデルをダウンロードしてすぐ動かすだけで結果が出る。
input → 事前学習モデル → output — AI推論の本質はこの1行だ
STFTもマスキングも忘れろ — モデルがやることはただ一つ、入力を受けて出力を出すこと
オーディオAIパイプラインでSTFT、マスキング、ISTFTは全部数学だ。ニューラルネットがやることはただ1行 — model(input)でoutputを出す。音源分離、音声認識、TTS、音分類、全部この構造だ。
📄 OCR & ドキュメントAI
OCRオープンソースカタログ — 画像からテキストを抽出するすべての方法
TesseractからEasyOCR、PaddleOCR、Surya、TrOCR、Qwen2-VLまで — 難易度・言語・速度比較
OCRは完全にニューラルネットワーク分野だ。画像→model(image)→テキスト。最も簡単なEasyOCR（3行、80言語）からCJK最強PaddleOCR、最新高精度Surya、TransformerベースTrOCR、マルチモーダルLLM（Qwen2-VL）まで整理した。
PDF特化OCR — 複雑なレイアウト・表・数式をMarkdownに変換するツール
Marker、Docling、MinerU、Nougat、olmOCR — PDFをLLMが読める形に
通常のOCRは画像からテキストを抽出するが、PDFはより複雑 — 多段レイアウト、表、数式、コードブロック、ヘッダー/フッター。PDF特化ツールはこの構造を理解しMarkdown/JSONに変換する。RAGパイプラインの最初のステップとして必須。
契約書・法律文書特化OCR — 条項抽出、当事者識別、構造化
Legal-BERT + LayoutLMv3 + CUADデータセットで契約書を構造化データに変換
契約書OCRはテキスト抽出自体より「抽出したテキストから何を取り出すか」が核心。OCR（テキスト抽出）→Legal-BERT（法律言語理解）→条項分類・当事者識別・期限抽出。CUADデータセット（500契約書、41ラベル）でファインチューニング可能。
日本語特化OCR — 漫画、縦書き、ふりがな、古文書まで
manga-ocr、Sarashina2.2-OCR、PaddleOCR、KuroNet — 日本語OCRのすべての選択肢
日本語OCRが難しい理由：縦書き、ふりがな、ひらがな・カタカナ・漢字混在、漫画特有のフォント。manga-ocr（漫画専用）、Sarashina2.2-OCR（日本語文書最高精度）、PaddleOCR（汎用CJK）、KuroNet（古文書/くずし字） — 用途別推薦。
OCRファインチューニング入門 — 日本語不動産契約書を読む自分のモデル作り
TrOCR + Trainer.train() — 感情分析ファインチューニングと全く同じパターン
OCRファインチューニングは感情分析ファインチューニングと構造が同じ。inputがテキストから画像に変わっただけで、Trainer.train()でモデルの重みを調整するのは同一。TrOCR（ViTエンコーダー+テキストデコーダー）が最も簡単 — HuggingFace標準インターフェースそのまま。
OCR APIカタログ — モデル管理なしAPI 1行でテキスト抽出
Google Vision、Azure Document Intelligence、AWS Textract、Clova OCR — 価格・精度・コード比較
モデルをインストール・管理せずAPI呼び出しだけでOCRできる。Google Cloud Vision（精度最高）、Azure Document Intelligence（契約書・レシート特化）、AWS Textract（表構造化に強い）、Naver Clova OCR（韓国語最強） — コード例と価格を比較した。
日本語契約書OCRベンチマーク — API vs オープンソース、どちらが良いか
Google Vision、Azure、PaddleOCR、Sarashina2.2 — 日本語契約書で精度・速度・価格比較
日本語不動産契約書を基準にAPI（Google Vision、Azure）とオープンソース（PaddleOCR、Sarashina2.2-OCR、manga-ocr）の性能を比較する。精度：Google Vision≈Sarashina2.2 > PaddleOCR > Azure > EasyOCR。コスト：オープンソース0円 vs API ページ課金。
OCR総合比較 — API vs オープンソース vs ファインチューニング、何を使うべきか
3つのアプローチの精度・コスト・セキュリティ・難易度・保守を1枚で比較
OCRを実装する3つの方法：API呼び出し（Google Vision等）、オープンソースセルフホスティング（EasyOCR、PaddleOCR等）、ファインチューニング（TrOCR、manga-ocr）。精度・コスト・セキュリティ・難易度・保守の5軸で比較すると状況により最適な選択が変わる。
Azure Document Intelligence専用モデル全整理 — レシートから契約書まで15モデル
prebuilt-read、prebuilt-receipt、prebuilt-contract、prebuilt-invoice — モデル名を変えるだけで構造化データが出る
Azure Document Intelligenceは単なるOCRではない。文書タイプ別専用モデルが15以上ある。レシートを入れると店名・日付・金額が、名刺を入れると名前・肩書・電話番号が、契約書を入れると当事者・管轄・条項が構造化JSONで出る。モデル名を変えるだけ。
文書構造化抽出API比較 — Azure、Google、AWSそれぞれ何を提供するか
Azure prebuilt-contractのような「文書を理解するAPI」はGoogleとAWSにもある？
Azureのprebuilt-contractのように「文書タイプ別にフィールドを構造化抽出するAPI」はGoogle（Document AI）とAWS（Textract）にもある。ただし対応文書タイプ、言語、価格が全部違う。Azureは専用モデルが最も多く、Googleはカスタムプロセッサが強く、AWSは表抽出に特化。
📏 評価 & 検証
AIモデル評価入門 — 自分のモデルが良いかどうやって分かる？
正解率、BLEU、CER、SDR — タスクごとに異なる評価指標と「なぜこれを使うのか」
モデルを訓練したら評価が必要。だがタスクごとに評価方法が違う。分類は正解率、生成はBLEU、OCRはCER、音源分離はSDR。全部1つの数字に帰結 — 高いほど良いか、低いほど良いか。
タスク別評価チートシート — どの指標を使うべきか一目で
分類→Accuracy/F1、生成→BLEU/ROUGE、OCR→CER/WER、分離→SDR — コード付き
タスクによって使う評価指標が違う。このチートシートで自分のタスクに合う指標を選び3行コードですぐ測定できる。
AI評価ツールカタログ — evaluate、lm-eval-harness、RAGAS、DeepEval
単一指標測定からLLMベンチマーク、RAG評価、自動テストパイプラインまで
単純な指標測定（evaluate）からLLMベンチマーク（lm-eval-harness）、RAGパイプライン評価（RAGAS）、AIアプリテスト（DeepEval）まで — 評価ツールも用途別に違う。