生成AIのアプリケーション開発をするライブラリであるLangChainについて、いくつかのバージョンアップなどもあり昔の機能が非推奨になったり、様々な更新などがあったため、公式のドキュメントを漁っていてlangchainでモデル呼び出す際の入力について気になったことがあったので詳しく調べてみました。
モデルの呼び出し方
ドキュメントによると次の呼び出し方を実施しています。
|
invoke関数がモデルの呼び出しを行うもので、引数としては文字列が入力されています。
これは入力した文字列がgpt-4o-miniに送られているのだろうと想定されますので、理解は難しくないです。
しかし、チュートリアルでは以下のような呼び出しになっています。
|
これは2つのメッセージクラスのリストを入力しています。これも会話をリスト形式で保持しているのだろうとは想像できますが、次の形はどうでしょうか。
|
|
|
上記チュートリアルにも記載されていますが、上記はいずれも同じ処理が行われます。
入力方法が多岐に渡っているので、実際どんな入力がサポートされているのか確認してみましょう。
ドキュメントを読むとLanguageModelInputが想定されているようです。
ライブラリを見ていくと次のような形で定義されています。
|
つまりPromptValue, str, Sequence[MessageLikeRepresentation]のいずれかが入力されることを期待しているということです。
先ほどの例がそれぞれどれに当てはまるのかというと
model.invoke("Hello"):strmodel.invoke([{"role": "user", "content": "Hello"}]):Sequence[MessageLikeRepresentation]model.invoke([HumanMessage("Hello")]):Sequence[MessageLikeRepresentation]
上記のようになります。
PromptValueは?というとプロンプトテンプレートを使った場合はこの入力に当てはまります。
|
実験
以下のコードは実行できるでしょうか?
|
これは動作しましたが、上記の指定の中にはない形です。
実際どのように動いているのか気になったのでソースコードを確認してみました。
まず、invokeの実装から見てみます。今回気になった部分はinputの部分なのでそこにフォーカスしてみます。
|
入力はconvert_inputによって別の値に変換されています。そっちも見てみましょう。
確認したかった部分はここですね。
|
この関数ではLanguageModelInputをPromptValueに変換しています。
PromptValueはそのまま- 文字列はStringPromptValueへ
Sequenceは入力をconvert_to_messagesで変換しChatPromptValueに
上の2つはすんなり理解できます。最後の関数も見てみましょう。
|
この関数が呼び出される場合はPromptValueのインスタンスではなくSequenceのインスタンスのはずなので、そこを見てみます。下記の通りリストやタプルの各要素を変換しています。
|
ドキュメントにも記載されている通り、フォーマットに従った内容であれば下記の通り変換がされるようです。
- メッセージクラスはそのまま
- 文字列はHumanMessageへ変換
Sequenceかつ要素数が2なら、1つ目の要素をロール、2つ目の要素を値にしたメッセージクラスへ変換- 辞書型ならrole要素かtype要素をロール、content要素を値にしたメッセージクラスへ
ここで先ほどの入力がどうなっていたか見てみましょう。
|
先ほどの入力ではSequenceであるタプルの中に文字列が含まれていたので、_convert_to_messageではHumanMessageへの変換がされていることになります。
つまり、ここで処理されているのは下記と同一だったわけです。
|
ソースコードの確認は深い理解のためには重要ですね。
おまけ
今回の実験のためにいろいろ試していたのですが、その際、出力が微妙に異なるパターンがtemperatureが0に指定されているのにも拘らず発生してしまいました。誤差が大きいときでは100トークン前後の誤差が生じていました。
その原因としてはGPUでの計算のリアルタイム最適化の結果、演算順序が変動することで浮動小数点での誤差が発生してしまうためのようです。
これは生成したトークンから次のトークンを生成していく連鎖によって動作するLLMにとっては最終的に大きな誤差が生まれ得ることを意味しています。
これはGPUによる演算を最適化している都合上起こり得るものなので、回避は難しいです。
参考:The New World of LLM Functions: Integrating LLM Technology into the Wolfram Language (2025/1/30閲覧)






