filebrogと比較するために【Inazuma Search】を導入。
filebrogと同様に近接検索ができない。でも、ぶちこんでおけばあるレベルの仕事をしてくれる。素材が明瞭であればAIや近接検索がなくてもいいことになる。しかし、30万もある素材を加工することは無理。だからAI的に頼るしかない。このジレンマは解消することはないだろう。主要な素材をなるだけ適正化(分離・加工・関連付け)しつづけるしかないだろう。
検索方法(近接検索)
RAGを構築できれば、近接検索も可能になるだろう。
近接検索はNear検索と同じだと思う。
近接検索とは、近傍検索とは、キーワードとキーワードの距離を検索条件として絞り込むことにより適合度の高い検索を行うこと。これが可能であれば(になれば)、検索技術のみで素材Bookだけで目的は達成できるのに…。
しかし、いくつかのクラウドのサービスの方々に問い合わせたが近接検索はまだできないとのこと。つまり【データパイプライン】作業が必要とのこと。
Fessとエラクレは取り込める大丈夫。
ElasticsearchまたはN2なんとか
どこかで書いてあるが、エラクレ的はいったん構築してもメンテナンスとチューニングが常時必要となると唱われており、それゆえに月額ランニングコストがかかって金がかかり、CTIソフト80万の二の舞になると危惧していた。
しかし、CTIは10年ぐらい役に立っているので十分だったから10年もてばいいのだから、メンテナンスは無視すればいい。
そして、そこに書いてあったように、イナズマもfileblogもチューニングなしで動くのだから月額ランニングはいらんだろう。MSはそんな高度な素材でないはずだ。要常時チューニングは大きな企業の場合に限ると思う。
30万ぐらいで導入してくれるのならば、2台用意しておいて同じそれきり構築でいこう。たぶん私ならば、維持していけると思う。
1台目はハチPCを使う。2台目はクロネコPCを使う。それまでにイナズマ化による水冷PCはクロネコ主要PCになっているだろう。間に合わなければドットPCを。ドットは暫定的にノートをあてがう。
検索エンジン(それを想定した入れ物・フォルダ)
根源的に、Inazuma serchを軸にすることになる。
入れ物の前にAI(RAG)・検索エンジンを念頭に置かなければならない。そは次である。
Aは、おそらく永続的なレギュラー。
Bは、いまだ有用性の確信にいたっていないが、鋭意試用中。それなりに利用しているもの。有料なので無用と判断したら中止するもの。
Cは、無料なのでただ手を出しているもの。
A01 sharepoint
A02 Gsite
B1 Dropbox
B2 Evernote
C――
Inazuma serch/
☆
クララドを利用すると入れ物が限定される。もっとも社内データーを指定することもできるだろうがげんかいがある。原始的なのがInazumaserch。つまりオプンレスを基準にしたほうがいい。検索エンジンが壊れる場合を想定、また別の検索エンジンに乗り換える場合のために素材のフォルダが必要となる。
手動リポジトリ(バックアップの意味)
システムの世界にリポジトリというものがある。
各バージョンを自動的にバックアップすることらしい。Wordがクラッシュしたときに直前のデータが残っていたり、ウインドウズのアップデート履歴から過去のバージョンに戻る機能は、この類いなのだろう。
私は、この仕事をするようになった直後にこれを手動でするようになった。訴状01というファイル名からはじめる。このデ一タがクラッシュしたら怖いと感じた瞬間に、上書保存(Ctl+S)したうえ訴状02にする(F12)。また、別の展開がはじまったり・それまでの内容を大幅に変えることになりそうなときも同様だ。これを手動リポジトリと呼んでおこう。
タイプ作業以外でも同じことをする。前者に該当するものはないが、大きく方針を変える場合はそれまでの書類群を一つの袋に入れ、複製したものですすめる。
そのようにして、データー(作品)がなくなった場合に備えるバックアップをしている。いや.違うな。おそらくは、昔、長い間かけたWord文書がクラッシュして手痛い目にあったとか、後者作業を怠って方向転換した結果、元に戻る必要があったとき戻れなかったという手痛い経験があったからだろう。
そういうことだろうがこれは本質的ではないだろう。機械が自動的にバックアップしているとしても安心できず、能動的にこれをすることによってその不安感を払拭しているのだ。手動リポジトリは、自身が 「ここらで、いったん保存して安心しておこう」 という意識を持って、能動的に過去のバージョンを作成する。これは、単なるデータのバックアップというだけでなく、作業の区切り や 心の安定 にも繋がっている。また、 「へんな方向にいっても元に戻れる」 という安心感は、チャレンジ精神 を与え、新たなアイデアや表現に挑戦する勇気を与えてくれる。 “創造性を刺激するリポジトリ” だ。
手動リポジトリは、デジタルデータだけでなく、アナログな世界でも見られる。例えば、画家が絵を描く際に、途中で写真を撮ったり、スケッチを残したりするのも、一種の手動リポジトリと言える。
このように、手動リポジトリは、人間の “創造性” と深く結びついていると言える。
常時バックアップの数
サブマシンには、毎日バックアップをしてもらう。
サブマシンは他にバックアップデータをクロールしており、スタッフの書庫になっている。
MS-Svr予備機は、スタッフと同じ数だけある。
Inazuma SearchのSvr?化
Inazuma Searchはローカル環境での利用を想定したソフトウェアであり、Svrではない。
fileblogのようにサーバーで使用できるといいのに…
フェスとエラクレは手に負えなかったが、イナズマは簡単だった。イナズマがサーバーで使えるならすべてうまくいくのに…
そこで、39PCを潰して常時クロールにして専用にしよう。そしてリモートで操作する。
作者ページにスペックなどの動作環境はないが、クロールにはかなりのパフォーマンスがされる。つまり、各PCのイナズマは不定期クロールの古い状態だが、最新をみたいときにイナズマSvrもどきを確認する。
また、クロール結果を移動することによって最新クロールになるかもしれない。そうすると3日が約10分になる。そもそも、そのようなサブマシンがあれば、各PCの不定期クロールイナズマはいらないだろうな。
うん、いずれにしても39PCイナズマ専用作戦は採用だな。というかこれは各人サブマシン構想だ。
そのとき、PCが1台不足する。ハチ分の同じもの2台買おう。そうすると最近モヤモヤしていた購入欲求も満足できる。ハチのモニター2台を中央に移動。すると中央デスクのモニターは4台・いや5台かな。うん、ちょうどいい。
FileblogとTag
Fileblogのあの機能のTag付けは、PDFまたはword
検索エンジン(探三郎)
SvrとCltがある。
Svrも成功したが、ある時期から動かなくなってしまった。安定してないのだろう。
Cltは、インストール無用でフォルダ単体で動く。ゆえにゲリラ的な使い方が可能。探三郎以外のClt検索エンジンは複数あるからMSとしてはゲリラ的な使用方法が適する。
おそらく単体で動く簡易なであるゆえだろうパワーがない。たええばサーバーデータを担えない。分離すると動く。そしてこのことからも、検索作業にはPCのパワーがない求められることが解る。
常時バックアップの時間
後日談:ウインドウズバックアップはやめる、特殊ファイルにしかならないから。生のママがいい、それを素材にしてクロールするから。bunbackupにする。バックアップ間隔は、1日・3日などいろいろ試してみる。
~
設定された間隔でファイルの変更を監視し変更があった場合にバックアップが実行される。
ウインドウズの標準仕様の限界は10分らしい。ファイル履歴のバックアップ間隔が10分の場合、5分前に誤って削除したファイルは、バックアップデータには含まれていない可能性が高い。例えば、10時00分にバックアップが実行され、10時05分にファイルを削除した場合、次のバックアップは10時10分に実行される。そのため、10時05分に削除したファイルは、10時10分のバックアップには含まれない。ただし、ファイル履歴は、以前のバージョンのファイルを保持する機能がある。そのため、削除したファイルが以前のバックアップに含まれていれば、復元できる可能性がある。
完全なバックアップを考えるということは、これは入れ子理論に関係する。
バックアップの目的を「①交換」と「②取戻し」に区別し、「①交換」こそがバックアップ本来の意味であると定義づける。
当日作業が消滅しても仕方がないと考える。当日であればまだ記憶されているし、mfillの手前てあるメールなどに残っているから復元は難しくないと考える。だからリアルタイムのバックアップは行き過ぎだ。
そこで、時間は24時間とする。サブPCも1日1回であれば、楽ちんだろう。