ローカルAIモデル向けのより良いプロンプトの書き方

ローカルモデルは、最先端のチャット製品を小さくした複製ではありません。役に立つ文脈はより短く、指示への追従は弱く、あいまいな言い方への我慢は少ないです。下の直しは、普通の自宅PCで出力を変えるものです。作業を先に置き、形式を固定し、作業を小さく保ち、プロンプトを平易な言葉で書き、点検が必要な作業にだけ点検を足し、長さを上限で止めます。

これらの型をすぐコピーできる版は ローカルLLM向け最高のプロンプトテンプレートにあります。より長い試験メモは 実際に効くことにあります。

1. 指示を原文より前に置く

多くのローカルモデルは、プロンプトの終わりより始まりを重く見ます。長い記事を貼ってから「要約してください」と言うと、モデルは記事を続けたり、書き出しだけを要約したり、原文の中にあった質問に答えたりします。役割、作業、ルールを先に書いてください。そのあと 本文: のような明確なラベルの下にテキストを貼ります。

効く例

下の本文を箇条書き4つで要約してください。各項目は一文です。助言は足さないでください。 本文: [記事をここに貼り付け]
あなたは Python の見直し役です。バグだけを列挙してください。ファイルは書き直さないでください。 コード: [貼り付け]
下の本文をドイツ語に翻訳してください。URL はそのままにしてください。翻訳のあとに注は付けないでください。 本文: [貼り付け]

反例

[記事二千語を先に貼り付け] ああ、それからこれも要約してもらえますか。良くしてください。

失敗する理由: 指示が遅く、短く、曖昧です。モデルはすでに、記事そのものかのように「読んで」います。「良くしてください」は、良いとは何かを言いません。具体的な要約の指示を最初の行へ移し、「良くしてください」は消してください。

2. 雰囲気ではなく形式に名前を付ける

「良い」「プロらしい」「洞察に富む」のような言葉は形式ではありません。形式は個数、形、または禁止です。ローカルモデルは趣味より、個数と禁止に従うことが多いです。

効く例

ちょうど箇条書き3つで答えてください。 各項目は20語未満です。 前置きは付けないでください。
キーが title と summary の JSON を返してください。 summary は一文です。 マークダウンのコードフェンスは使わないでください。
関数だけを書いてください。 そのあと説明しないでください。 テストは含めないでください。

反例

これを良いプロらしいやり方で要約し、洞察が本当に映えるようにしてください。

失敗する理由: 長さもなく、要点の数もなく、前置きの禁止もありません。見出し、元気な前置き、不揃いな段落五つ、「お役に立てれば幸いです」がよく出ます。個数と文の上限に置き換えてください。

3. 成果物は一つだけ頼む

下書き、翻訳、タイトル一覧、ソーシャルのキャプションを一つのプロンプトで頼むと、作業は四つです。小さいモデルでは、あとの作業が落ちるか、最初の作業に混ざります。分けてください。自分でつなぐことはできます。下書きを受け取り、新しいプロンプトを始め、翻訳だけを頼んでください。

効く例

120語の製品説明を書いてください。説明のあとで止めてください。
次に貼る説明を使って、タイトル案を5つ、1行に一つ、それぞれ8語未満で書いてください。
この顧客メールに90語未満で返信してください。割引は提案しないでください。

反例

スタンディングデスクについてのブログ記事を書き、フランス語に翻訳し、ツイートを10個作り、スライドの概要を設計してください。創造的に。

失敗する理由: 出力が四つで、長さがなく、「創造的に」が一貫性とぶつかります。モデルはたいてい短い英語の記事を書き、残りはおおざっぱに示すだけです。プロンプトを四つに分けるか、より大きいモデルがあり出力に番号を付けるなら、多くても二つまでにしてください。

4. プロンプトは出力より簡単な言葉で書く

改まったメモを頼むことはできます。指示そのものは、それでも短い文であるべきです。入れ子の節、重なった否定、システムプロンプトの中の専門語で、小さいモデルは筋を失います。

