#rag

What jumped out at me is not the code. It’s the claim that wrapping retrieval behind MCP is what turns “a notebook prototype” into something you can put behind an SLA. I think that’s directionally right, but also a little too neat. MCP gives you a clean seam between the host and the retrieval system; it does not magically make the retrieval system trustworthy. If your chunking is bad, your metadata is sloppy, or your answer ranking is weak, you just get a well-packaged failure. The strongest par

読んでまず思ったのは、RAG の話って「検索して答えさせる」だけで終わりにしがちだけど、本当に面倒なのはそこから先なんだな、ということだった。デモなら動く。でも実運用に乗せると、チャンクの切り方、再インデックスのしやすさ、ログに残る説明可能性、マルチテナントの分離みたいな話が一気に重くなる。記事はその泥臭い部分をちゃんと見ていて、そこは素直に好感が持てた。 特に引っかかったのは、MCP を「接続の標準」として置いているところだ。RAG と vector database だけなら、まだ「まあよくある構成」で済む。でも MCP を挟むことで、モデルがデータベースに直接触るのではなく、`search_docs` のような tool を呼ぶ形に寄せている。これ、地味だけど大きいと思う。各チームが個別に glue code を作るのではなく、検索能力そのものをひとつのサービスとして扱えるからだ。モデル周りの話はつい賢さに目が行くけれど、実際に壊れやすいのは接続面なんだよな、と改めて感じた。 もう一つ、地味に刺さったのは semantic cache の話だった。RAG の議論では「どう賢く検索

最初に思ったのは、「これは便利そうだが、ちょっと怖いな」ということだった。 県庁の問い合わせ対応にAIを入れる、しかも単なるチャットボットではなく、Webサイトの情報を読ませて答えさせるRAG構成で、さらに本番の問い合わせを人が見ながら検証する。設計としてはかなり筋がいい。でも、役所の窓口って一度つまずくと信用を失いやすい場所でもあるので、そこでAIを前に出すのは勇気が要ると思う。 記事でいちばん引っかかったのは、問い合わせの多くが「調べれば分かること」だとしても、役所側にとってはその“調べる”作業自体が重いことだ。電話で来た質問を、担当課に回して、確認して、返す。あの往復が積み重なると、人数が増えても楽にならない。そこでAIに一次受けを任せる発想は、単なる業務効率化というより、職員の時間を細切れの確認作業から少し解放する試みなんだろうと思う。 ただ、数字の話を読むと、私は少し身構えた。年590時間の削減、というのはたしかに大きい。でも、こういう数字は「うまくいったとき」の話でもある。実際には、誤回答をどこまで許容するのか、更新が頻繁な制度情報をどう追従するのか、回答の根拠をどう残すの

AIエージェントに何を覚えさせるか、どう呼び出すかは、実はかなり面倒な問題です。Cal Paterson はそこに対して、記憶を巨大なパイプラインではなく、もっと素朴な「ファイル形式」として扱おうと提案しています。記事の狙いは、既存の agent memory がなぜ使いづらいのかを整理したうえで、より単純で移植しやすい代替案を示すことにあります。単なる思いつきではなく、Markdown や SQLite、semantic search をどう組み合わせるかまで踏み込んでいるのが面白いところです。 記事の中心にあるのは、agent memory を処理工程ではなくデータとして扱おう、という考え方です。著者はまず、今よくある記憶システムを3種類に分けて批判します。ひとつ目は、特定のハーネスやプラットフォームに縛られるタイプです。会話履歴から情報を抜き出す設計が多く、結局「その人についての記憶」ばかりが増えやすい。ふたつ目は、pgvector、Neo4j、独自の LLM まで使うような複雑すぎる仕組みで、管理も大変だしモデルを混乱させる、と言います。みっつ目は、理想化された graph や

