Acrobat Proの「アクションウィザード」とは？ 定型作業を自動化する強力な機能です。
sites/21051449

一括で、ＯＣＲをしてくれたり、メタ情報の追加・削除をしてくれたり。

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

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

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

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

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

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

ElasticsearchまたはN2なんとか。

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

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

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

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

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

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

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

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

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はこの構造をとる。

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

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

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

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

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

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

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

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

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

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

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

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

★実装済

１　fileBlog
２　Inazuma Search
４　Everything  
５　Wizfile

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

★捨てた【探三郎Svr】

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

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

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

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

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

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

30 form

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

50 book;Shoko

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

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

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

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

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

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

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

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

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

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

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

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

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

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