世の中はゴールデンウィーク。 このような心に余裕があるときにしかなかなか Haskell に取り組めない。 今日は、以前から使ってみたかった Parsec に入門した。 そのメモです。

今回は、 前回の Embeddings の計算を OpenAIのそれではなく、Multilingual-E5-base に代えて RetrievalQA してみます。 なお、RetrievalQA の処理自体は引き続き OpenAI の LLM を使用します。

対象とするコンテンツ（ 現代語訳 徒然草 (吉田兼好著・吾妻利秋訳) ）の準備やコードは （Embeddings 計算を除いて） 前回を踏襲します。

現代語訳 徒然草 (吉田兼好著・吾妻利秋訳)と LangChainをつかって 吉田兼好に人生の悩みを質問してみる。

現代語訳 徒然草 をデータとして RetrievalQA を使うことで、 最終的に次のような質問から回答を得ることができました。

• (質問) その道のプロとしてふさわしい立ち振舞について教えてください。

  • (回答) 「一言芳談」や「和漢朗詠集」など、尊敬すべき先人の言葉や作品を読み、感動することは大切です。しかし、それを自慢したり、栄光を自分のものにしようとするのは愚かです。また、自分の間違いを素直に認め、改善することも大切です。謙虚さと誠実さを持って、道を極めることがプロとしてふさわしい立ち振舞いだと思います。

• (質問) 専門家が陥りがちな間違いや見苦しい行為にはどんなことがありますか？

  • (回答) 「偉い」と思い込み、自分の知識や専門分野について自慢することや、それを知らない人に対して上から目線で語ること。また、自分の専門ではない分野に対しても詳しそうに振る舞うことや、知らないことを偉そうに語ることがあります。このような行為は、専門家としての信用を損ない、見苦しい行為となります。

・・・なかなか興味深い。

リストの各要素に対してマップするというのは簡単。 これと同じことを 木構造 に対して行うにはどうすればいいのか？

Color Classic II

前回のエントリー の改善版です。 Tree クラスが本来不要な情報を保持できるように定義していたことで、 コード全体が冗長になっていました。 そこを改善します。

前回（マークアップテキストのパース、ブロッククオート領域をハンドルする） のエントリーで BlockQuote 領域が入れ子（ネスト）になっていても再帰処理すれば対処できるだろう、などと書いていたので、 それを試した。

マークダウン書式でいえば行頭を "> " からはじめた行は BlockQuote として扱われる。 このような領域を含んだテキストをパースして（たとえば）HTMLに変換したい場合どうすればいいか、ということを考えた。

このようなテキストをパースする場合、一度で変換をすませようとすると難しい。 また、BlockQuote 領域の中にさらに BlockQuote 領域が存在するような場合もありえる。 そのようなことまで想定すれば、一度のパースで変換を完了させるという発想は筋が悪いだろう。

Galaxy Tab S6 Lite / S8+ で使うアプリを書いている。 このアプリ用にボタンが二個ついているペンがほしくなったので、 Wacom One スタンダードペンを購入してみた。 Android 側でボタンが二つとも認識できるか事前に確認せずに入手したので、 せっかく買ったのに・・・という事態になるという不安があったが、大丈夫でした。

それを回避するにはCSVファイルの先頭に BOM をつけるだけです。

解決方法はこれ: https://stackoverflow.com/questions/60873673/how-to-add-a-utf-8-bom-in-kotlin

GIMP Script-Fu を使って 所定のディレクトリ内にある xcf ファイルを png にバッチ変換するというエントリーの追伸です。

PNG形式ではなく JPEG形式で出力する必要が生じたのでそれようのコードを書きました。

ネット上のドキュメントで一覧表をHTMLのテーブルデータとして 掲載されているが、表計算（エクセル）用のデータまたはCSVデータは 提供されていない、という場合の対処方法です。（覚え書き）

GPT-4 Vision API など使えば、そのHTMLまたはそれをPDFにしたデータを アップロードした上で「CSVデータに変換して」といえば済むのかと思ったのですが、 どうやらまだ（今のところは）そこまで簡単にはいかない模様。

ChatGPT Plus であればすでにその手のことができるようになっているかもしれません。試していません。

数年もたてば ブラウザに搭載された AI に「今見ているページをエクセルに変換して」といえば済む世界が来そう。

ただ・・・この手の処理で GPT のような LLM を使う場合の不安は、 一部が間違って変換されても気づかない、という問題です。 人間が手作業でやった場合、間違いが混入することはある（ヒューマンエラー）ので、 その作業を GPT 的なもので代用した場合には、 人間とGPT（的なもの）とどっちが間違い多いか？みたいな問いになるとは思う。

たとえば、データ内に価格情報があった場合に間違った値として変換されると場合によっては悲惨なことになる。

しかし、HTMLのテーブルデータがあるのであれば、 Python + BeautifulSoup を使うことで、CSVへの変換が可能。 この古典的なやり方ならば、 変換用のコードに書いたルール通りにHTMLデータができている限りは 変換後のデータに間違いないと確信できる、 という点において GPT的方式より優れている。