Acrobat9とDCそして35万もした

PDFソフトといえばAbobeのAcrobatです。

だって、PDFはAdobeが開発したのですから。ふりかえると現在のDCの前に6.7.8.9の各バージョンを購入していました。丁寧にシリアル番号を控えている。ver9のCDが6枚もある(当時はスタッフが多かった)。9より前のCDは行方不明(9を大量購入したので無用と判断し廃棄したのだろう。とっておけばよかった)。9より後のパッケージを購入していない理由は9が使い勝手がよく現役だからです。

現在のDCはパッケージで売ってくれません。買い切りでなくザブリスクです。人数分いるので司法書士専用ソフトに匹敵する費用が毎月かかるが、Adobeの儲けの態度ではないのだろう。DCというよりPDFというソフトウエアはインフラそのものというところがあり、常に進化を求められているのだと想像します。 電子署名というインフラに密着している司法書士事務所としては、最新の電子署名技術に触れて熟知していなければならないところもある気がする。

買い切りを求める人は、ランニングコストだけを問題にしているのではないと思う。アップグレードを積極的に拒んでいるのだ。PDFファイル化ができればそれでよく、余計な機能はまつたく邪魔なのです。Acrobat6ぐらいがちょうどいい。軽くて速いのがいい。電子署名なんかしたくない。ところで、DCとそれ以前のバ―ジョンは共存できない(二つをインストールできない)。そこで、日常PDF業のために、干渉しないAdobe以外のPDFソフトも導入するはめになってしまった。

使いづらいがDCの機能はすごい。この正月の3日間わが事務所のDCくんは、千冊ほどの解本をアクションウイザ―ド自動化によって休むことなくOCR化してくれた。 こんな芸当はJustさんやエレメントくんではできそうにない。

アクションウイザ一ドを組むのにはかなり苦労しました。条件付設定を仕込むだけでプログラムは不要でした。しかし6時間も作業したところでフリーズしてしまう。マシンが弱いのだろう。事務所PCはどれもSSDに換装済でメモリを32MBに上げてあるのに。途中で止めることはできず正月そうそう最新PCを大須商店街で買ってきて成功しました。35万円もした。高校生のころからIBMだったのでそのあたりで統一していたのですがツクモの自作PCという例外が生まれてしまった。

CPUの性能差とビデオカードの影響とみた。こういうのを目の当たりにすると、全体的な買い替えなのかなあと頭によぎり、まだ捨てきれていない旧代PCの山をみて思いとどまります。ゲームをやるわけでもなくCADを扱うのでもない。ただワープロだけ。だからSSDと最強メモリの先は無用と思っていた。これからは、AI処理スペックのためにそうはいかなくなるのだろう。この千冊処理はRAGの前処理です。

ところで、DCが高価だから全PCにインストールしてしないというわけではない。 使い勝手が悪いからだ。前述したが機能が多すぎる。機能の多さが重くしている。あっても困るものではないが使わない機能ならむしろないほうがいいと思うようになった。こうよぎるのは、9があるからで、DCしかないのならそんな気持ちにならないのだろう。

回転木馬のデットヒート

OCR化の時間

この正月の3日間で、千冊ほどあったデジタルデータをOCR処理をしました。
アクションウイザ一ドでしました。
リアル本ではなくデータとしての本は便利です。机から動かなくていい。あの本のあそこの記述を確認したい…という症状で作業が中断してしまっている状態であったのが、瞬時にボタンを押せば画面に現れる。もちろん引き出すにはそれなりの地道な作業が必要だったし、検索スキルも求められます。

アクションウイザードを利用しないOCR処理は、解本(自炊)した本に対し、まず①ファイルを開きます。②次にOCR化します。そして③保存してファイルを閉じます。

この②のOCR作業には10分程(待ち時間)かかります。そこで、別のパソコンで別の本の作業をします。これを待ち時間なく操作し続けるにはパソコン5台が必要になります。そして、かかる①②③の操作には待ち時間を除き2分程かかります。

アクションウイザ一ドは、この①②③の作業を自動でしてくれます。
2分✕千冊という時間が削減されます。

33時間になります。 計算式は、2×1,000 =2,000 2,000÷60 =33。

アクションウイザ一ド

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

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


paperという入れ物

Paperという入れ物(フォルダ)。

論文形式のようなものを意味しています。通達先例(判例)は、論文とは違いますがややここにに入れておきます。 Noteに入れるよりもマシだから。

それだけで完成しているところがChapter(章)と違い、QandAとの類同は、ある種の問い(命題)がありそれに答える形式にあること。qandaとの差異は、qandaが1・2枚であることに対しPaperは10ページ以上になってしまうこと。問いというかテーマであり、qandaは端的に答えらる問い(命題)であるのに対し、Paperは帰納や演繹法をつかって導出しなければならない類。所謂論文がpapeです。

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

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万文書・1TB)であるわけです。

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

01 form
02 qanda
03 Paper
04 book
10 server

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

RAGが欲しい

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

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

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

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

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

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

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

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

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

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

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

検索エンジン(オプンレスSvr)

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

★実装済

1 fileBlog
2 Inazuma Search
4 Everything  
5 Wizfile

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

★捨てた【探三郎Svr】

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

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

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

素材の整理

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

10 qanda:1問1答形式(問いがあるもの

20 Paper:論文形式・通達先例(判例):それだけで完成

30 form

40 chapter:解説本解体(章):隣接と関係

50 book;Shoko

60 note:雑多なメモ(NSR)★、つまりその他だな。
70 server
 71mfile
 72mclient

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

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

ナレッジPDFについて

ナレッジPDF(30万文書・1TB)は、その7割が書籍で1割が市販のデジタル書式集で、残りの2割が事務所として手記です。

うち、書籍の取扱いに苦労します。

一つになっていてくれないと困るが、一つの命題毎になっていて欲しい。そうでないと検索満足化に耐えられない。RAGは可能なのだろうがそれは叶わぬ夢。