知らないのに答えるモデルは機能ではありません。心地よい口調の負債です。私が動かすシステムでは、質問が空で戻ってよいことにしています。役に立つ動きは、箇所がライブラリにあれば引用、なければ拒否です。
まず検索、言葉はあと
型はわざと退屈です。質問を取ります。答えを持ちそうな箇所を見つけます。採点します。どれも主張を実際には支えないなら、止まります。一つが支えるなら、それを使った文の横に箇所を見せます。文が出典ではありません。箇所が出典です。箇所を開けない読者は文を信じられず、信じるよう求めるべきでもありません。
私が動かしている訓練システムはこう作りました。教材が入り、計画は日付を目指し、答えは出典に照らして採点され、復習は内容を忘れる前に来ます。文書への質問もそうあるべきです。根拠があるか、黙るか。当てることはデモでは助けに見え、顧客がそれに従って動いた最初の週に高くつきます。
| 戻ってきたもの | システムが言ってよいこと |
|---|---|
| 主張を支える箇所 | 答え。その箇所が添えられている。 |
| 近くにあるだけの箇所 | 決まっていることはない。何が足りないかを言う。 |
| 該当箇所がない | 拒む。隙間をもっともらしい文で埋めない。 |
| 確信度の低い抽出 | 人のために止まる。モデルにもう一度払って、当てずっぽうにやり直させない。 |
請求と記録は設計の一部
クラウドのモデルはデータを見ます。その前に、データの流れを書きます。どのサービスか、誰の鍵か、月の上限はいくらか。同意は明示です。顧客、価格、注文に触れるものは人を待ちます。呼び出しは記録します。「アシスタントがそう言った」は監査の跡になりません。
これでサイトが誰かの回答欄に入るとは約束しません。順位は別の機械で、その誘因は私が制御しません。制御できるのは、自分のシステムがでっち上げるかどうかです。
流暢さは安い。製品は、開ける箇所だ。
しきい値はプロダクトの決定
「近い」が「足りない」になる点は、誰かが選ばなければなりません。モデルの機嫌には任せません。箇所は、説明できる線を越えるか、答えが差し止められるかです。ユーザーに拒否を説明するほうが、従った手順の中の作り話の一歩を説明するよりましです。線は、本物の質問を見てから調整できます。ゼロから始めてはいけません。デモはそこに住みたがり、デモは何かを言う頻度で採点されるからです。
実行が別の意味で不確かなとき、空のライブラリではなく確信度の低い抽出なら、もっと滑らかに聞こえる再試行に払う代わりに、人のために止めます。滑らかさは正しさではありません。ログは最初の試みを残すので、人は何が取り出され、何が捨てられたかを見られます。
モデルは役に立つように訓練されていて、段落を完成させたがります。アプリケーションはモデルよりぶっきらぼうでなければなりません。閾値、欠けた引用、空の検索。それぞれは答えを返さず、理由を記録する枝です。その枝がなければ、システムはやがてライブラリが支えられない質問に答え、確信があるように聞こえます。
初めて拒否するのを見ると、不具合に感じます。逆です。不具合なのは、自信たっぷりで、どこもクリックできない段落です。
