RAG

GPUなしで毎秒100ページ以上のPDF→Markdown変換を実現するオープンソースツール「OpenDataLoader PDF」が話題になっている。Apache 2.0ライセンスで完全無料、CPUのみで動作するため、高価なGPUハードウェアは不要だ。 OpenDataLoader PDF とは OpenDataLoader PDF は、PDFドキュメントをAI活用に適した構造化データ（Markdown、JSON、HTML等）に変換するオープンソースのパーサーだ。Java で実装されており、Python・Node.js・Java から利用できる。 主な特徴: 超高速処理: ローカルモードで 0.05秒/ページ（CPUのみ）、8コア以上のマシンでマルチプロセスバッチ処理すると毎秒100ページ以上 GPU不要: CPUだけで高速に動作するため、導入コストが低い 高精度: ベンチマークで総合精度0.90を達成し、読み順・テーブル・見出し抽出で1位 Apache 2.0ライセンス: 商用利用可能な完全オープンソース インストール Python パッケージは Java CLI のラッパーのため、Java 11以上とPython 3.10以上が必要だ。 1 2 3 4 5 # Python pip install -U opendataloader-pdf # Node.js npm install @opendataloader/pdf Java の場合は Maven で opendataloader-pdf-core を依存関係に追加する。 基本的な使い方 Python でのシンプルな変換 1 2 3 4 5 6 7 import opendataloader_pdf opendataloader_pdf.convert( input_path=["file1.pdf", "file2.pdf", "folder/"], output_dir="output/", format="markdown,json" ) フォルダを指定すれば一括変換も可能だ。出力形式は Markdown、JSON、HTML、プレーンテキスト、注釈付きPDFから選べる。 ...

社内資料をRAGで検索しているのに「欲しい情報に限って見つけてくれない」「関係ない文書ばかり読んで的外れな回答をする」という経験はないでしょうか。AIDB が紹介する新しいRAG手法は、検索方法そのものをモデル自身に判断させるというアプローチで、この問題に正面から取り組んでいます。 従来RAGの限界：一本調子の検索 従来のRAGはシンプルです。あらかじめ決まった方法（主にベクトル類似度検索）で文書チャンクを引っ張ってきて、まとめてLLMに渡す。検索がハズれたら、その時点でもう正解にはたどり着けません。 どんなに優れたモデルを使っても、読む資料がズレていれば回答の質は上がりません。問題は「LLMの能力」ではなく「検索戦略の固定化」にあります。 3つの検索戦略を状況に応じて使い分ける この新手法では、モデルが以下の3つの検索戦略から最適なものを選択し、必要に応じて組み合わせます。 検索戦略 特徴 向いているケース キーワード検索 特定の語句・コードをピンポイントで探す 固有名詞、型番、コマンドなどを調べるとき 意味検索（セマンティック検索） 意味的に近い文書を探す 概念的な質問、言い換えが多い文書を扱うとき チャンク全文読み 対象範囲を丸ごと読み込む 文脈が重要な長文、前後関係が必要なとき 重要なのは、どの順番で、どの検索を使うかをモデル自身が推論して決定する点です。固定のパイプラインではなく、質問の性質や文書の構造に合わせて動的に戦略を切り替えます。 なぜこれが機能するのか 読み込むテキスト量は同等以下 従来のRAGと比較して、読み込むテキストの量は同等かそれ以下です。にもかかわらず、回答精度は大きく向上します。これはトークン数の節約にもつながります。 モデル進化と共にスケールする構造 この手法の特筆すべき点はモデルの推論能力と性能が比例することです。モデルの推論能力が高いほど、「どの検索を、どの順番で使うか」という判断精度が上がり、RAG全体の性能が向上します。 つまり、将来より優れたモデルが登場すれば、RAGのフレームワーク自体を改修しなくても自然に性能が底上げされます。 実装への示唆 この手法を自社のRAGシステムに取り入れる場合、以下の点が設計のポイントになります。 1. 検索ツールの整備 モデルが選択できるよう、複数の検索エンドポイントを用意する必要があります。BM25（キーワード）、ベクトルDB（意味）、ドキュメント取得（全文）の3種を揃えるのが基本構成です。 2. ツール呼び出し（Function Calling）の活用 OpenAI / Anthropic / Google などの主要LLMはFunction Callingをサポートしています。検索戦略の選択をFunction Callingで実装することで、モデルが自律的に検索を制御できます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 tools = [ { "name": "keyword_search", "description": "固有名詞・型番・コマンドなど特定のキーワードで文書を検索する", "parameters": {"query": "string"} }, { "name": "semantic_search", "description": "意味・概念の近さで関連文書を検索する", "parameters": {"query": "string"} }, { "name": "read_document", "description": "指定した文書チャンクを全文読み込む", "parameters": {"document_id": "string"} } ] 3. 推論能力の高いモデルを選ぶ ...

