(JSConf JP 2023) LLM (大規模言語モデル) 全盛時代の開発プラクティス

LLM (大規模言語モデル)  全盛時代の  開発プラクティス  baseballyama 

自己紹介 (baseballyama)  • 株式会社フライル  ◦ TypeScript / Vue / Svelte 
◦ Kotlin / Spring Boot  ◦ Python / Fast API / Open AI  ◦ AWS / Terraform  ◦ MySQL / Fargate / S3 / SQS / その他     • Svelteコアチームメンバー   ◦ Svelte5に向けて活動中 (できる範囲で)  ▪ Svelte コンパイラのバグ修正  ▪ ESLint Parser の Svelte 5 対応  ▪ ESLint Plugin の Svelte 5 ルール追加  ▪ コミュニティからの質問対応     • その他  ◦ 本業では5月からLLM系の機能を主に担当しています  

始める前に  JavaScript の話  薄めです。すみません。 

1. GitHub Copilot の話  2. AIツールによる更なる効率化  a. 理想と現実  i. AIレビューツール 
ii. Figma to Code  b. 理想と現実のギャップを埋める方法  i. AIレビューツール  ii. Figma to Code  c. ギャップを埋める実装ステップ  i. 実装する前に...  ii. 実装ステップ  3. まとめ  アジェンダ 

1. GitHub Copilot の話 

⚡アンケート⚡    GitHub Copilot 使ってますか? 

個人的所感  • 少しタイピングしたら数秒待って、サジェストされたコードをとりあえず Accept してその後精査する、という流れが基本になった  (Vue.js / TypeScript /
独自ユーティリティ有でも問題なくサジェストされる)    • 実装が面倒なユーティリティ関数はコメントだけ書いて GitHub Copilot に実装して貰う、という場面も増えた    • 飛行機などネットが使えないと GitHub Copilot が使えなくて辛い    • Svelteコンパイラみたいな参考にできるコードが少ない系のプロジェクトではあまり採用できない感覚 

GitHub Copilot のサジェスト方法の説明  const で統一  function で統一  const と function
混在 

GitHub Copilot のサジェスト方法の説明  • GitHub Copilot は現在開いているファイルを参考にサジェストする仕組みのようです    •
よって、既存の実装が (不必要に) 統一されていない場合、サジェストの精度が落ちてしまいます 

コードの書き方の変化  • つまり、「統一感」を重視している開発チームの場合、「統一感」はこれまでにも増して重要になります。  コードベースに統一感がない場合、GitHub Copilot がサジェストするコードも統一感がなくなり、コードベースの統一感のなさが加速します。  • (脱線:
外在性認知負荷) 個人的には「統一感」はチーム開発において重要な要素だと考えています。例えば、先ほどの const vs function の例の場合、なぜここは const を使用しているのだろうか、なぜここは function を使用しているのか、という疑問を持つ開発者が出ることが予想されます。これは「外在性認知負荷」と呼ばれます。つまりコーディングで達成したい目標と直接関係のない負荷です。このような認知負荷は少ないほど良いはずです。  

どうやって統一感を獲得するか  • ESLint などの静的検査ツールを徹底的に活用しましょう  ◦ 必要に応じて ESLint のカスタムルールを作りましょう  ◦ ESLint
のカスタムルールを作る時間がない場合は  一旦AIを使用したレビュープロセスを導入しましょう (詳しくは後述)    • 過去の資産が多いなどの理由で既に統一感がない場合は  ◦ まずはコーディングルールを策定しましょう  ◦ ESLint の autofix などを活用して一括でリファクタリングしましょう  ◦ 一括で対応するのが難しい箇所は、コードにTODOを貼りましょう 

先ほどの function にTODOを貼ると... 

まとめ  • GitHub Copilot は現在開いているタブのコードを参考にする  • 良いサジェストを得るにはコードの統一感が重要  • 統一感を獲得するためにはESlintなどの静的検査を導入する  ◦
すぐにできない場合はTODOを貼るだけでも有効 

統一感は大事 

時間配分  ヨシッ 

1. a  2. AIツールによる更なる効率化 

例えば...  AIレビューツール 

最近流行りのAIレビューツールを使ってみた  Figma to Code  AIレビューツール 

