アウトライナ【11】

ON しおりを自動生成する ON 既存の目次からしおりを生成する OFF 目次のページ番号でリンクを設定する とした場合の対応方法になります 対処方法ですが、下準備2で次のようにしてから自動生成ウィザードを使用してみてください 1問 ＊＊＊ --- 1 2問 ＊＊＊ --- 1 3問 ＊＊＊ --- 1 4問 ＊＊＊ --- 1 300問 ＊＊＊＊ --- 1 とするとよいとのこと。

アウトライナ―【10】

 自炊書籍を分離したい。

★

わかりやすい本として「Ｑ＆Ａ300問」という本がある。約700頁ある。自炊目次は、章立てとなって2階層となっている。

　第1章　　総則
　　1問　＊＊＊　　…〇〇頁
　　2問　＊＊＊　　…〇〇頁

　第2章　　各論1
　　3問　＊＊＊　　…〇〇頁
　　4問　＊＊＊　　…〇〇頁
　300問　＊＊＊　　…〇〇頁

この＊＊＊タイトル毎に分割し、且つこのタイトルをファイル名にしたい。

（分割後のファイル名を「しおり」にする方法がわからない）

★

★

私が推測するには、1「既存の目次からしおりを生成する」が頼りになる。2だから、この既存の目次が正確でなければならない。そこで、既存の目次をＯＣＲしたものをワードに落として丁寧にチェックして差し替えるほうがいい。3その際頁番号は無関係。

★

うまくいかない。

★その他
スキャンしてOCR化しているので、テキスト化は完全ではない。

バラバラにして検索が目的であるから、はしがき・索引・あとがきは削除している。
また、N章の末紙の白紙には頁数が書かれているが邪魔だから削除している。

頁番号は、ほとんど100％フッター中央にある。

目次に頁番号が振られ、本文にもその連続した頁番号が振られている書籍がある。
　例　目次1・2・2、本文4・5・5…
いっぽう、本文に独立した頁番号振られることもあり、これが多い。

自炊目次を置き換え・はしがき等を削除すると、1ワード目次と、2自炊本文の2つになる。
1ワード目次には頁番号を無視しているし、自炊本文は連続していない場合がある。

FileblogとTag

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

素材の整理

素材フォルダは次である。

10 qanda：１問１答形式（問いがあるもの

20 Paper：論文形式・通達先例（判例）：それだけで完成

30 form

40 chapter：解説本解体（章）：隣接と関係

50 book;Shoko

60 note：雑多なメモ（ＮＳＲ）★、つまりその他だな。
70 server
 71mfile
 72mclient

結局、10～40を入れ物で鍛えて（整理、ファイル名変更、タグ）、それが軌道に乗るまで作業を続けなければならないのだろう。おそらくいま40%ぐらい。

まず入れてみる。ファイル名・タグに頼らずその段階で成立していなければ（効果が発生しなければ）ならない。この段階で効果がなければ、、、

常時バックアップの数

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

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

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

常時バックアップの時間

後日談：ウインドウズバックアップはやめる、特殊ファイルにしかならないから。生のママがいい、それを素材にしてクロールするから。bunbackupにする。バックアップ間隔は、1日・3日などいろいろ試してみる。

～

設定された間隔でファイルの変更を監視し変更があった場合にバックアップが実行される。

ウインドウズの標準仕様の限界は10分らしい。ファイル履歴のバックアップ間隔が10分の場合、5分前に誤って削除したファイルは、バックアップデータには含まれていない可能性が高い。例えば、10時00分にバックアップが実行され、10時05分にファイルを削除した場合、次のバックアップは10時10分に実行される。そのため、10時05分に削除したファイルは、10時10分のバックアップには含まれない。ただし、ファイル履歴は、以前のバージョンのファイルを保持する機能がある。そのため、削除したファイルが以前のバックアップに含まれていれば、復元できる可能性がある。

完全なバックアップを考えるということは、これは入れ子理論に関係する。

バックアップの目的を「①交換」と「②取戻し」に区別し、「①交換」こそがバックアップ本来の意味であると定義づける。

当日作業が消滅しても仕方がないと考える。当日であればまだ記憶されているし、mfillの手前てあるメールなどに残っているから復元は難しくないと考える。だからリアルタイムのバックアップは行き過ぎだ。

そこで、時間は24時間とする。サブPCも1日1回であれば、楽ちんだろう。

手動リポジトリ（バックアップの意味）

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

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

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

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

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

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

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

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

サブマシン・引退PC

 引退PCをサブPCにする。

すると引退しやすくなってサイクルがはやくなる。

引退マシンには、①常時バックアップと②常時クロールをしてもらう。

あと時間がかかる仕事が似合う。美の特有としてOCR化作業と機械学習がある。その他スタッフには、そのような仕事はいまのところ見つからないが、RAGがかなりの時間とリソースを要求するならサブマシンに逃がす。