Google が 2026年3月に公開した Gemini Embedding 2 は、テキスト・画像・動画・音声・ドキュメントを同一のベクトル空間に埋め込める、初のネイティブマルチモーダル埋め込みモデルだ。RAG パイプラインやマルチモーダル検索を構築する開発者にとって注目すべきモデルとなっている。 主な特徴 ネイティブマルチモーダル対応 従来の埋め込みモデルはテキスト専用か、別モデルで画像を処理する必要があった。Gemini Embedding 2 は全モダリティを 3072次元の統一ベクトル空間 に直接埋め込む。これにより、テキストで検索して関連する画像や動画を取得するといったクロスモーダル検索が自然に実現できる。 対応モダリティと制限: モダリティ 制限 テキスト 最大 8,192 トークン 画像 1リクエストあたり最大 6枚（PNG, JPEG） 動画 最大 120秒（MP4, MOV） 音声 ネイティブ対応（テキスト変換不要） インターリーブ入力にも対応しており、1つのリクエストに画像とテキストを混在させて渡すことができる。 Matryoshka 表現学習（MRL） Matryoshka Representation Learning（マトリョーシカ表現学習）により、重要な意味情報がベクトルの先頭次元に集約される設計になっている。デフォルトの 3,072次元から 1,536 や 768次元に切り詰めても、検索品質の大部分を維持できる。 Google の推奨次元数: 3,072次元：最高品質 1,536次元：高品質（コスト削減向け） 768次元：バランスの良い推奨値 768次元に切り詰めた場合でも、同サイズの固定次元モデルを上回る性能を発揮するとされている。 多言語対応と性能 100以上の言語をサポート MTEB 多言語リーダーボードで 69.9 を記録しトップランク MTEB コード検索でも 84.0 と高スコア 料金 プラン 料金 リアルタイム API $0.20 / 100万トークン バッチ API $0.10 / 100万トークン（50% OFF） OpenAI の text-embedding-3-small（$0.02/100万トークン）と比較すると高価だが、マルチモーダル対応を単一モデルで実現している点が差別化要因となる。 ...

ローカルで Ollama + Qwen を動かしている Mac Studio（M3 Ultra / 96GB）に、NAS 上の PDF やテキストなどのドキュメントを学習させて「個人の知識ベース」として活用したい——そんなとき、ファインチューニングと RAG のどちらを選ぶべきかを整理する。 やりたいこと NAS に蓄積された個人ドキュメント（PDF、テキスト等）の知識を Qwen に覚えさせたい 自分の PC を使った活動に関する知識を、AI が把握している状態にしたい 選択肢1: ファインチューニング（QLoRA） モデル自体の重みを更新し、知識を「記憶」させるアプローチ。 Mac Studio での実現可能性 M3 Ultra / 96GB 統合メモリなら、QLoRA でのファインチューニングは技術的に可能。 手法 必要メモリ目安（7B） ツール QLoRA (4bit) 6-8 GB Unsloth, LLaMA-Factory, MLX LoRA (16bit) 14-16 GB LLaMA-Factory, PEFT フル FT 60+ GB 非現実的 Apple Silicon では MLX ベースが最もパフォーマンスが良い。 1 2 3 4 5 6 7 8 9 10 # MLX での QLoRA 実行例 pip install mlx-lm mlx_lm.lora \ --model Qwen/Qwen2.5-Coder-14B-Instruct \ --data ./training_data \ --train \ --batch-size 1 \ --lora-layers 16 \ --iters 1000 ファインチューニングの課題 最大のボトルネックはデータ準備。NAS の生ファイルはそのまま学習データにはならず、instruction 形式への変換が必要になる。 ...

Agentic AI 学習ロードマップ — 「フルスタックインテリジェンス」を9ヶ月で習得する体系的な道筋 @ingliguori 氏（Giuliano Liguori）のポストが、Agentic AI を学ぶためのロードマップを共有しています。 Roadmap to learn Agentic AI: AI fundamentals → Python + frameworks → LLMs → Agents architecture → Memory + RAG → Planning & decision-making → RL & self-improvement → Deployment → Real-world automation Agentic AI = full-stack intelligence. 「Agentic AI = フルスタックインテリジェンス」というフレーズが示すように、AI エージェントの開発には基礎数学からデプロイまで、フルスタックの知識が求められます。本記事では、このロードマップを複数の学習リソースと照合しながら、各段階で何を学び、どのツールを使い、どこまでを目指すのかを体系的に解説します。 ロードマップの全体像 Liguori 氏が示した9ステップを、Scaler の9ヶ月ロードマップと roadmap.sh の AI Agents ロードマップを参考に、時系列で整理します。 月0-1 AI Fundamentals ← 数学 + ML 基礎 月1-2 Python + Frameworks ← API + ライブラリ 月2-3 LLMs ← Transformer + プロンプト 月3-4 Agents Architecture ← ReAct + ツール使用 月4-5 Memory + RAG ← ベクトル DB + 検索拡張 月5-6 Planning & Decision ← 計画 + マルチエージェント 月6-7 RL & Self-improvement ← フィードバック + 自律性 月7-8 Deployment ← MLOps + 監視 月8-9 Real-world Automation ← ポートフォリオ + 実案件 Step 1: AI Fundamentals（月0-1） 学ぶこと 分野 具体的な内容 線形代数 ベクトル、行列演算、固有値分解、SVD 微積分 勾配、偏微分、最適化 確率・統計 ベイズの定理、分布、仮説検定 ML 基礎 教師あり/なし学習、評価指標 推奨リソース Khan Academy — 数学基礎 “Mathematics for Machine Learning”（書籍） StatQuest — 統計の直感的理解 この段階のゴール 「なぜニューラルネットワークが動くのか」を数学的に説明できること。数式を書ける必要はないが、勾配降下法やベイズ推論の直感を持つことが重要です。 ...

