eBPF GPU が遊んでいる理由を eBPF で言い当てる — 自作ダッシュボード eBPFLens、GPU・ディスク・ネットワークまで一日で埋めた記録
前回の記事で、eBPF で Zabbix 風のダッシュボードを再発明する eBPFLens を作り始めた話を書いた。CPU の実行待ち、プロセスの生死、メモリの回収停止、VM の「なぜ止まったか」までが前回。今回はロードマップの残り、GPU...
2026-09
eBPF 
eBPF 平均値の裏を覗く — eBPFとは何か、Zabbixと比べて何が見えるのかを自作ダッシュボードで確かめた
eBPF は「Linux カーネルの中で、検証済みの小さなプログラムを動かす仕組み」である。言葉では何度も聞いていたが、実際に何が見えて何が見えないのかは、手を動かさないと分からない。そこで Zabbix 風の Linux ダッシュボードを...
AI 公開できない RAG を作り切って分かったこと ― Titan + S3 Vectors から手元の ruri-v3 + OpenSearch へ、paperlake の総括
紙の資料を OCR して RAG にする paperlake の総括。Bedrock KB (Titan + S3 Vectors) から手元の ruri-v3 + OpenSearch + 再ランクへ移して hit@1 は 0.40 から 0.73 に。著作物を扱うので公開はしないが、学習として得たものと運用の謎解きを残す。
AI 検索基盤を手元に置いたら AWS より当たった ― ローカル埋め込み + OpenSearch + 再ランクで RAG を組み直す
前回の最後に「キーワード検索を自前で足せば、月 350 ドルの固定費なしでハイブリッド検索が手に入るはず」と書いた。paperlake(紙資料 → OCR → Markdown → Bedrock Knowledge Base → MCP)...
AI S3 Vectors か OpenSearch か ― 同じ 40 問で測ったら、索引では差が出ずハイブリッドで 6 問上がった
RAG の索引を Amazon S3 Vectors に置くか OpenSearch に置くか。paperlake(前回で Golden セットという物差しを作った)は月 1 ドル未満の S3 Vectors を選んでいるが、「1,000 ...
AI 検索は当たっているのか ― RAG に「物差し」を作る: Golden セットと hit@k
RAG を作ると、必ず「で、ちゃんと当たっているの?」と聞かれる。自分で数問試して「当たっている気がする」では、チャンクの大きさを変えたときに良くなったのか悪くなったのかが分からない。paperlake(前回まで)に、変更のたびに同じ質問で...
AI Claude Code から資料を引く仕組み ― paperlake の MCP サーバーは 40 行でできている
paperlake は紙の資料を OCR して AWS の Knowledge Base に索引を作るところまでを自前で持っているが、答えを作る側は Claude Code に任せている。その橋渡しをしているのが MCP サーバーで、中身は...
AI 紙のページはどうやって文字になるのか ― YomiToku に画像を渡してから Markdown が出るまで
YomiToku は Ollama で動いていると思っていた。違った。前々回は「8GB の GPU で日本語の縦書き資料が 1 ページ 1 秒で読める」という結果を書いたが、OCR エンジンの中で何が起きているかは書かなかった。paperl...
AI 機密資料のナレッジベースを AWS の閉域だけで回す ― OCR ローカル案と完全 AWS 案
前々回で作った paperlake は、手元の GPU で紙資料を OCR し、S3 と Bedrock Knowledge Base と S3 Vectors で索引を作って、Claude Code から MCP で検索する構成だった。前...
AI 図は VLM に読ませるべきか ― ローカル VLM で図を Mermaid 化する試験と、文字だけで図が再構成できた話
前回は、8GB の GPU で日本語の縦書き資料を OCR し、AWS の Knowledge Base に載せるところまで書いた。今回はその続きで、図と表をどう扱うかである。結論を先に書くと、図を VLM に読ませるのはやめた。代わりに「...