Architecture

ライブラリに箇所がなければ、モデルは拒むべきだ

流暢なのにクリックする場所がない答えが、欠陥だ。自分が運用するシステムは箇所を示すか、止まる。

When the library has no passage, the model should refuse

知らないのに答えるモデルは機能ではありません。心地よい口調の負債です。私が動かすシステムでは、質問が空で戻ってよいことにしています。役に立つ動きは、箇所がライブラリにあれば引用、なければ拒否です。

まず検索、言葉はあと

型はわざと退屈です。質問を取ります。答えを持ちそうな箇所を見つけます。採点します。どれも主張を実際には支えないなら、止まります。一つが支えるなら、それを使った文の横に箇所を見せます。文が出典ではありません。箇所が出典です。箇所を開けない読者は文を信じられず、信じるよう求めるべきでもありません。

私が動かしている訓練システムはこう作りました。教材が入り、計画は日付を目指し、答えは出典に照らして採点され、復習は内容を忘れる前に来ます。文書への質問もそうあるべきです。根拠があるか、黙るか。当てることはデモでは助けに見え、顧客がそれに従って動いた最初の週に高くつきます。

戻ってきたものシステムが言ってよいこと
主張を支える箇所答え。その箇所が添えられている。
近くにあるだけの箇所決まっていることはない。何が足りないかを言う。
該当箇所がない拒む。隙間をもっともらしい文で埋めない。
確信度の低い抽出人のために止まる。モデルにもう一度払って、当てずっぽうにやり直させない。

請求と記録は設計の一部

クラウドのモデルはデータを見ます。その前に、データの流れを書きます。どのサービスか、誰の鍵か、月の上限はいくらか。同意は明示です。顧客、価格、注文に触れるものは人を待ちます。呼び出しは記録します。「アシスタントがそう言った」は監査の跡になりません。

これでサイトが誰かの回答欄に入るとは約束しません。順位は別の機械で、その誘因は私が制御しません。制御できるのは、自分のシステムがでっち上げるかどうかです。

流暢さは安い。製品は、開ける箇所だ。

しきい値はプロダクトの決定

「近い」が「足りない」になる点は、誰かが選ばなければなりません。モデルの機嫌には任せません。箇所は、説明できる線を越えるか、答えが差し止められるかです。ユーザーに拒否を説明するほうが、従った手順の中の作り話の一歩を説明するよりましです。線は、本物の質問を見てから調整できます。ゼロから始めてはいけません。デモはそこに住みたがり、デモは何かを言う頻度で採点されるからです。

実行が別の意味で不確かなとき、空のライブラリではなく確信度の低い抽出なら、もっと滑らかに聞こえる再試行に払う代わりに、人のために止めます。滑らかさは正しさではありません。ログは最初の試みを残すので、人は何が取り出され、何が捨てられたかを見られます。

モデルは役に立つように訓練されていて、段落を完成させたがります。アプリケーションはモデルよりぶっきらぼうでなければなりません。閾値、欠けた引用、空の検索。それぞれは答えを返さず、理由を記録する枝です。その枝がなければ、システムはやがてライブラリが支えられない質問に答え、確信があるように聞こえます。

初めて拒否するのを見ると、不具合に感じます。逆です。不具合なのは、自信たっぷりで、どこもクリックできない段落です。