Agentic AI の周期表 — 66 要素で読み解く AI エージェント構築の全体像 @ingliguori（Giuliano Liguori）氏のポストが話題になっています。 Agentic AI now has its own “Periodic Table”. From: LLM, RAG, RL to PLAN, MAS, LTM to SAFE, HUMAN oversight to HR, MKT, LEGAL use cases. Autonomous AI = memory + planning + tools + safety + collaboration. It’s a system, not a prompt. Capital One の Chief Scientist である Prem Natarajan 氏が、AI エージェント構築に必要な 66 の要素を化学の周期表のように体系化した「Agentic AI Periodic Table」を公開しました。LLM や RAG といった基盤技術から、メモリシステム、安全性プロトコル、業務適用まで、エージェント開発の全領域を一枚の表に凝縮しています。 ...

コンテキストエンジニアリング — AI を「使う人」と「使いこなす人」の違い 紹介ポスト: えいと @7_eito_7 「AIを使っている人と、本当にAIを使いこなしている人の違いは何か。結論はコンテキストエンジニアリングができるかどうか。簡単に言えば、指示の出し方ではなくどんな文脈を渡しているか。」 はじめに 2025年半ば、Shopify CEO の Tobi Lütke が次のように発言した: 「“プロンプトエンジニアリング"より"コンテキストエンジニアリング"という言葉の方がずっと好きだ。LLM がタスクを解決できるだけの十分な文脈を与える技術 — これこそが核心的スキルだ。」 AI 研究者の Andrej Karpathy もこれに同意し、「コンテキストエンジニアリング」という概念は一気に広まった。2026年現在、プロンプトエンジニアリングの時代は終わり、コンテキストエンジニアリングが AI 活用の新しい標準になりつつある。 プロンプトエンジニアリング vs コンテキストエンジニアリング 観点 プロンプトエンジニアリング コンテキストエンジニアリング スコープ 1つの入力テキストの書き方 モデルが見る情報の全体設計 焦点 指示の言い回し・構造 情報の選択・順序・形式・量 対象 単発の質疑応答 複雑な推論、マルチターン、エージェント 複雑さ 文章レベル システムレベルのパイプライン 例え 「質問の仕方を工夫する」 「解答に必要な教科書・資料・道具を揃える」 プロンプトエンジニアリングはコンテキストエンジニアリングの一部にすぎない。質問の質ではなく、AI に渡す情報の質と構造が結果を決める。 なぜプロンプトだけでは不十分なのか よくある問題: RAG で正確な情報を取得し、プロンプトも丁寧に書いた。それでも AI がハルシネーションを起こす。 原因はプロンプトでも検索でもなく、コンテキストの構造にある。 プロンプトの 3 つの限界 情報不足: 質問は完璧でも、判断に必要な背景情報が足りない 情報過多: 関連情報を全部詰め込むと、かえって精度が落ちる（ノイズに埋もれる） 情報の無秩序: 重要な情報とそうでない情報が区別なく並んでいる コンテキストエンジニアリングは、この 3 つを体系的に解決する。 コンテキストエンジニアリングの 4 つの柱 1. 構成（Composition）— 何を渡すか タスクに必要な「材料」を選択する: ...

App Store Connect スクリーンショットの仕様 アップデート ✓ Built IPA to build/ios/ipa (46.7MB) To upload to the App Store either: 1. Drag and drop the “build/ios/ipa/.ipa” bundle into the Apple Transporter macOS app https://apps.apple.com/us/app/transporter/id1450874784 2. Run “xcrun altool –upload-app –type ios -f build/ios/ipa/.ipa –apiKey your_api_key –apiIssuer your_issuer_id”. See “man altool” for details about how to authenticate with the App Store Connect API key. xcrun altool での apiKey と apiIssuer の取得方法 xcrun altool を使用して App Store Connect にアプリをアップロードする際に、apiKey と apiIssuer の値が必要になりますね。これらの値は、App Store Connect で API キーを作成することで取得できます。 ...

ColPali arXiv アーカイブ 記事 ColPali： PaliGemma-3B と ColBERT ストラテジーに基づくビジュアルレトリバー ColPali: Efficient Document Retrieval with Vision Language Models テキスト抽出不要の RAG を実現する ColPali

RAG 【勉強メモ】RAG But Better: Cohere AI によるリランカー　RAG But Better: Rerankers with Cohere AI