ハルシネーションのすすめ― 読めないことの効用（RAG設計編）

最近、ローカルLLM界隈ではさまざまなフロントエンドが流行っている。
OpenClawのような尖ったものもある。

だが今回は使わない。

理由は単純だ。

事故るからではない。

事故の仕方が観察にならないから

今回やりたいのは「壊す」ことではない。

誤読を観察すること

だから環境は、あえて地味にいく。

機材は MacBook Air M1 　メモリ　8GB

16GBは勧めない。

なぜか。

16GBは破綻をなめらかに隠す。
8GBは限界を露出させる。

メモリが足りないと、

• 長文で詰まる

• RAGで鈍くなる

• 応答が漂い始める

そのとき初めて、機械の「読めなさ」が見える。

今回必要なのは性能ではない。

破綻の輪郭

フロントは AnytimeLLM

AnytimeLLMは、ちょうどいい。

過剰な自動化がない。
検索も勝手に始めない。
派手な機能も少ない。

つまり、

余計な知識で誤魔化さない。

観察にはそれが重要だ。

みんな大好き Ollama

実行基盤は Ollama。

好きなのは、正しいからではない。

間違い方が一定だから

同じモデル。
同じ温度。
同じプロンプト。

同じ誤読が繰り返される。

その反復が、現象になる。

設定思想 ― 数値は小さく

今回のテーマは「夢を見させる」ことではない。

夢を見始める瞬間を見ること

だから設定は抑制的にする。

• Temperature は低め

• 出力は短め

• 引用は短く

• 問いは一つだけ

長く書かせるほど、機械はそれっぽくなる。
それは誤読の“増幅”であって、観察ではない。

System指示

この一文で十分だ。

機械が沈黙するか。
無理に埋めにいくか。

そこに癖が出る。

RAG設計編

実験環境は整った。

• MacBook Air M1 8GB

• AnytimeLLM

• Ollama

• 小さなモデル

次はRAGだ。

ここで多くの人が間違える。

「できるだけ多く読ませる」方向に進む。

だが今回は逆だ。

1. RAGは補助であって全文読解ではない

RAGは知識の補完装置だ。
だが文学テキストや日記を扱うとき、それは容易に誤読増幅装置になる。

大量のチャンクを渡すと、

• 全体を把握した“ふり”をする

• 文脈を合成する

• それらしい全体像を作る

それがハルシネーションの温床になる。

2. チャンクは短く、冷たく

原則はこれだ。

具体的には、

• 5〜10行

• 物語的区切りで分けない

• あえて中途半端で切る

中途半端に切ると、機械は補完を始める。
その補完の癖が見える。

3. ベクトルは増やさない

ありがちな設定は、

• 上位5件

• 上位10件

だが8GB環境では、これは「読んだふり」製造装置になる。

推奨は上位2件まで。

足りない。

その足りなさの中で、機械はどう振る舞うか。

• 正直に「根拠がない」と言うか

• 推測を始めるか

そこが観察点になる。

4. 質問は一つだけ

複数質問を投げると、機械は構造を合成する。

• 比喩の意味は？

• 作者の心理は？

• 時代背景は？

これを同時に聞けば、ハルシネーションは作品になる。

問いは一つ。
できれば具体語を含める。

例：

これだけでいい。

読めないことの効用

8GBは不便だ。
遅く、すぐ限界がくる。

だがその縁で、

• どこから想像が始まるのか

• どこで確信が崩れるのか

• どこで“それっぽさ”が立ち上がるのか

が見える。

16GBは正確さを上げる。
8GBは誤読を露出させる。

今回は後者を選ぶ。

まとめ

RAGは正しく使えば精度を上げる。
だが今回は違う。

今回は、

読めないことを、見える形で残す。

それがテーマだ。