Gドライブに放り込んでおけば、よいという代物ではない。

まず①「データ変換・加工処理」が必要。OCR済みのデータを読み込み、Gemini Advancedが理解しやすい形式に変換する。必要に応じて、ノイズ除去やテキストの正規化などの前処理を行う。文書の内容を解析し、メタデータ（タイトル、作成日など）を抽出したり、インデックスを作成する。

次に②「データ連携処理」が必要。変換・加工されたデータをGemini Advancedに送信し、学習データとして取り込む。Gemini AdvancedのAPIを使用して、効率的にデータを送信する。

この①②作業を「データパイプライン」と名付けよう。そして①をデータパイプライン前処理とし、②をデータパイプライン送信作業と名付けことにする。

Geminiが言うには①前処理もプログラミンで可能らしい。しかし、そのようなスキルは私にはないし、時間的・経済的な余裕もない。おそらく30万文書はこの前処理にはほど遠いだろうけど②の送信作業に進みたい。

もう少しだけ①前処理をしようと思う。
学習データとしては不十分だが、検索データとして機能する程度に。

なにごとも二律で考えることにしている。しかし、だいたい三軸になる。四つ目が加わるとハレーションを起こすからタブーとしている。

素材は各PDF。Chapterとbookのように重複が生じてしまうがフォルダ分けをしているから規律がある。論文と本というような重複があるのだから神経質になることはない。素直に入れ物の性質に応じて愚直に入れればよい。

乗り物の筆頭はfileblog。そしてこれを含む他のシステムや各クラクド・サーチなどの検索エンジン。乗り物が、または乗りこなしているうちに、入れ物と素材の変更を求めてくるだろう。

三軸目が、ＡＩ・ＲＡＧ・検索エンジン。三番目が素材と検索エンジンの脆弱さを補ってくれる。

 filebrogと比較するために【Inazuma Search】を導入。
 filebrogと同様に近接検索ができない。でも、ぶちこんでおけばあるレベルの仕事をしてくれる。素材が明瞭であればＡＩや近接検索がなくてもいいことになる。しかし、30万もある素材を加工することは無理。だからAI的に頼るしかない。このジレンマは解消することはないだろう。主要な素材をなるだけ適正化（分離・加工・関連付け）しつづけるしかないだろう。

RAGを構築できれば、近接検索も可能になるだろう。
近接検索はNear検索と同じだと思う。
近接検索とは、近傍検索とは、キーワードとキーワードの距離を検索条件として絞り込むことにより適合度の高い検索を行うこと。これが可能であれば（になれば）、検索技術のみで素材Bookだけで目的は達成できるのに…。

しかし、いくつかのクラウドのサービスの方々に問い合わせたが近接検索はまだできないとのこと。つまり【データパイプライン】作業が必要とのこと。

 ElasticsearchまたはN2なんとか

どこかで書いてあるが、エラクレ的はいったん構築してもメンテナンスとチューニングが常時必要となると唱われており、それゆえに月額ランニングコストがかかって金がかかり、CTIソフト80万の二の舞になると危惧していた。

しかし、CTIは10年ぐらい役に立っているので十分だったから10年もてばいいのだから、メンテナンスは無視すればいい。

そして、そこに書いてあったように、イナズマもfileblogもチューニングなしで動くのだから月額ランニングはいらんだろう。MSはそんな高度な素材でないはずだ。要常時チューニングは大きな企業の場合に限ると思う。

３０万ぐらいで導入してくれるのならば、2台用意しておいて同じそれきり構築でいこう。たぶん私ならば、維持していけると思う。

1台目はハチPCを使う。2台目はクロネコPCを使う。それまでにイナズマ化による水冷PCはクロネコ主要PCになっているだろう。間に合わなければドットPCを。ドットは暫定的にノートをあてがう。

根源的に、Inazuma serchを軸にすることになる。

入れ物の前にＡＩ（ＲＡＧ）・検索エンジンを念頭に置かなければならない。そは次である。

Aは、おそらく永続的なレギュラー。

Bは、いまだ有用性の確信にいたっていないが、鋭意試用中。それなりに利用しているもの。有料なので無用と判断したら中止するもの。

