3/2の研究日誌で、記事の一覧ページを誤ってピックアップしてしまう問題について、修正を行ったとお伝えしました。しかし、残念ながら、実際には全く改善されていませんでした…。
GPTでは非常に高い精度で判定できていた処理が、Geminiではなぜかフィルターが緩すぎて、何度例示を工夫しても一覧ページがピックアップされてしまう状況でした。
3日間試行錯誤を重ねた結果、以下の対応を行うことで、ようやく精度が向上したように思います。
1. 処理の細分化と独立
まず、処理をさらに細分化し、一覧記事をピックアップする工程を完全に独立した処理として分離しました。
以前は、多くの指示をまとめて記述していたため、どの指示が有効に機能しているのか、どの指示が無視されているのかが分かりにくい状態でした。プロンプトがうまく機能しない場合は、処理を分割してシンプルにすることで、人間にとってもLLMにとっても理解しやすくなり、問題の特定と解決が容易になるようです。
2. 例示の拡充（ルールベース化）
次に、うまく機能しない原因を探るため、GPTに相談したところ、「具体的な指示をさらに列挙する」ようにアドバイスを受けました。そこで、半ばやけくそになりながらも、具体的な指示を大量に列挙しました。
f"以下の文字列はURLです。"
f"{article['link']}\n{'-'*80}\n"
"・上記URLが以下に例示するピックアップの条件に当てはまっている場合は、回答として必ず 'True' とだけ出力してください。\n"
"・条件に当てはまらない場合は、'False' とだけ出力してください。\n"
"【URLのピックアップ対象の条件】\n"
"・URL内に4つ以上数字が含まれているが存在する。 ※数字が/で区切られている場合は無効\n"
"・URLの末尾が数字である。\n"
"例）\n"
"https://example.com/1234 → True\n"
"https://example.com/abcd → False\n"
"https://news.example.ne.jp/list/000/120/xxxxx.html → False ※数字は含まれているが、数字の間が/で区切られており、4桁の連続した数字ではないため対象外\n"
"https://www.example.jp/life/5/19/66/ → False ※数字は含まれているが、数字の間が/で区切られており、4桁の連続した数字ではないため対象外\n"
"【URLのピックアップ対象にならない条件】\n"
"URLの末尾が以下の文字列になっている\n"
"例）\n"
"jp → False\n"
"jp/ → False\n"
"com → False\n"
"com/ → False\n"
"php → False\n"
"php → False/\n"
正直なところ、ここまで詳細な指示を列挙するのであれば、通常のルールベースのプログラムと変わらないのではないか…という思いもよぎりました。しかし、LLMの特性を活かすためには、ある程度のルールベース的なアプローチも必要なのかもしれません。
3. Temperatureの調整
Temperatureパラメータについても見直しを行いました。恥ずかしながら、私はTemperatureの値が大きいほど出力精度も高くなると誤解していました。
実際には、Temperatureは以下のように出力に影響を与えます。
- 低い値（例: 0.0〜0.3）:
- 決定的な出力（同じ入力に対してほぼ同じ応答）。
- 事実重視のタスク（数学、プログラミング、学術的な質問）に適している。
- 創造性は低めで、より確実な答えを選びやすくなる。
- 中程度の値（例: 0.4〜0.7）:
- ある程度のランダム性が入り、出力のバリエーションが増える。
- 自然な文章を生成するのに適している。
- バランスの取れた応答になる。
- 高い値（例: 0.8〜1.5）:
- 出力が多様になり、創造性が増す。
- ただし、意味が通らない、または一貫性のない応答が出る可能性もある。
- 詩や物語の生成など、クリエイティブなタスク向き。
Temperatureの具体的な用途と適切な値
| 用途 | 適切なTemperature |
|---|---|
| 事実ベースの質問応答 | 0.0 – 0.3 |
| コーディング、数学 | 0.1 – 0.3 |
| 一般的な会話 | 0.4 – 0.7 |
| 創作（物語、詩） | 0.8 – 1.2 |
| 完全なランダム性（実験用） | 1.5 以上 |
今回の目的は、出力のブレをなくし、一貫性のある結果を得ることです。そのため、Temperatureの値を0.2に設定しました。今回のような単純な文字列比較であれば、0.0に設定しても良いかもしれません。
4. モデルの変更（これが最も効果的だった可能性）
最後に、モデル自体を変更しました。複雑な処理を行うには高度なモデルが適していますが、今回のケースのように単純な処理を行う場合は、よりシンプルなモデルの方が良い結果をもたらす可能性があると判断しました。
そこで、モデルを「gemini-2.0-flash」から「gemini-2.0-flash-lite」に変更しました。今回の対応の中で、おそらくこれが最も効果があったと考えています。
今後の展望
現時点では、上記の対応により期待通りの結果が得られています。しかし、まだ十分な検証ができていないため、精度の安定性については確信が持てません。
引き続き、パラメータの調整やプロンプトの改善を行い、検証を重ねていく予定です。今後の研究日誌で、さらなるチューニングの結果や新たな知見をご報告できればと思います。
コメント