その１ からの続きです。

その１では、 Streamlit で UI だけつくったので、 あとは、実際にプロンプトから OpenAI API 経由で文章を生成させる機能を追加します。

Streamlit で Open AI API を使いデモをつくります。 今回は Open AI API はおいておいて、 Streamlit で最低限のウェブインタフェースをつくるところまでの覚え書きです。

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

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

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

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

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

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

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

そこそこ速いシリコンマックでの、 Controlnet + Stable Diffusion 1.4 を試す。

そこそこ速いシリコンマックでの Stable Diffusion まとめ。

torch_dtype=torch.float16 指定を外すとどうなるか試しました。

そこそこに速いシリコンマックで ELYZA-japanese-Llama-2-7b-fast-instruct を使って クライアントからテキストを投げると JSON文字列 を返すサーバをつくります。

Large Language Model をローカルで動かす時代が到来するらしい。

Reddit には LocalLLaMA というサブレディットがあり、かなり盛り上がっている。 そこでは シリコンマックを使っているひとが結構いる。 Meta の 商用利用も可能な Llama 2 がオープンソースで提供された結果、 その派生プロジェクトがいろいろ存在している。 そのなかには、低スペックの シリコンマックでも LLM を実行できるものがある。 Pytorch もMetal 対応していて、 おそらくは、Pytorch 依存の LLM モデルについては、Linux + CUDA と同じ手順で動かせるのではないかと思う。

Pytorch を使う方法を 手元の M1 Macbook Air 8GB で試したが残念ながら作動しなかった。 たぶんメモリが足りないのだと思う。 十分メモリがあれば動くのではないかと思うが定かではない。

それでも Llama.cppと軽量化されたモデルを使うことで M1 Macbook Air 8GB でも作動させることができた。

このエントリーでは、Linux + CUDA で、 Llama 2 をベースに商用利用可能な日本語LLM ELYZA を試します。

Python Web Framework の Bottle で GET/POST する方法を確認します。 その後、React からPOSTを使うところまでの備忘録です。

支給されたデータのうち特定の列だけを抜き出して使いたい、という場合に pandas を使ったのでその備忘録です。

こんなエクセルデータがあったとして、これを pandas で処理する。

Word2vec ... いまさら感がありますが、Wikipediaダウンロードから手順を書き残します。

使用した環境は Ubuntu 22.04 LTS です。

Google の Cloud Vision APIの機能のひとつにOCRがあり これを業務で使う機会がありました。 実際に使ってみると、対象が印刷物をスキャンした画像データだったなど条件がよかったのだとは思いますが ほぼOCR処理として100%に近い形でテキストに変換されました。 とはいえ、100%ではないので、そこは人間が一度はすべて確認する必要がありますし、 そもそもOCRで読みとったテキストをこちらが使用したい単位に整理する処理については 当然OCRの守備範囲外になります。 そのため、その部分のコードを書くのが相当に大変でした。

もし人間が目視＆手作業としてテキスト入力すれば、その整理部分も含めて人間が処理することになる。 それがアウトソーシングとしてページ単価いくらで予算の範囲で収まるのであれば、 どうなんだろう。 自分ががんばって書いたコード部分は結局たいした価値があるのだろうか……という微妙な仕事になってしまった。