私のモニターの数

私のモニターの数は９台です。

スタッフの平均値は３台。２台の者が２人ある。

私は、画面は多ければ多い方がいい。
問題は、物理的というか視野的な限界と思う。

この５階B室ディスクの中心は、５・６・７の三つ。他は視野に入らな）。
９が視野に入らないということは以外だ。その理由は視点が「５」を中心にやや上向きであることと私の視野は上下より左右にあるからだろう。平均値３台の理由はおそらくそこにある。

２人が２台のみとしたいと求めた理由は、それ以上は鬱陶しいということだろう。

Fessとエラクレは取り込める大丈夫。

 ElasticsearchまたはN2なんとか

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

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

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

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

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

Inazuma SearchのSvr？化

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

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

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

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

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

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

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

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

Fessとエラクレは手に負えないから考えるな。

 ElasticsearchまたはN2なんとか。

これらが本物のようです。本格的というか。

それゆえか、チャレンジしてみたが手に負えない。

Elasticsearchの構築には100万かかるという。QuickSolution並じゃあないか。一見ならばオリジンのエラクレのほうがいい気がする。しかし、テレコムアシスト（80万）や音声メールの件もあるから、オリジンはやめておいたほうがいいのかも。

考えてもキリがないし、Fileblogがあるのだからしばらく考えるのはやめにしよう。そのしばらくとはあと1年はということにする。それよりも素材の最適化をやりましょう。

そのうちに三軸日がやってくる。

また、イナズマSvr化が先決だ。

グルグル考えるのは体に毒だ。

検索エンジン（探三郎）

 SvrとCltがある。

Svrも成功したが、ある時期から動かなくなってしまった。安定してないのだろう。

Cltは、インストール無用でフォルダ単体で動く。ゆえにゲリラ的な使い方が可能。探三郎以外のClt検索エンジンは複数あるからMSとしてはゲリラ的な使用方法が適する。

おそらく単体で動く簡易なであるゆえだろうパワーがない。たええばサーバーデータを担えない。分離すると動く。そしてこのことからも、検索作業にはPCのパワーがない求められることが解る。

ブログの目論見1

このブログを書き修正を繰り返すことによって、〈ある概念を構築しよう〉としています。

言葉によって思考が可能となると同様に、一枚一義という形のこのブログ形式が有用と考えた。間違っているかもしれないし、間違っていないがただ一枚のメモに入れれば済むことかも知れない。

ディバイド・アンド・コンカーの実践をしている。

こうやって、考えた結果を書くことによって・・・いや、書くことによって考えている。このように突然書きたくなるのは、考えをまとめたいのだろう。その場はSharepointでよさそうにもかかわらず、Bloger に求めている理由が何かあるのかもしれない。その理由は、この一枚一枚の形式性なのか、それとも外部に発信されているという状態性なのか。もし、後者であれば、気持ちのうえでそのような状態が必要だとしても誰も見ないのだから、そこに何を期待するのかという問いを立てよう。

検索エンジン（オプンレスSvr）

オプンレスでSvrの検索エンジンは、次が実装済・未構築・捨てている。

★実装済

１　fileBlog
２　Inazuma Search
４　Everything  
５　Wizfile

★未構築【Fess】【Elasticsearch】【QuickSolution】

★捨てた【探三郎Svr】

「1・fileBlog」はＮＡＳ（Ser)を対象にしており、それ以外はローカル（Clt）にしています。「2乃至3」もＮＡＳ（Ser)を対象にすることができるのですが、パフォーマンスが極単に落ちる気がする。

あと、【Fess】と【Elasticsearch】は近接検索できるので魅力的ですが、設定・メンテナンス・チューンナップが私では手に負えない。

また、【QuickSolution】は説明書によると、ぶち込んでおけば学習データを構築してくれるとあるので魅力であるが、【Fess】と【Elasticsearch】を専門業者に依頼する以上に高価だ。それゆえに【QuickSolution】を採用するよりは、【Elasticsearch】を採用するべきだろう。

アウトライナ―（ Antenna House）

 Antenna Houseのアウトライナー

千頁ある自炊書籍を分割したい。
高度なAＩならそのようなことが自動化できるかもしれない。ABBYY FineReaderがそうかもしれない。しかし、いまのところは手作業でないとできないだろうと思われる。

AＩではないが標記のソフトがある。

paper（フォルダ）

Paperという入れ物（フォルダ）。

論文形式のようなものを意味している。通達先例（判例）は、ややズレが生じるがここに入れておく。 Noteに入れるよりもマシだから。

それだけで完成しているところがChapter（章）と違い、Qantaと一致する。

