心構えリスト

LLMを信用してはいけない

LLMがどんな文字を出すかは神のみぞ知る。
機械学習モデルは学習データでトレーニングしなければ意味のない出力をするだけの存在で、長時間じっくりと学習を繰り返すことで「なんかしらんけどいい感じに」意味ありげな出力をする関数である。
クリティカルな部分の自動化に使ってはいけない。欠損値を許容できるシステムであるべき。

基礎設計をおろそかにしてはいけない

LLMは確かに多様なタスクを解くことができる。
それが原因なのか（？）、LLMの関係ないロジックがおろそかにされがちである。
ビジネスロジックは必ずメンバー全員で理解するべき。

LLMの入出力は明確にするべき

アーキテクチャ図にOpenAIのロゴを載せただけで設計した気になるな。
その中でどのような処理をさせるのかは明確にするべき。

LLMを使う理由は？
何をさせるか？
この二つに焦点を合わせて入出力とそれに伴うシステムを設計する必要がある。

安易にチャットUIを作ってはいけない

LLMは人語を真似る従順な猛獣なので、ユーザーの指示を聞いたらその通りに返答します...
「自由度が高くていいね！」...?
これに伴うデメリットが多すぎる

ユーザーが何を入力するべきか迷う
出力が特定できないので、何かに特化した処理が困難
Function Callingをしようにも、利用者が関数の存在を理解していないと適切に呼び出されない
実装が単純に難しい。メッセージとスレッドを保持するのが大変
チャットUIである必要があるなら、まずGPTsとしての開発を検討する。

テストケースと性能指標を設定する

LLMの出力は不安定なので、テストケースは多ければ多いほど良い。
可能であれば同じ入力でも複数行うべきである。GPUの仕組み上、どれだけtemperatureを下げても同じ結果にはならない。
テストケースは開発メンバーにとってもスコープと要件を理解する重要なデータになる。
導入後のモニタリングでも必要なので、必ず適切なものを設定すること。

テスト計画を作る

かんたんに言えばPDCA。
回せるだけ回す。

１．目的
２．理論
３．実験方法
４．実験結果
５．考察

Plan
- 目的
- 仮説設定
- 実験方法
Do
- 実施
Check
- 結果
Act
- 考察

意思決定は数字で行う

データの扱いはLLMがどれだけ進化しても変わらない。
MLモデルに誤差は必ずあるのでざっくり単語だけでも覚える。

よく使う評価指標

MSE, RMSE
- 数値出力で使う
Recall, Precision
- カテゴリ出力で使う
IoU
- 抽出タスクで使う

レポートでよく使う数字

相関係数
p値