AI

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 に読ませるのはやめた。代わりに「...
AI

縦書き資料をRAGにする前段を作る ― 8GB GPUのYomiTokuで432ページ7分、paperlakeができるまで

手元の縦書き資料(スキャン画像)をAWSでRAGにするための前段を作った。OCRは資料を外に出さず8GBのRTX 2070で回す方針にして、YomiToku・Qwen3-VL・PaddleOCR-VLを実ページで比較。432ページを7分で読む汎用の紙資料パイプラインpaperlakeができるまでの開発記。
AI

Amazon Connect + KVS + OpenAIで通話の怒りをリアルタイム検知する — 45日で完走した個人開発の全記録

crossbar_telepath のポストモーテムである。プロジェクトは2026-08-24にアーカイブした。畳んだ経緯(電話番号クォータの180日ルール)は前回書いたので、今回は45日間で何ができたかを総括する。死因の解剖が前回なら、今...