paperpileに入れる論文がもっとも合致する。したがって、ジャーナルのほうがいいかもしれない。しかし、上のように先例がQandAやNoteからズレるという状況からジャーナル（研究誌、論文）に入れれないし、個人・事務所的ルールの入れ物が必要なのでペーパー（Paper）にした。たぶん、将来さらに変わるだろう。

～以下は従前の取扱いであり、その後方針を変えた。

qandaとの類同は、ある種の問い（命題）がありそれに答える形式にあること。qandaとの差異は、qandaが１・２枚であることに対しPaperは10ページ以上になってしまうこと。問いというかテーマであり、qandaは端的に答えらる問い（命題）であるのに対し、Paperは帰納や演繹法をつかって導出しなければならない類。所謂論文が、papeである。

EverNote

￥1,550/月で３個使っている。

データパイプラインや近接検索を夢見ている。が半分諦めている。しかし、完全とはいわないまでもある程度は勝手になるとは思っている。執着しないことにして別の道を模索してるということ。その別の道とは、地道なというより地味な「ただの検索」である。

「ただの検索」

ファイル名を最適にすることは大変なので、入れ物（乗り物）をEverNoteにすればよいと思った。ノートブックとタグの2軸がよさそう。タグがなんとかしてくれると思った。タグだけでの検索、というか絞り込み。タグは階層的となり世の中のモノコトに応じてどんどん増える。100はある。

EverNote はタグ検索に向いていないのではないのか。というよりタグで整理するのはそもそも無理ではないのか。またevernote は入れ物として適当ではないのではないか。という気がしてきた。このうちどれかが該当すればそのようになる。だから、いったんこの道は保留にする。

Inazuma Search（クロール時間）

 Inazuma SearchのSvrのクロールに36時間かかった。ハチPCだと倍の3日かかるだろう。

データを計らなければならない。

Cltだと24時間だと思う。Cltは外付HDDにしている。クロールデータ量をはからなけばならい。

Clt×1.5=Svr  内部ネットワークの障害はたいしたことはない。

クロール中はいずれもかなりのパフォーマンスを要求された。クロール後の検索速度等は申し分ない。サーバーデータが大きすぎてソフトの許容量を超えるのでないかという懸念があったが、無用だった。探三郎は許容を超えた。

ということは、おそらくFessも大丈夫だろう。素材の最適化以外のメンテナンスやチェーンナップは不要だと思う。

いずれも常駐クロールははずしておいてよいことになる（最新を求めるものではない）。

いずれにしても、更新クロールは連休しかやれない。

素材が安定したらSvrのみになるだろう。否、Cltはいらないだろう。

データパイプライン

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

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

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

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

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

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

検索方法（近接検索）

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

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

検索エンジン（Inazuma Search）

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

検索エンジン（それを想定した入れ物・フォルダ）

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

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

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

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

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

Ａ01  sharepoint
Ａ02  Gsite

B1  Dropbox

B2  Evernote

C――

Inazuma serch／

☆

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

素材フォルダの遍歴

変遷のほうがいい。いや、この迷いは遍歴だ。

sub.素材の入れ物

フォルダ名を次に変更する。

10 qanda
20 Paper：論文
30 form：
40 book（syokoと同じ）
60 server

桁を上げたのは、そのフォルダの下位に再項目の存在を示している。
たとえば、

10 qanda
12 qanda-不登

………………………………

その素材（element（エレメント））が、ナレッジPDF（30万文書・１TB）であるわけです。

その素材を、次に分類する。

01 form
02 qanda
03 Paper
04 book
10 server

上の各フォルダの全部また一部を、検索エンジンまたRAGが目的に応じて参照する。Inazuma serchはこの構造をとる。

素材・入れ物・乗り物

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

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

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

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

ナレッジPDFについて（その１）

 ナレッジPDF（30万文書・１TB）は、その7割が書籍で１割が市販のデジタル書式集で、残りの２割が事務所として手記です。
うち、書籍の取扱いに苦労します。一つになっていてくれないと困るが、一つの命題毎になっていて欲しい。そうでないと検索満足化に耐えられない。RAGは可能なのだろうがそれは叶わぬ夢。

RAGが欲しい

RAG：リトリーバル・オーグメンテッド・ジェネレーション

蓄積文書を情報源とした質疑応答システムのこと。

より具体的に表現するならば、蓄積文書を学習データとして、RAGを実装したAIチャットボットの開発です。

約30年分の蓄積文書は、30万文書・１TBになった（ ナレッジPDFと呼ぼう）。データ化に５年ほどかかった。取り込まれなかった分が若干あり、新規データが毎年増えることになるが、次の段階に移行したい。

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

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

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

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

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

開発を外注しても、定期的なメンテナンスとチューンナップが必要となるだろう。自分が理解できる範囲でとどめることにしよう。まあ、お金がないという理由もあるが。

RAGは夢として、検索データとして機能する程度（これを検索満足化と呼ぼう）で我慢するしかない。