25/12/24 10:14:50.91 .net
>>207
三行で
209:名無しさん＠お腹いっぱい。
25/12/25 14:20:07.82 .net
長年、Scansnapで自炊したPDFにScansnap OrganizerでOCRをかける、
というフローでやってきたが、OCRの誤認識率が体感5～10％くらいあった
AI技術の長足の進歩を考えると最新のOCRは絶対認識率上がってるよなぁと思いつつ、
Scansnap OrganizerのOCRにそれなりに満足していたので、ずるずると使い続けてきたが、
思い立ってPDFelementを導入してみたら、誤認識率が体感1％くらいになった
精度の低いOCRをかけたPDFの山を前に、これも一種のバッドノウハウだったと思う
210:
25/12/25 14:27:27.73 .net
AI的OCRってハルシネーションあるんでは
211:名無しさん＠お腹いっぱい。
25/12/26 20:50:04.51 .net
OCRはディープラーニングではあってもLLMではないので
ハルシネーションは関係ないっぽい（Grok情報）
212:名無しさん＠お腹いっぱい。
25/12/27 02:38:10.86 .net
gemini3に聞いてみた：
AIによるOCR（光学文字認識）において、ハルシネーション（もっともらしい嘘をつく現象）は**「確実に起こります」**。
従来のOCRが単なる「文字のパターンの切り出し」だったのに対し、近年のAI（特にDeep Learningや大規模言語モデルを活用したAI）によるOCRは、文脈を理解しようとする性質があるため、存在しない文字を勝手に生成してしまうリスクを孕んでいます。
213:名無しさん＠お腹いっぱい。
25/12/27 02:46:32.27 .net
>>212
AIによるOCRにおいて、ハルシネーションは**「起こり得る」どころか、AIの高性能化（文脈理解の向上）に伴って、より巧妙で気づきにくい形で発生するようになっています。** 「100%正確」と過信せず、特に数値や固有名詞を扱う場合は、人間による確認（Human-in-the-loop）や、バリデーションチェックの仕組みを構築することが不可欠です。
214:名無しさん＠お腹いっぱい。
25/12/29 20:51:13.41 .net
Gemini3に聞いてみたが、そっちのGeminiの言ってるOCRって括弧付きの『OCR』なんじゃない？
こっちのGeminiが言うには、LLMのマルチモーダルモデルの文字認識は、
実際はOCRではなく視覚的文書理解（Visual Document Understanding）というもので、
本来のOCRのように文字を一文字ごとに切り出すのではなく、画像を決まったサイズに分割し、
それぞれの画像単位にベクトル化処理を施し、LLMとして処理するらしい
だからこそハルシネーションが起きる
『OCR』（実際はVDU）にハルシネーションが起きるのは、LLMだからその通り
ただOCRと『OCR』は似て非なるものなので、OCRではハルシネーションは起きない
というか、文字単位に切ってから認識してるんだから、
文脈レベルの処理で生じてくるハルシネーションなんて起きようがない
215:名無しさん＠お腹いっぱい。
25/12/29 21:40:46.38 .net
DeepSeek-OCRにはランダム文字列が読めない - きしだのHatena URLﾘﾝｸ(share.google)
216:名無しさん＠お腹いっぱい。
25/12/30 00:31:09.18 .net
AI OCRでハルシネーションが起こるメカニズム
従来のOCRは、一文字ずつ画像を切り出し、既存のフォントデータと照合する手法が主流でした。
最新のAI OCR（特にTransformerやAttentionメカニズムを用いたモデル）は、以下のプロセスでハルシネーションを引き起こす。
文脈補完（Contextual Filling）
AIは「画像として見えているもの」だけでなく、「統計的に次に来る可能性が高い文字」を予測する。
例: 「東京○」というかすれた画像があった場合、AIは○の部分を読み飛ばすのではなく、文脈から「東京都」と補完する。
リスク: これが「東京都」ではなく、実際には「東京支店」の場合でも、AIが「東京都」と誤って書き換えてしまうことがある。
視覚的特徴の誤認（Visual Misinterpretation）
AIはノイズ（汚れ、折れ曲がり、裏写り）を文字の一部として解釈しようとする。
例: 紙のシミを「、」や「。」と認識したり、数値を読み取る際に、汚れを「1」や「7」と誤認して存在しない桁を生成する。
217:名無しさん＠お腹いっぱい。
25/12/30 11:14:27.90 .net
そもそもAIに聞いた回答自体ハルシの可能性定期
AIは自分の仕様を正しく説明できない
218:名無しさん＠お腹いっぱい。
25/12/31 00:40:41.47 .net
grokってやっぱ娯楽用なんやな
219:名無しさん＠お腹いっぱい。
26/01/23 21:59:47.87 .net
RAGにドキュメントに書いてあるはずのことを聞いても
ベクトル検索によるretrieveの段階でドキュメントがヒットせず、
当然の結果としてアカン回答になる件だが、
たとえドキュメント群が日本語であっても質問を英語にすればベクトル検索の結果がまともになると気づいた（Logicallyで確認）
Grokに聞いたら、多言語対応のLLMであっても学習データの分布は英語が圧倒的なので、
英語l以外の言語だとクエリのエンコード（ベクトル化処理）が微妙になりがちらしい
日本語ドキュメントを英語クエリで検索できるということは、
日本語ドキュメントのベクトル化には成功しているということだが、
なぜ日本語クエリのベクトル化は微妙になりがちなのか？
そこは文章の長さがものを言うらしい（クエリは文章として短すぎる）
いずれにしろ、セマンティック（意味ベースの）な検索とはこういうものかと実感した
表記の同一性なんてほとんど無意味なんやなって
220:名無しさん＠お腹いっぱい。
26/03/12 22:43:38.94 .net
AIで色々なものが作りやすくなった今、作りたいものって何だろう？と考えた時
LLMを活用したIMEかな？と思ったものの、そのハードルはかなり高そうで、
ATOKダイレクトでLLMを呼び出したりするか？と思ったが、
結局、ATOKの省入力辞書データをLLMに補完してもらうという単純かつ泥くさいやり方に逢着した
「このリストに追加すべきワードをリストアップして下さい」という質問を繰り返して、
周辺のワードを増やしていく
この作業には、IMEの環境整備という意味以上に、既有知識を拡げていくという意義があると感じる
LLMに提示されたワードを確認せずに追加することはなくて、調べてから追加していくので。
既にある知識でやりくりしがちなので、こういう知識を拡張していく習慣は有意義だと感じる
221:名無しさん＠お腹いっぱい。
26/03/13 05:57:14.62 .net
句読点もバラバラで読みにくい長文になっておりますので、AIで簡潔にまとめてから投稿していただけると助かります。
222:名無しさん＠お腹いっぱい。
26/03/20 13:59:21.72 .net
>>221
自分以外の人にAIの文章を差し出すようになったら終わりやろ
「あっ・・はい、分かりました（あなたの人間性が）」ってなる
端から信頼なんて求めていない相手ならいいが、
信頼していた人間がAI文を投げてきた時の絶望感はいかほどか―
このAI社会に人はあまりにも自分の信頼を放擲しすぎよな
223:名無しさん＠お腹いっぱい。
26/03/20 14:21:54.82 .net
もっとも、YoutubeのAI生成系コンテンツは全然普通に、むしろ結構な頻度で観ているが
結局のところ、自分の文章の体でAIの文章を出すか
最初から「これはAI生成コンテンツです」の文脈でそれを出すかの違いなんやろね
224:名無しさん＠お腹いっぱい。
26/03/20 19:02:30.63 .net
>>222
そういう精神論はいいから
おまいは毛筆直筆で文をやりとりしていればヨシ
パソコンやスマホで文字を打つなんて誠意のかけらもない軟弱行為は当然していないよね
225:名無しさん＠お腹いっぱい。
26/05/07 21:45:53.99 .net
ポメラのような、集中のためにあえて機能を制限したデバイスとして
電子ペーパーディスプレイを採用したタブレットが使えるのでは？とふと思い立ち
Bigmeの10インチAndroidタブレット（白黒モデル）をこうてみた
操作性はPCと比べると当然かなり落ちるが（それでもキーボードとマウスを接続したら使えるレベルに）
ことディストラクション対策について言えば最高レベルと言っていいと思う
PC作業では、がんばって気を逸らさないようする構えが求められたが、
電子ペーパータブレットでは、集中は自然と生まれるので、意識的な踏ん張りが不要になる
現代人に集中が難しくなっているのはアテンションエコノミーのせいだと言われるが、
発光するディスプレイにも気を散らせる性質があるんやろね
UpNoteやObsidianといった愛用ツールが、そのまま使えるのが良い
むしろ愛用ツールの知られざるよき一面を知った感じで
226:名無しさん＠お腹いっぱい。
26/05/11 05:47:54.99 .net
Obsidianの端末間同期にはRemotely Saveを使っていたが、
PCとe-inkタブレットを頻繁にスイッチする使い方を始めると、
同期がまあまあ遅く複数端末で同期を走らせると新しい方が消えたりもするのが辛くなって、
Self-hosted LiveSyncプラグインに変えてみた
同期用データベースはCloudflare R2にしたが、無料範囲に余裕で収まりそう
挙動を見てると、同期用データベースには編集単位ごとにデータが登録されていく感じなので
一つのノートの同期でもめっちゃデータやりとりするじゃんという印象はあるが、
Remotely Saveよりは速くて、メッセージから何が起きているのか分かるので、かなり環境はよくなった
何も考えなくても使えるというものではなく、それなりに試行錯誤が必要なプラグインだとは思うけど
227:名無しさん＠お腹いっぱい。
26/05/16 18:23:21.75 .net
>>226の件だが、
Self-hosted LiveSyncが、Androidだと端末からサーバにデータを送るっぽいタイミングで落ちるようになってしまったので
Remotely Saveに戻した
プラグインのバージョンを安定してた頃のに戻してみたり、ローカルデータベースをクリアしてみたり、
R2のバケットをクリアしてみたりしたが、無理だった
プロセスの継続性よりもシステムの安定性を重視してプロセスを殺すことに躊躇がないのがモバイルOSだが
AndroidはiOSよりも介入が激しい印象
228:名無しさん＠お腹いっぱい。
26/05/18 16:43:23.56 .net
Androidでバックグラウンド同期させるには、サービスとして動作させるしかないね
ローカルのインデックスを同期するJoplinも同じだわ