読んでいてまず思ったのは、「RAG を自前で全部持つの、やっぱり重いよな」ということでした。ベクトル化して、検索して、再ランキングして、権限も見て、さらにエージェント用の制御まで入れる。この記事はそこを Foundry IQ 側に寄せて、LangGraph は orchestration に集中させる、という割り切りをかなりはっきり示しています。こういう分担はきれいですし、運用のたびに同じ部品を各エージェントへ複製する苦さも減りそうです。 ただ、読んでいて面白かったのは、「MCP でつながる」と言っても、単にツールを呼べば終わりではないところです。token refresh が必要で、ユーザー権限も別トークンで渡し、しかも knowledge base 自体が planner でもある。つまり、エージェントが planner を持つのに、検索基盤側もすでにある程度 “考える” ので、誰がどこまで考えるかを決めないと、挙動が見えにくくなる。ここは実装の華やかさより、設計の面倒さが前に出ていて、かなり実務っぽいと感じました。 あと、knowledge base の description

家のことを聞ける chatbot を作るために、質問をまずカテゴリ分けしている その分類を、わずか 0.6B パラメータの local LLM にやらせているのが実験の肝 ふつうの prompting だけでは精度が低く、fine-tuning で一気に改善した さらに、カテゴリ名そのものではなく短いコードに変えたら、精度がもう一段上がった ただし「water heater」と「pool」みたいな、水っぽい意味のかぶりはまだ苦手 大きいモデルを何でも屋にするより、小さいモデルに仕事を絞って任せる発想がかなり実用的だと思う 家庭内の質問に答える chatbot を作る、という発想自体がまず楽しいです。 「この部屋のエアコン、いつ替えたっけ？」とか「この前、プールのポンプを直したのはいつだっけ？」みたいな、生活の中の細かい記憶を引っ張り出してくれる相棒ですね。記事では、こうした家庭の知識を RAG で持たせています。RAG というのは、LLM が記憶だけで答えるのではなく、外部のデータベースを検索して、その結果を見ながら答える仕組みです。検索エンジン付きの賢い返事、という理解でだいたい合っ

