Hacker Newsが見直したproduction RAGの現実、local modelで451GBを扱う方法

Hacker Newsは、Andros Fenollosaによる長い振り返り記事を再び前に押し出した。多くのarchitecture demoよりも、production RAGの裏側にある地味なengineering作業をずっと正直に描いているからだ。プロジェクトの出発点はシンプルだった。ほぼ10年分の社内文書、OrcaFlex simulation file、各種technical artifactに対して質問応答できるlocal-LLM assistantを作ること。しかし実際に始まったのは、整ったframework tutorialではなく、451GBのheterogeneous dataをmemory、storage、budgetを壊さずsearchableにするための多段階作業だった。

なぜこの書き込みが響いたのか

Fenollosaは、RAG prototypeから実運用へ進めたことのある人なら見覚えのある流れを率直に説明している。初期stackであるOllamaとLlamaIndexはtoy experimentでは十分うまく動いた。しかし、実際の企業文書環境ではすぐ限界が出た。video、simulation、backup、CSV、malformed documentがpipelineをRAM exhaustionに追い込み、最初の試みは破綻した。そこで価値の低いfile typeを除外し、office documentをplain textへ変換した結果、indexing対象は54%減少し、ようやく最初の段階が現実的なものになった。

結果を変えた転換点

最大のarchitectural pivotは、標準のJSONベースindexingフローをやめ、SQLite上のChromaDBへ切り替えたうえで、文書を150 fileずつbatch処理する方式にしたことだ。この変更により、中断後の再開、checkpointの維持、fragileなmonolithではなく単一のSQLiteベースartifactとしてvector storeをバックアップすることが可能になった。それでもthroughputの問題は残り、laptop GPUだけでは足りなかった。最終的なindexing runはNVIDIA RTX 4000 SFF Adaを搭載したレンタルmachineへ移され、約2週間から3週間をかけて738,470 vectorと54GBのChromaDB indexを作った。

HN読者がこの投稿に強く反応したのは、RAGをpromptの問題ではなく、まずdata pipelineの問題として捉え直しているからだ。最終システムは高速で有用だったが、その前にdocument triage、batch processing、checkpointing、monitoring、storage separationを明示的に片付ける必要があった。元のfileはAzure Blob StorageにSAS linkで残し、vector indexとlocal modelだけをより小さなproduction machineに置いた点も同じだ。conference demoがよく省くのは、まさにこの部分である。この記事は、reliable retrievalがclever prompt phrasingよりも、disciplined ingestion、failure tolerance、そして地味でも重要な運用判断に大きく依存していることをよく示している。