最近流行りのAIレビューツールを使ってみた    「テストを追加しよう」とか「コメントを書きましょう」   とかごく一般的なことしか指摘してくれなかった。     テストは別の方法で対処しているので問題ないし、コメントはほとんどの場合はコメントを読めばわかるので、不必要に書く必要はないと考えている。  
  もっと実際に役立つ指摘をして欲しい。   Figma to Code  AIレビューツール 

最近流行りのAIレビューツールを使ってみた  理想 : 自社のルールやコンテキストを踏まえてレビューして欲しい  現実 : 一般的な指摘に終始する  Figma to Code 
AIレビューツール 

(参考) LLMを使用したレビュー支援ツール  • PR-Agent (https://github.com/Codium-ai/pr-agent ) (⭐2.6K)  • AI-based PR
reviewer and summarizer (⭐1K)  (https://github.com/coderabbitai/ai-pr-reviewer )  • chatgpt-action (⭐556) (https://github.com/kxxt/chatgpt-action#chatgpt-action )  • ChatGPT Code Review (⭐191) (https://github.com/domvwt/chatgpt-code-review#chatgpt-code-review )  • AI Code Reviewer (https://github.com/freeedcom/ai-codereviewer ) (⭐144)  Figma to Code  AIレビューツール 

例えば...  Figma to Code 

Figma to Code  • 自社特有のデザインシステムがあるから単に HTML / CSS が出てきても困る   
• Figma公式のコード生成はReactのみ    • Builder.io は色々なライブラリに対応している  しかし自社向けなカスタマイズがどこまでできるかは不明  Figma to Code  AIレビューツール 

Figma to Code  理想 : 自社のコンテキストを踏まえたUIコンポーネントを出力して欲しい  現実 : コンテキストを踏まえないUIコンポーネントが出力される  Figma
to Code  AIレビューツール 

AIツールの理想と現実  現実の業務でAIツールを活用するには、AIツールは自社特有のコンテキストを理解する必要があるが、現時点でこれを達成しているツールはあまりないと理解しています。    これは以下2つのどちらかの方法で解決する必要があります  1. 自動的に自社特有コンテキストを理解するAIを実装する (AGIに近い (?))  2.
我々がAIに自社特有のコンテキストを与える    今回は 2 の方法に関して具体的な経験を共有します。 

2. 理想と現実を埋める方法 

最初に結論  AIはめちゃくちゃ知識があるが業務のことを何も知らない新人だと思うとわかりやすいと思います。  プロセスとデータを解釈の余地なく教える必要があります。  Figma to Code  AIレビューツール 

LLMと人間の違い  共通点  • LLMは人間の脳の仕組みを模倣している  相違点  • 知識獲得方法  ◦ 人間 :
(個人・組織に関わらず) 各々が十人十色の経験を基に独自の知識を獲得している   ▪ 知識量は限られているが独自性に優れている   ◦ LLM : webから収集できる一般的な知識を獲得している   ▪ 知識量は膨大だがwebから収集できない独自情報は知らない   一番わかりやすい例は「あれどうなった?」で理解できるのが人間。  LLMは理解できない。  Figma to Code  AIレビューツール  免責 : 私はAI / LLM の専門家ではないため正確でない可能性があります。  

LLMと人間の違い  つまり、LLMは、私たちが普段意識することもなく共通認識とみなしているアレやコレを知らない訳です。  これはまさに会社に来た新人と似ている状況ではないでしょうか。  Figma to Code  AIレビューツール  免責 :
私はAI / LLM の専門家ではないため正確でない可能性があります。  

AIは新人  (めちゃくちゃ知識豊富だけど) 

AIレビューツールの理想と現実を埋める方法  理想 : 自社のルールやコンテキストを踏まえてレビューして欲しい  現実 : 一般的な指摘に終始する  理想に近づけるためには   1.
まずはレビューのワークフローを言語化する  2. その後、AIレビューツールにそのワークフロー通りに処理させる  3. 各ワークフローで足りない情報があればAIに教える  Figma to Code  AIレビューツール 

AIレビューツールの理想と現実を埋める方法  やってみた結果  Figma to Code  AIレビューツール 

AIレビューツールの理想と現実を埋める方法  やってみた結果  結果  • 自社のコーディングルールを基に  • GitHub のPRに対して指摘  • 改善案も提案 
  効果  • 正しい指摘もある一方で誤りもある  • コーディング規約を日々目にするようになるという副次効果    改善点  • まだ false positive も多い  • 本当に修正が必要な指摘だけをできるようにならないと狼少年になって人間に無視されるようになる  Figma to Code  AIレビューツール 

リポジトリはここに (ai-review-flex)  https://github.com/baseballyama/ai-review-flex   Figma to Code  AIレビューツール 

Figma to Code の理想と現実を埋める方法  理想 : 自社のデザインシステムを踏まえて自動生成して欲しい  現実 : 単にライブラリを使用したコードが生成されてしまう 
理想に近づけるためには   1. まずはレビューのワークフローを言語化する  2. その後、AIレビューツールにそのワークフロー通りに処理させる  3. 各ワークフローで足りない情報があればAIに教える  Figma to Code  AIレビューツール 

Figma to Code 理想と現実を埋める方法  やってみた結果  Figma to Code  AIレビューツール 

Figma to Code の理想と現実を埋める方法  やってみた結果  結果  • 自社のデザインシステムコンポーネントを基に  • Vue
3 コンポーネントを実装してくれた    効果  • Figmaと行き来する回数が大幅に減った  • 今まで30分程度はかかっていただろう作業が5 分足らずで大枠が出来るのはかなり楽になった。    改善点  • 生成したコードに対して vue-tsc や ESLint を実行してエラーがなくなるまで自動修正させればもっと手作業が減りそう。  (時間が足りなくて試せませんでした🙏)    Figma to Code  AIレビューツール 

公開リポジトリはありません。  Figma to Code  AIレビューツール 

3. ギャップを埋める実装ステップ 

実装する前に... 

a. 実装する前に...  実装する前に以下の手順を踏むのが良いと思います。  作業プロセスと必要なデータを言語化する   ”単純作業” で “工数大” なプロセスを抽出する  
静的検査で自動化できるか  自動化する  Yes  GitHub Copilot などの既存ツールで対処する   GitHub Copilot  などの既存ツールで対処できるか  Yes  LLM を活用して独自の対処方法を検討する   No  Yes  No 

a. 実装する前に...  実装する前に以下の手順を踏むのが良いと思いました。  作業プロセスと必要なデータを言語化する   ”単純作業” で “工数大” なプロセスを抽出する  
静的検査で自動化できるか  自動化する  Yes  GitHub Copilot などの既存ツールで対処する   GitHub Copilot  などの既存ツールで対処できるか  Yes  LLM を活用して独自の対処方法を検討する   No  Yes  No  LLMはいわば「異様に能力が高いがプロジェクトのことを何も知らない人」です。  LLMへの指示は「解釈の余地なく」出す必要があります。  つまり、自動化したいタスクを解釈の余地なく言語化できる必要があります。  また、LLMはプロジェクトのことを何も知りません。よって、その作業プロセスに必要なデータも全て言語化する必要があります。 

静的検査で自動化できるか  自動化する  Yes  GitHub Copilot などの既存ツールで対処する   GitHub Copilot  などの既存ツールで対処できるか  Yes  LLM を活用して独自の対処方法を検討する   No  Yes  No  LLMは「高い」「遅い」「不正確」なので、ロジックで対処できるものは全てロジックで対処した方が良いです。 

静的検査で自動化できるか  自動化する  Yes  GitHub Copilot などの既存ツールで対処する   GitHub Copilot  などの既存ツールで対処できるか  Yes  LLM を活用して独自の対処方法を検討する   No  Yes  No  OpenAI を中心として、LLMを使用したサービスの成長速度が凄まじいです。  折角自作してもすぐに既存製品が対応する可能性があるので、  現時点では、既存製品を積極的に使用すると共に各社の動向を見て、製品側で対応されることで将来解決されそうな問題に対しては、自作するとしても深追いしすぎないなどの塩梅の調整が必要です。 

静的検査で自動化できるか  自動化する  Yes  GitHub Copilot などの既存ツールで対処する   GitHub Copilot  などの既存ツールで対処できるか  Yes  LLM を活用して独自の対処方法を検討する   No  Yes  No  それでも独自の方法が必要であるという結論に至った場合は  LLMを活用して独自の仕組みを実装しましょう!! 

作らない 

LLMを活用して独自の仕組みを実装する場合は... 

b. 実装ステップ  私が今まで試した中では以下の手順が良いと思いました。  Chat GPT に指示と必要なデータを与える   差分に関して  なぜそのような回答をしたのかを聞く  
指示とデータを修正して再度処理させる   返答と期待値に  差分があるか  Yes  Chat GPT にこれまでの指示をまとめさせる   新しいチャットにて、まとめた指示に対して   不明瞭な点や疑問がないかを聞く   (あればこれらがなくなるまで修正する)   この指示を使用するプログラムを実装する   返答と期待値に  差分があるか  運用開始  ※ 全指示とレスポンスはログに保存しておく   Yes 

LLMを活用して独自の仕組みを実装する場合は... 

指示とデータを与える  あなたは世界を代表するソフトウェアエンジニアです。あなたの仕事は git の diff をよく理解し、コーディング規約に違反しているコードを指摘することです。  以下のコーディング規約とdiffを基に指摘してください。    ##
コーディング規約    ### プロダクションコードにコンソールログを残さない    本番コードからすべての `console.log` ステートメントを削除することで、情報の漏洩や出力の乱雑さを避けることができます。    ## diff    {{ git diff の結果 }} 

回答  Based on the coding standards you provided and the
`diff` content, there is a clear issue that needs to be addressed:    The addition of `console.log(diff);` in the `splitForEachDiff` function violates the coding standard of not leaving console logs in production code. As per the standard, all `console.log` statements should be removed from production code to avoid information leakage and cluttered output. This newly introduced line directly contravenes this rule and should be removed or replaced with an appropriate logging mechanism suitable for production environments.  英語で返ってきたので日本語にしたい 

指示とデータを修正する  日本語で回答してください。 

回答  コーディング規則に基づいて、提供された `diff` の内容を検討すると、以下の問題点が明確になります：    `splitForEachDiff` 関数に追加された `console.log(diff);` は、本番コードにコンソールログを残さないという規則に違反しています。規則によれば、情報漏洩や出力の乱雑さを避けるために、本番コードからすべての
`console.log` ステートメントを削除する必要があります。この新しく追加された行はこのルールに直接反しているため、削除されるか、本番環境に適した適切なロギング機構に置き換えられるべきです。  最初の文章は不要 

指示とデータを修正する  指摘だけを簡潔に返答してください。 

回答  `splitForEachDiff` 関数に追加された `console.log(diff);` は本番コードにコンソールログを残さないというコーディング規約に違反しています。この行は削除すべきです。  よさそう 

これまでの指示をまとめる  これまでの指示を整理してください。この指示はGPTへの命令に使用します。指示は解釈の余地がないようにしてください。 

回答 (1 / 2)    以下に、あなたがLLMに対して使用するための整理された命令を示します。これは、コーディング規約とdiffが変わることを考慮して変数として設定できるように構成されています。    ---   
### 命令のテンプレート    **命令:**  LLMに対して、特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。    **変数:**  1. `codingStandard`: コーディング規約の詳細（テキスト形式）。  2. `diffContent`: 分析するdiffの内容（テキスト形式）。   

回答 (2 / 2)    **具体的な指示:**  1. LLMは、`codingStandard` に示されたコーディング規約を理解し、遵守する。  2.
LLMは、`diffContent` を分析し、`codingStandard` に違反している部分があるかどうかを判断する。  3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。  4. 分析結果は簡潔かつ明確に提示する。    ---    このテンプレートを使用することで、LLMに対する指示を明確かつ一貫性を持たせることができます。また、変数を変更することで、異なるコーディング規約やdiff内容に対応することが可能です。 

b. 実装ステップ  私が今まで試した中では以下の手順が良いと思いました。  Chat GPT に指示と必要なデータを与える   差分に関して  なぜそのような回答をしたのかを聞く  
指示とデータを修正して再度処理させる   返答と期待値に  差分があるか  Yes  Chat GPT にこれまでの指示をまとめさせる   新しいチャットにて、まとめた指示に対して   不明瞭な点や疑問がないかを聞く   (あればこれらがなくなるまで修正する)   この指示を使用するプログラムを実装する   返答と期待値に  差分があるか  運用開始  ※ 全指示とレスポンスはログに保存しておく   Yes 

まとめた指示に対して不明瞭な点や疑問がないかを聞く  以下の指示に関して、不明点や不明瞭な点があれば教えてください。     ---    **命令:**  特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。    
**変数:**  1. `codingStandard`: コーディング規約の詳細（テキスト形式）。   2. `diffContent`: 分析するdiffの内容（テキスト形式）。     **具体的な指示:**   1. LLMは、`codingStandard` に示されたコーディング規約を理解し、遵守する。   2. LLMは、`diffContent` を分析し、`codingStandard` に違反している部分があるかどうかを判断する。   3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。   4. 分析結果は簡潔かつ明確に提示する。  

回答  承知しました。このタスクを実行するためには、以下の情報が必要です：    1. **コーディング規約の詳細** (`codingStandard`)：これは、分析する際に参照するルールセットです。コーディング規約の詳細が提供されているか、あるいは特定の既存のコーディング規約（例えばPEP 8、Google Java Style
Guideなど）を参照するかの指示が必要です。    2. **分析するdiffの内容** (`diffContent`)：これは、変更点を示すコードの差分（diff）です。diffがどのように表示されているか（例えば、 GitHub形式のdiff、単純なテキスト比較など）、そしてどのプログラミング言語で書かれているか（TypeScript、JavaScript、Kotlin、Java、 Pythonなど）の情報が必要です。    これらの情報を提供していただければ、指示に従って分析を行うことができます。どうぞよろしくお願いいたします。 

大丈夫そうなのでコードに落とし込んでみましょう。  

コードにしてみる  const response = await openai.chat.completions.create({  model: "gpt-4-1106-preview" ,  messages:
[  {  content: buildPrompt(codingRule, diff),  role: "user",  },  ],  temperature: 0,  });  return response.choices[0]?.message?.content ?? "";    const buildPrompt = (  codingStandard: string,  diffContent: string,  ) => {  return `\  **命令:**  特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。    **変数:**  1. \`codingStandard\`: コーディング規約の詳細（テキスト形式）。  2. \`diffContent\`: 分析するdiffの内容（テキスト形式）。    **具体的な指示:**  1. LLMは、\`codingStandard\` に示されたコーディング規約を理解し、遵守する。  2. LLMは、\`diffContent\` を分析し、\`codingStandard\` に違反している部分があるかどうかを判断する。  3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。  4. 分析結果は簡潔かつ明確に提示する。  5. 日本語で回答する。    ## codingStandard  ${codingStandard}    ## diffContent  ${diffContent}`;  };    指示が抜けていたので足しました。  

コードにしてみる  const response = await openai.chat.completions.create({  model: "gpt-4-1106-preview",  messages: [ 
{  content: buildPrompt(codingRule, diff),  role: "user",  },  ],  temperature: 0,  });  return response.choices[0]?.message?.content ?? "";  const buildPrompt = (  codingStandard: string,  diffContent: string,  ) => {  return `\  **命令:**  特定のコーディング規約に基づいて、提供されたdiffの内容を分析し、規約違反がある場合はその指摘を行う。    **変数:**  1. \`codingStandard\`: コーディング規約の詳細（テキスト形式）。  2. \`diffContent\`: 分析するdiffの内容（テキスト形式）。    **具体的な指示:**  1. LLMは、\`codingStandard\` に示されたコーディング規約を理解し、遵守する。  2. LLMは、\`diffContent\` を分析し、\`codingStandard\` に違反している部分があるかどうかを判断する。  3. もし規約違反がある場合、LLMはその具体的な違反点と、それがどのように規約に反しているかを明確に指摘する。  4. 分析結果は簡潔かつ明確に提示する。  5. 日本語で回答する。    ## codingStandard  ${codingStandard}    ## diffContent  ${diffContent}`;  };    指示が抜けていたので足しました。  

実行してみた (1 / 2)  ## 分析結果    ### 規約違反の指摘  
  **違反箇所:**   ```diff  + console.log(diff);   ``` 

実行してみた (2 / 2)  **違反理由:**   提供されたコーディング規約には「プロダクションコードにコンソールログを残さない」という指示が含まれています。この規約は、本番コードからすべての `console.log` ステートメントを削除することで、情報の漏洩や出力の乱
雑さを避けることを目的としています。提供された `diffContent` の変更部分には、新たに追加された `console.log(diff);` という行があり、これは明確にコーディング規約に違反しています。     ### 修正提案    この `console.log` ステートメントは削除するか、デバッグ目的であれば、別のログメカニズムに置き換えることが望ましいです。例えば、ロギングフレームワークを使用して、開発環境でのみログを出力する設定にすることが考えられます。 

いい感じですね。  (ちょっと回答が長いけど) 

実際にはこんなことも実装しないといけない...  • コーディング規約のファイルをルールごとに split する処理   • diff を取得して1箇所ごとに分割する処理  
◦ diff から削除行を削除する処理 (これをした方が精度が上がった)   • 回答フォーマットをより厳密にするプロンプト調整   ◦ 指摘対象の diff に対してコメントするためには指摘対象の行番号が必要   • GitHub にコメントを投稿する処理   • 並列処理 (GPT4 は遅いため)   • OpenAI API のレート制限に引っかかった場合のリトライ処理     などなど... 

実装ステップ  私が今まで試した中では以下の手順が良いと思いました。  Chat GPT に指示と必要なデータを与える   差分に関して  なぜそのような回答をしたのかを聞く   指示とデータを修正して再度処理させる
  返答と期待値に  差分があるか  Yes  Chat GPT にこれまでの指示をまとめさせる   新しいチャットにて、まとめた指示に対して   不明瞭な点や疑問がないかを聞く   (あればこれらがなくなるまで修正する)   この指示を使用するプログラムを実装する   返答と期待値に  差分があるか  運用開始  ※ 全指示とレスポンスはログに保存しておく   Yes 

運用開始 ※ 全指示とレスポンスはログに保存しておく  プロンプトを一度作っただけでは大抵うまくいきません。こういうケースではうまくいくけどこういうケースではうまくいかない、のような学びを得ることになります。   その度にプロンプトを改善する必要があります。     プロンプトを改善する方法は簡単です。単に「その回答をした理由を教えてください」と聞きましょう。
 

運用開始 ※ 全指示とレスポンスはログに保存しておく 

運用開始 ※ 全指示とレスポンスはログに保存しておく  OpenAI の Playground を使用すれば Assiatants に任意の回答をさせた体でプロンプトを実行できます。  

運用開始 ※ 全指示とレスポンスはログに保存しておく  これをひたすら繰り返すことで精度改善をしましょう。  

継続的改善 

他に有用なテクニック  • プロンプトエンジニアリング : ( https://www.promptingguide.ai/ )  • ロール設定 :
「あなたはxxxの専門家です」 (https://platform.openai.com/docs/guides/text-generation/chat-completions-api )  • EmotionPrompt : 「限界を超えましょう!」 ( https://arxiv.org/abs/2307.11760 )  • Assistants API : 知識の埋め込み  • ベクターDB : より柔軟な知識の埋め込み   • Fine Tuning : モデルのカスタマイズ   GPTが知らない知識も使える   → 最新の技術はGPTが知らないから採用しない、のようなことは気にする必要はない。  

テストに関して  一般的にLLMの回答は毎回異なります。よってテストが難しいです。   LLMを使用した機能のテストに関してはまだ世界的にも手法が確立されていません。   それでも自分の経験から共有できることを共有しようと思います。     GPT モデルでは、パラメーターを設定することができるのですが、その中に「temperature」と呼ばれるパラメーター
があります。    これを設定すると、「最も確率の高い次のトークン」をひたすら返答し続けるので、プロンプト実行ごとの回答のブレが (ある程度) 少なくなります。     よって、この性質を利用することで、「めちゃくちゃ精度が落ちた」のようなことに気づける状態を構築することができます。 

テストに関して  弊社ではこれをCIに組み込むことで品質劣化がないかを確認しています。  

まとめ 

まとめ  • (統一感は大事) AIの支援を最大化するために統一感がより重要になります   • (AIは新人) AIは何も知らない新人です。プロセスとデータを解釈の余地なく教える必要がありま
す  • (作らない) AIの進化が激しいので不用意に独自のツールを作っても無駄になる可能性があります   • (継続的改善) プロセスとデータを解釈の余地なく教えるのは至難の技です。例えば誰かが「明日の朝までに」と言った時にAさんは「日本時間の朝までに」と捉えるかもしれませんし、Bさんは「サンフランシスコの朝までに」と捉えるかもしれません。   よって、「継続的改善」が必須です。 

終わり良ければ全て  ヨシッ  ありがとうございました 

(JSConf JP 2023) LLM (大規模言語モデル) 全盛時代の開発プラクティス

(JSConf JP 2023) LLM (大規模言語モデル) 全盛時代の開発プラクティス

More Decks by Yuichiro Yamashita

Other Decks in Technology

Featured

Transcript