効く例

改まったメモを書いてください。 読者: 財務チーム。 長さ: 180語。 含めるもの: 費用、日付、必要な決定。 プロジェクトの歴史は含めないでください。
DNS を、新しく来た事務管理者に説明してください。 短い文を使ってください。 例は一つ: ブラウザがサイトを探すこと。 例のあとで止めてください。
パスワードを再設定する手順を列挙してください。 番号を付けてください。 最大6手順。 会社のブランドについての話は省いてください。

反例

通常の段階的推論を引き出す枠組みとは対照的に、潜在的な道具使用の可能性を前提とせず、明瞭さ、関係者との共鳴、認識論的な謙虚さを同時に操作化する、多価でありながら冗長でない成果物を総合してください。

失敗する理由: 指示が作業より難しいです。モデルは専門語をオウム返しにするか、曖昧な作文で固まることがあります。誰のためか、どれだけ長いか、何を含めるかを言ってください。

5. 壊れやすい作業にだけ自己点検を足す

出力が形と一致しなければならないときに、自己点検は役立ちます。JSON、固定した箇条書きの数、散文を含んではいけないコード。気軽な書き換えには役立ちませんし、小さいモデルでは答えの代わりに点検を印刷させることがあります。一行だけ、最後に置いてください。

効く例

キーが name と date の JSON を返してください。 値がなければ null を使ってください。 答える前に、両方のキーがあるか確認してください。なければ JSON を直してください。 点検を説明しないでください。
箇条書きをちょうど5つ書いてください。 4つか6つ書いていたら、5つになるよう一度書き直してください。 箇条書きだけを出力してください。
Python の関数だけを返してください。 下書きに説明があれば、説明を消し、関数を再び返してください。

反例

とても注意深く考え、推論を振り返り、三つの哲学的な視点から自分を批判してから、Sam への誕生日の短い手紙を書いてください。

失敗する理由: 点検が作業より重いです。欲しかったのは手紙です。推論についての段落と、最後に硬い手紙がよく出ます。誕生日の手紙なら、自己点検は省き、語数の上限を置いてください。

6. プロンプトと実行環境の両方で長さを上限にする

プロンプトもアプリも天井を置かないと、ローカルモデルは脱線して長くなります。両方を設定してください。プロンプトでは語数か箇条書きの数を使います。Ollama、LM Studio、Jan では、その数より少し上に最大トークンを置き、最後の文が語の途中で切れずに終わるようにします。プロンプト自体の長さが不安なら、長い原文を貼る前に トークンカウンターに通してください。

効く例

変更を80語から100語で説明してください。 見出しは足さないでください。
箇条書きを4つください。 各項目は一文です。 4番目のあとに止めてください。
コミットメッセージを書いてください。 件名は50文字未満。 本文: 最大2文。

反例

バックアップについて知っていることを全部教えてください。深く入ってください。遠慮しないでください。

失敗する理由: 終わりがありません。ローカルモデルは実行環境の最大トークンに当たるまで一般的なコツを列挙し、しばしば繰り返します。読者と長さを書いてください。「自宅PCの利用者に、バックアップの手順を6つ、それぞれ一文でください。」

短い変更前と変更後

同じ依頼です。一つ目は人がよく打つ書き方で、二つ目は 7B モデルが追える版です。

通話のメモを見て良くしてください。やることも抜き出してください。ありがとうございます
この通話メモを整えてください。 リストは二つだけ返してください。決定と作業。 作業は動詞で始めてください。 担当の名前がなければ「担当: 記載なし」と書いてください。 メモにない作業は足さないでください。 メモ: [貼り付け]

もう一度整えたいなら、同じプロンプトで「もっと良くもしてください」と同じモデルに頼まないでください。整えたメモと、新しい指示一つだけを入れた新しいプロンプトを始めてください。

これでは直らないこと

関連するガイドとツール