Ｃは、無料なのでただ手を出しているもの。

Ａ01  sharepoint
Ａ02  Gsite

B1  Dropbox

B2  Evernote

C――

Inazuma serch／

☆

クララドを利用すると入れ物が限定される。もっとも社内データーを指定することもできるだろうがげんかいがある。原始的なのがInazumaserch。つまりオプンレスを基準にしたほうがいい。検索エンジンが壊れる場合を想定、また別の検索エンジンに乗り換える場合のために素材のフォルダが必要となる。

システムの世界にリポジトリというものがある。

各バージョンを自動的にバックアップすることらしい。Wordがクラッシュしたときに直前のデータが残っていたり、ウインドウズのアップデート履歴から過去のバージョンに戻る機能は、この類いなのだろう。

私は、この仕事をするようになった直後にこれを手動でするようになった。訴状01というファイル名からはじめる。このデ一タがクラッシュしたら怖いと感じた瞬間に、上書保存（Ctl+S）したうえ訴状02にする(F12）。また、別の展開がはじまったり・それまでの内容を大幅に変えることになりそうなときも同様だ。これを手動リポジトリと呼んでおこう。

タイプ作業以外でも同じことをする。前者に該当するものはないが、大きく方針を変える場合はそれまでの書類群を一つの袋に入れ、複製したものですすめる。

そのようにして、データー（作品）がなくなった場合に備えるバックアップをしている。いや.違うな。おそらくは、昔、長い間かけたWord文書がクラッシュして手痛い目にあったとか、後者作業を怠って方向転換した結果、元に戻る必要があったとき戻れなかったという手痛い経験があったからだろう。

そういうことだろうがこれは本質的ではないだろう。機械が自動的にバックアップしているとしても安心できず、能動的にこれをすることによってその不安感を払拭しているのだ。手動リポジトリは、自身が 「ここらで、いったん保存して安心しておこう」 という意識を持って、能動的に過去のバージョンを作成する。これは、単なるデータのバックアップというだけでなく、作業の区切り や 心の安定 にも繋がっている。また、 「へんな方向にいっても元に戻れる」 という安心感は、チャレンジ精神 を与え、新たなアイデアや表現に挑戦する勇気を与えてくれる。 “創造性を刺激するリポジトリ” だ。

手動リポジトリは、デジタルデータだけでなく、アナログな世界でも見られる。例えば、画家が絵を描く際に、途中で写真を撮ったり、スケッチを残したりするのも、一種の手動リポジトリと言える。

このように、手動リポジトリは、人間の “創造性” と深く結びついていると言える。

サブマシンには、毎日バックアップをしてもらう。

サブマシンは他にバックアップデータをクロールしており、スタッフの書庫になっている。

MS-Svr予備機は、スタッフと同じ数だけある。

Inazuma Searchはローカル環境での利用を想定したソフトウェアであり、Svrではない。

fileblogのようにサーバーで使用できるといいのに…

フェスとエラクレは手に負えなかったが、イナズマは簡単だった。イナズマがサーバーで使えるならすべてうまくいくのに…

そこで、39PCを潰して常時クロールにして専用にしよう。そしてリモートで操作する。

作者ページにスペックなどの動作環境はないが、クロールにはかなりのパフォーマンスがされる。つまり、各PCのイナズマは不定期クロールの古い状態だが、最新をみたいときにイナズマSvrもどきを確認する。

また、クロール結果を移動することによって最新クロールになるかもしれない。そうすると3日が約10分になる。そもそも、そのようなサブマシンがあれば、各PCの不定期クロールイナズマはいらないだろうな。

うん、いずれにしても39PCイナズマ専用作戦は採用だな。というかこれは各人サブマシン構想だ。

そのとき、PCが1台不足する。ハチ分の同じもの2台買おう。そうすると最近モヤモヤしていた購入欲求も満足できる。ハチのモニター2台を中央に移動。すると中央デスクのモニターは4台・いや5台かな。うん、ちょうどいい。

 Fileblogのあの機能のTag付けは、PDFまたはword