PDFに目次ページはあるのに、機械が使えるアウトラインが入っていないことがある その場合でも、リンク付きの目次なら比較的きれいに復元できる もっと厄介なのは、ただ印刷されているだけの目次。ここでは「見出し」と「実際のページ位置」を別々に扱う必要がある この記事の面白いところは、PDFの中に書かれている情報を、かなり地道に読み直して `toc_df` を作り直す発想にある RAG（検索拡張生成）では、章ごとに範囲を切れるかどうかが地味に効く。ここを外すと、検索も要約も雑になりやすい この記事が扱っているのは、かなり「あるある」なPDFの悩みです。人間が開くと、きちんと目次ページがある。ところがPDFビューアのブックマーク欄は空っぽ。つまり、ページ上には文字として目次が印刷されているのに、ソフトウェアが使える構造情報としては入っていない、という状態です。 著者はこれを、RAGシステムの文脈でかなり実務的に見ています。文書解析の段階で `toc_df` という表を作るのですが、ここには `level`、`title`、`start_page`、`end_page`、`brea

RAG evaluation is the process of checking whether a retrieval-augmented generation system’s answer is faithful to the provided context and relevant to the user’s question. RAG systems are meant to answer with help from retrieved documents, not just from the model’s memory. Evaluation tells you whether the system is actually doing that well. In practice, teams use RAG evaluation to catch two common failure modes: Low faithfulness: the answer sounds plausible but is not supported by th

RAG (retrieval-augmented generation) and fine-tuning are two different ways to make a language model more useful: RAG gives the model external information at answer time, while fine-tuning changes the model itself using training data. If your app needs accurate answers about fast-changing or private information, RAG is usually the first thing to try because it can use your documents without retraining the model. If you want the model to consistently follow a format, style, or task pattern, fine-

Chunking is the practice of splitting a larger piece of text or data into smaller pieces so a system can process, store, or retrieve it more effectively; semantic chunking does the same thing, but tries to cut at meaningful boundaries instead of by fixed length. Chunking is a core technique in retrieval-augmented generation (RAG), document search, summarization, and any workflow that needs to feed long content into an LLM. Why teams use it: LLMs have context limits, so very large documents must

Semantic search is a way to find information by meaning, not just by matching the exact words you typed. Traditional keyword search is good when you know the exact term to look for. Semantic search helps when users phrase the same idea in different words, use synonyms, or ask a question instead of naming a document. You’d reach for it when: search queries are messy or conversational, exact wording varies a lot across documents, you want to retrieve “about the same thing” rather than “contains th

An embedding is a vector embedding: a list of numbers that represents something—like a word, sentence, image, or user—in a way a model can compare mathematically. Embeddings turn messy, human data into a form machines can use for: Similarity search: “Find documents like this one.” Recommendations: “Show items close to what the user liked.” Clustering and classification: “Group related things together.” Retrieval for LLMs: “Fetch the most relevant context before generating an

A vector database, also called a vector store, is a system for storing and searching data by its numerical embeddings so you can find items that are “most similar” rather than exactly matching text or IDs. Regular databases are great when you know the exact thing you want: a user ID, a product SKU, a timestamp range. But many AI features need semantic search or nearest-neighbor retrieval: “find questions like this one,” “retrieve passages relevant to this prompt,” or “recommend items

Retrieval-augmented generation, or RAG, is a way to make a language model answer questions using relevant external documents it retrieves first, instead of relying only on what it memorized during training. RAG helps when you want answers that are: grounded in your own content, such as docs, policies, tickets, or product knowledge easier to update than retraining a model more likely to mention current or proprietary information In practice, teams reach for RAG when a model needs to answer “what

Hybrid search is a retrieval method that combines keyword search with vector similarity search so you can find documents that match both the exact words a user typed and the broader meaning of the query. Pure keyword search is good when the exact term matters. Pure vector search is good when wording varies but meaning is similar. In practice, many real queries need both. You reach for hybrid search when: users may search with exact product names, error codes, or technical terms the same

A reranker, often implemented as a cross-encoder, is a model that takes a query and a candidate result together and scores how well they match. A reranker solves the “good enough first pass, better final answer” problem. In search and retrieval systems, you usually start with a fast retriever that finds a few dozen or few hundred candidate documents. That first stage is optimized for speed, not perfect ranking. A reranker then looks at those candidates more carefully and reorders them so the mos

Top-k retrieval is a way to search a collection and return the k most relevant items for a query, instead of trying to sort or inspect everything. Top-k retrieval is the standard first step in search, recommendation, and retrieval-augmented generation (RAG). You use it when you want a fast shortlist: the most relevant documents, passages, products, images, or candidates, without paying the cost of full ranking over the entire corpus. In practice, teams reach for top-k retrieval when: the dat

A knowledge base for RAG is the collection of documents or records a system retrieves from to ground an LLM’s answer in relevant source material. RAG, short for retrieval-augmented generation, works best when the model can search a useful, trustworthy set of content before it writes. That content is the knowledge base. You’d reach for one when the model needs to answer questions from: company docs support articles policies and handbooks product specs research notes tickets or tickets-like record

Contextual chunking, also called late chunking, is a way to split a document into retrieval chunks after a model has already encoded the whole document, so each chunk keeps some awareness of the surrounding context. Normal chunking cuts text first and then embeds each piece alone. That is simple, but it can make chunks semantically thin: a paragraph may be ambiguous without the surrounding sections, headings, or earlier definitions. Late chunking helps when you want better retrieval quality

A vector index is a data structure that helps a system quickly find the most similar embeddings or vectors to a query vector; it is also commonly called an ANN index, short for approximate nearest neighbor index. If you store thousands, millions, or billions of vectors and want “find the closest ones,” a brute-force scan is usually too slow. A vector index lets you trade a little exactness for much faster retrieval, which is why it shows up in search, retrieval-augmented generation (RAG), recomm

Cosine similarity is a way to measure how similar two vectors are by comparing the angle between them, not their size. It’s useful when you care more about direction than magnitude. In AI and information retrieval, that usually means comparing embeddings, text vectors, or feature vectors to find items that “mean the same thing” even if they have different lengths. You’d reach for cosine similarity when: ranking search results by semantic closeness, comparing document, sentence, or image embe

Metadata filtering in retrieval is the practice of narrowing a search or vector search to documents that match structured fields like date, author, source, tenant, language, or content type before or during ranking. It solves a very practical problem: not every relevant item is relevant for this user, this time, or this task. If you are building search or retrieval-augmented generation (RAG), metadata filters help you: exclude clearly irrelevant documents early, enforce access control or tenant

Query rewriting or query expansion is the process of changing a user’s search query into a better one—usually by adding, removing, or rephrasing terms so a search or retrieval system can find more relevant results. People often search with short, vague, or underspecified queries. Systems that use the raw query alone may miss relevant documents because the wording does not match the target content. Query rewriting/expansion helps when you want better recall, better intent matching, or more robust

The lost-in-the-middle problem is the tendency of a language model to miss information that appears in the middle of a long context, even when that information is relevant to the answer. This matters any time you stuff a lot of text into an LLM prompt: long documents, chat histories, codebases, retrieval-augmented generation (RAG), or multi-step agent traces. In practice, it means: the model may answer well using the beginning or end of the context, but fail on facts buried in the middle, so

Graph RAG, short for Graph Retrieval-Augmented Generation, is a way to help an LLM answer questions by retrieving information from a graph of connected entities and relationships instead of, or in addition to, plain text chunks. Classic RAG works well when the answer lives in a few relevant text passages. But some questions are really about relationships: who depends on whom, how events connect, which product is linked to which system, or how a concept appears across many documents.

A document loader or parser is a component that takes a file or data source and turns it into text and metadata an AI system can actually use. LLMs do not read PDFs, Word files, HTML pages, or emails directly in their native form. If you want to do retrieval-augmented generation (RAG), search, summarization, or extraction over real-world documents, you first need a reliable way to ingest them. That is where loaders and parsers come in: A loader fetches content from somewhere: local files, cl

技術ドキュメントの画像には、説明を補う画像と答えそのものを持つ画像の2種類がある 画像を毎回モデルに読ませると、コスト・容量・精度の面でつらい 解決策はシンプルで、画像を問い合わせ時ではなく、索引作成時に一度だけ説明文へ変換すること その説明文を通常のテキストchunkと一緒に検索することで、RAGが画像も扱えるようになる 実運用では、不要画像のフィルタリングと周辺テキストを使ったcaption生成がかなり重要 画像を別chunkとして保存する方式が、コスト面でも使い勝手でも有利だった 3つの顧客プロジェクトで、画像を入れた回答は品質が有意に改善した kapa.ai の記事は、RAG（Retrieval-Augmented Generation、検索で集めた情報を使って回答する仕組み）における画像の扱いを、かなり実務寄りに解説しています。 率直に言うと、これはすごく地味だけど、かなり賢い設計だと思いました。 多くの人は「画像も入れたいなら、vision model にその都度見せればいいのでは？」と考えがち

RAGは「答えの質」を上げる仕組みだが、「コスト最適化」は基本的に考えられていない その結果、同じ質問を何度も高価なLLMに投げる、不要な文脈を大量に詰め込む、簡単な質問まで高級モデルに回すといったムダが起きやすい 著者はこれに対して、semantic cache / query router / token budget / circuit breaker を組み合わせたコスト制御レイヤーを作成 ローカル環境の検証では、条件付きでLLMコストを最大85.8%削減できたと報告している ただし数字は実API課金ではなく、記事内の前提価格からの計算結果である点は重要 この記事は、RAG（Retrieval-Augmented Generation）を使ったシステムの「見えにくい出費」に切り込んだものです。 RAGは、ざっくり言うと 「質問に答える前に、関連しそうな資料を検索して、その内容をLLMに渡す仕組み」 です。ChatGPTみたいなLLM単体よりも、社内文書やFAQ、製品マニュアルに強くなるので、実務ではかなり便利です。 ただし

AIの hallucination（幻覚）は、たまたま起きる不具合ではなく、言語モデルの仕組みそのものから生まれるという主張 言語モデルは「真実を知る機械」ではなく、それっぽい答えを流暢に返す鏡に近い 問題の本質は、流暢さと正確さが切り離されていること RAG（検索してから答える方式）は、幻覚を完全に消す技術というより、モデルを信用しすぎないための設計 医療・法律・金融のような分野では、幻覚は単なるミスでは済まず、実害が大きい だからこそ、AIに「最終決定」を任せるのではなく、出典を追える形で使う設計が重要 生成AIを使っていると、たまに「え、それ本当？」という答えが返ってきます。しかも厄介なのは、その答えがめちゃくちゃ自然な文章で出てくることです。 この元記事が面白いのは、AIの hallucination を「モデルがたまたま変なことを言った」ではなく、構造的な性質だと捉えているところです。 つまり、いまの言語モデルは「うっかりミスをする機械」ではなく、そもそも真実そのものを保証するようには作られていない、とい

Kubernetesの実際のバグ修正事例を使って、AI coding agentsの実力を比べた 使ったのは3種類の見え方 - RAG-only: 検索結果だけを見る - Hybrid: まず検索して、そのあとローカルのコードも見る - Local clone: リポジトリを丸ごとローカルで見る 結果は、検索の工夫は「見つける力」には効くが、「どう直すべきか」の理解まではあまり助けないというもの AIは「主なバグ」だけ直して満足しがちで、周辺の変更や副作用を見落としやすい 逆に、issue（不具合報告）が丁寧に書かれていると、AIの方式差はかなり縮まった つまり、AIを賢くする鍵はRAGだけではなく、人間側の問題の書き方にもありそうだ、という話 InfoQが紹介しているのは、CNCFブログに掲載された Brandon Foley のベンチマーク研究です。 テーマはシンプルで、「AI coding agents は、現実の Kubernetes バグをどれだけ直せるのか？」というもの。 ここでいう AI coding agent は、ただコード補完するだけのツールではなく

Zooxは、Confluence・GitHub・Slack・PDFなどに散らばった情報を、LLMで横断検索できる環境へ移行した その中心にあるのが、安全に使える社内AIプラットフォーム「Cortex」 Cortexは、RAG、multi-modal LLM、agent APIを組み合わせた“社内向けAI基盤” 目的は「ただAIを置くこと」ではなく、開発者の1日の流れ全体を速く、楽にすること 導入を広げるために、AI championやhackathonを活用したのが実践的で面白い 重要なのは、決め打ちの自動化から、状況に応じて動くagentへ発想を切り替えること InfoQの記事「Accelerating LLM-Driven Developer Productivity at Zoox」は、Zooxでの社内開発体験をどうAIで変えたかを紹介する内容です。 話し手は Zoox の Staff Software Engineer、Amit Navindgi さん。彼は、LLMを使って開発者の生産性を上げる取り組みを、実運用ベースで進めてきた人です。 この話、かなり現実的で好感が持てます。

AIエージェントの失敗原因は、モデルそのものより評価の弱さにあることが多い 本番で使うなら、Retrieval / Generation / Agent / Production の4カテゴリで見るのが重要 単純なAccuracyだけでは足りず、hallucination rate や faithfulness を測らないと危ない 手動チェックは少量なら有効だが、大量運用ではすぐ限界が来る この記事のフレームワークは、「出してから直す」ではなく「出す前に壊れ方を見つける」発想が強い Towards Data Scienceの記事は、本番運用するAIエージェントには専用の評価基盤（evaluation harness）が必要だ、というかなり実務寄りの話です。 ここでいうAIエージェントは、ただ文章を返すチャットボットではありません。 RAG（検索してから回答する仕組み）を使ったり、外部ツールを呼んだり、複数ステップでタスクを進めたりする、いわば“仕事をするAI”です。 この手のシステム、デモではそれっぽく動くのに、本番に入れ

OncoAgent は、がん診療の意思決定を支援するための open-source なAIシステム ただのチャットボットではなく、複数の役割を分担する multi-agent 構成になっている 医療ガイドラインをもとに答える RAG（Retrieval-Augmented Generation） を使い、根拠のない回答を減らそうとしている 患者情報を外部クラウドに出さない Zero-PHI policy を重視し、on-premises で動かせる設計 2段階のモデル（Tier 1 / Tier 2）を使い、軽い案件は速く、複雑な案件は深く考える AMD Instinct MI300X と ROCm を使った学習最適化が大きな売りで、約50分で全データの fine-tuning を回せたとされる ただし、これはあくまで 臨床判断の補助 であって、医師の判断を置き換えるものではない この記事で紹介されている OncoAgent は、ひとことで言うと「**がん診療に特化した、かなり本気のAI意思決定支援システム