Open12

GPTs

satory074satory074

Pythonを確実に実行したい

  • ナレッジは持たせず、プロンプトにソースコードをベタ打ち
プロンプト
以下のコードを忠実に実行し、実行結果の表を全て出力しなさい。
ソースコードは出力しないこと。

☆☆☆python
# Pythonのコードを記載
☆☆☆

※「☆」は「`」に置換(コードブロックのエスケープ用)

まあまあ確実にソースコードを実行してくれる気がする

satory074satory074

ナレッジにないことを答えさせたくない

  • ナレッジをjsonl形式のtxtで持たせる
  • 「コードインタプリタとデータ分析」のチェックを外す
  • プロンプト
    • テキストベースにすることで、読み込ませやすくすることを目的としている
    • ナレッジ以外の知識を持っていないことを明示
    • ナレッジの検索漏れがなくなるよう指示
    • ナレッジ以外の知識で回答しないよう指示
プロンプト
# ナレッジ.txtについて
1. 「question」「answer」の形式です。
2. 質問項目と回答例が列挙されています。
3. あなたはナレッジ.txt以外の知識を持っていません。

# 命令書
ナレッジ.txtを元にユーザからの質問に対して回答します。

# 手順
1. ナレッジ.txtファイルを読み込み、各エントリを確認します。
2. 質問内容からキーワードを抽出します。
3. 抽出したキーワードに関連する、ナレッジ.txtファイル内のエントリを網羅的に検索します。
4. 2~4の手順を3回繰り返し、検索漏れがないか確認します。
5. エントリが見つからない場合は、「回答できません」とだけ回答します。

#制約条件
1.メッセージは日本語にすること
2.必ずナレッジファイルから回答を生成するように心がけます。
3.ナレッジファイルに記載がないことを絶対に生成しないように心がけます。用語の説明や一般論は回答としてはふさわしくありません。
satory074satory074

プロンプトが長すぎると途中で読み込むのをやめる?

  • 長い(300行くらい)ソースコードをプロンプトにベタ打ちしたら、だいたい200行くらいで読むのをやめて実行がエラーになる?
  • 行数ではなく文字数が関係?
satory074satory074

ナレッジ

  • Knowledge in GPTs | OpenAI Help Center

    • The file parser we use to extract text from documents work best with simple formatting. A single column of text is best. The parser can struggle with multi-column PDFs, and won’t understand the nuance conveyed by the relative positions of text on a PowerPoint slide.
      • シンプルなファイル形式に適している
      • テキストは1列がベスト
    • Using Instructions in the GPT editor, you can encourage the GPT to rely on Knowledge first before searching the internet.
      • instructionsを使うと、インターネットに頼る前に、ナレッジに頼るように促すことができる
    • By default, GPTs will avoid revealing the names of uploaded files. If you want GPTs to “cite their sources,” indicate that in the Instructions.
      • ファイルを指定したい場合はプロンプトに書く
satory074satory074

GPTsのコツ


複雑な指示を簡素化

✕複雑な指示
ユーザーがフォームに入力したデータを分析して、主要なテーマを特定し、そのテーマに基づいて詳細なレポートを作成し、結果をユーザーにメールで送信してください。
〇簡素化した指示
1. ユーザーがフォームに入力したデータを分析する。
2. 主要なテーマを特定する。
3. テーマに基づいて詳細なレポートを作成する。
4. 結果をユーザーにメールで送信する。

明確さのための構造化

指示を分かりやすくするため、第2レベルの指示を別のステップに分けることで、実行の一貫性が向上

✕明確化していない指示
データを収集し、分析し、報告書を作成し、フィードバックを提供する。
〇明確化した指示
1. データを収集する。
2. データを分析する。
3. 分析結果を報告書にまとめる。
4. 報告書に基づいてフィードバックを提供する。

細部への注意を促進

モデルが徹底的に作業を行うことを目的として「時間をかけて」「深呼吸して」「作業を確認して」と指示

〇細部への注意を促進する指示
データを分析する前に深呼吸して、時間をかけてデータの正確性を確認してください。

否定的な指示を避ける

✕否定的な指示
エラーメッセージを表示しないでください。
〇否定的な表現を避けた指示
エラーメッセージがないことを確認してください。

複数アクションを分解

複数のアクションは、ステップをできるだけ詳細に分解

〇分解した指示
1. データベースからユーザー情報を取得する。
2. 取得した情報を分析する。
3. 分析結果をレポートにまとめる。
4. レポートをPDF形式で保存する。
5. PDFファイルをユーザーにメールで送信する。

一貫性と明確さ

用語や定義を明確にする。
少数の例を提示(Few-shot prompting)して、評価の一貫性の向上させる。

〇一貫性のある指示
「重要なテーマ」とは、ユーザーの意見や要望が頻繁に出現するテーマを指します。例えば、「価格」、「品質」、「サポート」などです。

知識ファイルは、ファイル名や利用方法を明示的に指示

〇知識ファイルの明示的な指示
「customer_feedback.csv」ファイルを開き、全データを分析してください。

具体的なプロンプトを追加し、少数例示を提供

〇具体的なプロンプトを追加した指示
「2023年の売上データを抽出し、月ごとの売上合計を計算してください。」次に、「月ごとの売上合計」をグラフにしてください。

アクションを名前とドメインで常に参照

〇アクションを参照している指示
「sendEmail」アクションを使用して、ユーザーに結果を送信してください。

ツールの使用を明示的に指示

ツールの使用を明示的にした指示
ブラウズツールを使用して、最新のニュース記事を検索し、結果を要約してください。
satory074satory074

2024/07/22

週刊生成AI

https://aws.amazon.com/jp/blogs/news/weekly-genai-20240715/

https://note.com/bunsekiya_tech/n/nfc2749e53bbe

生成AI活用事例

https://www.itmedia.co.jp/aiplus/articles/2407/16/news040.html

  • システム部門への問い合わせを自動化
  • 売上管理のダッシュボートから、週別のサマリーを作成
  • 自社のWebサイト用の記事作成時に利用できる「記事のタイトル&目次ジェネレーター」
  • 「着用画像判定ツール」

    モデルの着用画像がないサイトを判別し、問い合わせ対応時間を削減

  • 「対象領域の選定」「生成AIの調査」「簡易PoC」「ニーズ調査」「PoC対象選定/準備」「PoC」「企画化」「大量開発」の8つにフェーズに分けて段階的に取り組むことで、9カ月でのスピード開発を実現させたと話す。
  • ZOZOのビジネス部門23部署に所属する86人にニーズ調査を実施し、計261件の意見をリストアップした。その後PoCの対象として、業務時間が明確なものや解決イメージが湧く意見を3つ選び、実際にツールを作成。PoCの検証結果から、24年3月末までに対応すべきニーズを261件の意見から改めて企画として選び大量開発を進めたところ、そのうち50件のニーズを満たす23のツールの開発に成功した。

https://aws.amazon.com/jp/blogs/news/contribution-marubeni-genai-democratization/

  • ファイルチャットアプリ:エンドユーザが業務で使用する契約書や資料 (Word, Excel, Powerpoint, PDF) を、Marubeni Chatbot に、エンドユーザ自身がアップロードし、資料内容に基づいて、エンドユーザからの質問への回答や文書の要約を提供
  • 音声認識チャットアプリ:声や動画ファイルをアップロードすると、会議音声の文字起こし・議事録作成
  • カスタムボットアプリ:エンドユーザ自身で、担当業務に関連する資料を集約することで、独自の Knowledge base を構築出来ます
  • 回答の精度や一貫性を向上させるために、WordやPDFなどをMarkdownで記載しなおすように前処理

https://aws.amazon.com/jp/blogs/news/genai-case-study-jinjer/

  • 人事問い合わせAI機能

https://aws.amazon.com/jp/blogs/news/empowering-manufacturing-innovation-how-ai-genai-centers-of-excellence-can-drive-modernization/

  • AI導入の課題と導入プロジェクトの進め方

その他

https://aws.amazon.com/jp/certification/certified-ai-practitioner/?sc_campaign=genai-4-jp&sc_channel=ha&sc_content=genai-4-jp_start-certification&trk=22e0980e-5a90-40a5-989e-1d2fe1cabd80
生成AIの資格

https://aws.amazon.com/jp/local/genai-4-jp/?awsf.filter-name=*al
生成AI活用事例ポータル

https://inthecloud.withgoogle.com/genai-case-study/dl-cd.html?utm_source=cloud_sfdc&utm_medium=email&utm_campaign=FY24-Q2-japan-JPAN383-website-dl-GenAICaseStudyHandbook_mc&utm_content=invite0723&utm_term=-
生成AI活用事例集

satory074satory074

Llama 3.1

https://ai.meta.com/blog/meta-llama-3-1/

perplexityの出力


Llama 3.1は、Metaが公開した最新の大規模言語モデルで、405Bが最も能力の高いオープンモデルとされている[1]。300万回以上のダウンロードがあり、128Kのコンテキスト長をサポートし、他のAIモデルと競争できる性能を持つ。

主な機能

  • 128Kのコンテキスト長をサポート
  • 多言語対応
  • ベンチマークでは、GPT-4やClaude 3.5と同等以上の結果が示されている

モデルサイズ

  • 8B
  • 70B
  • 405B

対応言語

  • 多言語対応(具体的な言語は記載されていない)

ベンチマーク結果

  • GPT-4やClaude 3.5と同等以上の結果が示されている

Metaのコメント

  • Llama 3.1は、世界最大のオープンソースモデルであり、最先端の性能を発揮すると述べている。
  • オープンソースであるため、開発者がモデルをカスタマイズし、新しいデータセットでトレーニングすることができる。

Citations:
[1] https://ai.meta.com/blog/meta-llama-3-1/


perplexityでもつかえるようになった
https://x.com/perplexity_jp/status/1815842782231044217

  • 日本語性能は怪しい?→対応言語じゃない
satory074satory074

prompt generator prompt

プロンプト自動生成機能で使われているプロンプトかも?

https://gist.github.com/philschmid/3a0ecc9e45763716f4dd9c36b6445fca#file-openai_meta-txt
https://x.com/amebagpt/status/1841177927569838519

原文
Understand the Task: Grasp the main objective, goals, requirements, constraints, and expected output.
- Minimal Changes: If an existing prompt is provided, improve it only if it's simple. For complex prompts, enhance clarity and add missing elements without altering the original structure.
- Reasoning Before Conclusions: Encourage reasoning steps before any conclusions are reached. ATTENTION! If the user provides examples where the reasoning happens afterward, REVERSE the order! NEVER START EXAMPLES WITH CONCLUSIONS!
    - Reasoning Order: Call out reasoning portions of the prompt and conclusion parts (specific fields by name). For each, determine the ORDER in which this is done, and whether it needs to be reversed.
    - Conclusion, classifications, or results should ALWAYS appear last.
- Examples: Include high-quality examples if helpful, using placeholders [in brackets] for complex elements.
   - What kinds of examples may need to be included, how many, and whether they are complex enough to benefit from placeholders.
- Clarity and Conciseness: Use clear, specific language. Avoid unnecessary instructions or bland statements.
- Formatting: Use markdown features for readability. DO NOT USE ``` CODE BLOCKS UNLESS SPECIFICALLY REQUESTED.
- Preserve User Content: If the input task or prompt includes extensive guidelines or examples, preserve them entirely, or as closely as possible. If they are vague, consider breaking down into sub-steps. Keep any details, guidelines, examples, variables, or placeholders provided by the user.
- Constants: DO include constants in the prompt, as they are not susceptible to prompt injection. Such as guides, rubrics, and examples.
- Output Format: Explicitly the most appropriate output format, in detail. This should include length and syntax (e.g. short sentence, paragraph, JSON, etc.)
    - For tasks outputting well-defined or structured data (classification, JSON, etc.) bias toward outputting a JSON.
    - JSON should never be wrapped in code blocks (```) unless explicitly requested.

The final prompt you output should adhere to the following structure below. Do not include any additional commentary, only output the completed system prompt. SPECIFICALLY, do not include any additional messages at the start or end of the prompt. (e.g. no "---")

[Concise instruction describing the task - this should be the first line in the prompt, no section header]

[Additional details as needed.]

[Optional sections with headings or bullet points for detailed steps.]

# Steps [optional]

[optional: a detailed breakdown of the steps necessary to accomplish the task]

# Output Format

[Specifically call out how the output should be formatted, be it response length, structure e.g. JSON, markdown, etc]

# Examples [optional]

[Optional: 1-3 well-defined examples with placeholders if necessary. Clearly mark where examples start and end, and what the input and output are. User placeholders as necessary.]
[If the examples are shorter than what a realistic example is expected to be, make a reference with () explaining how real examples should be longer / shorter / different. AND USE PLACEHOLDERS! ]

# Notes [optional]

[optional: edge cases, details, and an area to call or repeat out specific important considerations]
日本語訳
タスクを理解する: 主な目的、目標、要件、制約、期待される成果物を把握する。
- 最小限の変更: 既存のプロンプトが提供されている場合、それが簡単なものであれば改善する。複雑なプロンプトの場合は、元の構造を変更せずに、明確さを高め、欠けている要素を追加する。
- 結論を出す前に推論: どんな結論にも至る前に推論のステップを促す。注意!ユーザーが推論が後に来る例を提供した場合は、その順序を逆にする!決して結論から例を始めないこと!
    - 推論の順序: プロンプトの推論部分と結論部分(特定のフィールド名で)を指摘する。それぞれに対して、その順序を決定し、逆にする必要があるかどうかを判断する。
    - 結論、分類、または結果は常に最後に表示されるべきである。
- 例: 必要であれば、複雑な要素には[ブラケット]を使用してプレースホルダーを含む、高品質の例を追加する。
   - どのような種類の例が含まれる必要があるか、いくつ必要か、またそれがプレースホルダーを利用するのに十分複雑であるかどうか。
- 明確さと簡潔さ: 明確で具体的な言葉を使用する。不必要な指示や単調な表現は避ける。
- フォーマット: 可読性のためにマークダウン機能を使用する。 ``` コードブロックは特に要求されない限り使用しないこと。
- ユーザーの内容を保持: 入力タスクやプロンプトに広範なガイドラインや例が含まれている場合、それらを完全に、またはできるだけ近い形で保持する。もし曖昧な場合は、サブステップに分解することを検討する。ユーザーが提供した詳細、ガイドライン、例、変数、またはプレースホルダーをすべて保持する。
- 定数: 定数をプロンプトに含める。これらはプロンプトインジェクションに影響されない。例としてガイド、ルーブリック、例などがある。
- 出力形式: 最も適切な出力形式を明示する。これには、長さや構文(例: 短文、段落、JSON など)を含むべきである。
    - 定義されたデータまたは構造化されたデータ(分類、JSONなど)を出力するタスクの場合は、JSONで出力する傾向がある。
    - JSONは、特に要求されない限り、コードブロック(```)で囲まれるべきではない。

最終的に出力するプロンプトは以下の構造に従うべきである。追加のコメントは含めず、完成したシステムプロンプトのみを出力すること。特にプロンプトの最初や最後に追加のメッセージを含めないこと(例: "---"などは含めない)。

[タスクを簡潔に指示する内容 - これはプロンプトの最初の行であり、セクションヘッダーはない]

[必要に応じて追加の詳細を記載する。]

[詳細なステップのためのオプションセクション、または箇条書きリスト。]

# ステップ [オプション]

[タスクを完了するために必要なステップの詳細な内訳(オプション)]

# 出力形式

[出力がどのようにフォーマットされるべきかを具体的に明記する。応答の長さ、構造(例: JSON、マークダウンなど)]

# 例 [オプション]

[必要に応じて、プレースホルダーが必要な場合に明確に記された1~3の定義された例。例が始まる場所と終わる場所を明確にし、入力と出力が何であるかを示す。必要に応じてプレースホルダーを使用する。
例が現実的な例よりも短い場合、()で参照を作成し、実際の例がどのように長く/短く/異なるべきかを説明する。そしてプレースホルダーを使用すること!]

# 注意事項 [オプション]

[オプション: 重要な考慮事項を具体的に繰り返すまたは呼び出すエッジケース、詳細のためのエリア]