対話システムライブコンペ7

12月6日エントリ締切

概要

参考資料

手順

git bash使用時のtips（使いこなすためのコツ）

対話システムを自分のPCで実行できるようにしよう

開発環境の構築手順

生成AIのAPIを使ってみよう

コンペに向けてのToDo list（書きかけ）

GitHubリポジトリ管理者用のメモ（一般のコンペ参加者は、ここの情報は無視して大丈夫）

主催者リポジトリ（プライベートリポジトリ）からのGitHub上の複製（プライベートリポジトリ）の作り方

主催者リポジトリの更新を、複製したリポジトリに反映

主催者リポジトリの新しいブランチを、複製したリポジトリに複製

12月6日エントリ締切

締切が近づいたので、コンペの参加申し込みをゼミチームあるいは授業チーム毎にするか、するとしたら、各チームで中心になるのは誰かを決めます。
11月25日時点では、私の名前でシチュエーショントラックにエントリしてありますが、ゼミや複数の授業でコンペに向けた取り組みをしているので、たとえばゼミと授業で合計３チーム参加するとしたら、あと２つエントリする必要があります。

概要

対話システムライブコンペティション7 HP
キックオフのページ（コンペの説明会の動画とその時の資料を掲載）

参考資料

PLAMO: 2024年『10月末まで』トライアルで無料でAPIが使えるので、10月末まではこれを利用してシステム開発する予定（詳しくは指導教員まで） ←すぐ10月末になってしまいそうなので、方針を変えて、Gemini APIを使うことにします→生成AIのAPIを使ってみよう
GPT-4を使うとロボットのこんな動作ができるのか、と大いに刺激になる論文。ビデオはここで視聴できます。ライブコンペでは単なるテキスト対話でなく、CGエージェントを使ったマルチモーダル対話を行うので、とても参考になるはず。
ライブコンペに向けた開発は、GitHub（チームでの共同開発に適したソフトウェア開発プラットフォーム）上で行います。将来ソフト開発しそうな人もそうでない人も、この機会に体験しておくと、よい財産になります。
ソフトの共同開発？とか言われても実感湧かなくて、ピンと来ないあなたへ：GitHubは、ソフト開発以外でも使われて話題になりました。都知事選の候補者がマニフェスト（選挙公約）をみんなで作り上げるためのリポジトリ（プログラム、ドキュメント、データやそれらの履歴情報などを置いておく場所）をぜひ見て下さい。「初めての方へ」の解説ページは、GitHubの解説にもなっていてGitHubで共同開発を初めてやろうというあなたにもお勧め。
GitHubで登録すると、GitHub Copilotという、プログラミング支援専用の強力な生成AIが使えるようになります。有料サブスクリプション（たくさんのプロのプログラマが使っています）ですが、学生や大学教員は申請すると無料で使えます。申請に少し手間がかかりますが、その価値があるので、この機会に申請しましょう。申請方法はここを参照。
GitとGitHubの参考書「いちばんやさしいGit&GitHubの教本第2版」（下記の「手順」中のページ数はこの本のページです）
↑この本のサポートページからコマンドリファレンスがダウンロードできます。便利なのでぜひダウンロードして使って下さい。

手順

Windowsの人は以下の手順通りに進んで下さい。macOSの人は担当教員に声をかけて下さい。

まずは初期設定1.～6.を実施：

Gitのインストールと初期設定（このWebページ（Gitとは何か）も一通り見ておくと分かりやすいと思う）pp.32-39, pp.63-65
GitHubへの登録（ユーザ名は他のユーザと重複するとその旨のメッセージが出るので入力し直してください；メールアドレスはGitの初期設定で指定したものと同じにしてくださいとのこと）pp.116-121
（GitHub Copilotの無料申請）←GitHubの初期設定でプランの選択画面がありますが、とりあえず、無料プランを選んで4.に進むことができます。時間があるときに、「学生としてGitHub Educationに応募する」手続きを済ませておくと、GitHub Copilotが無料で使えて重宝します。
ライブコンペのGitHubリポジトリに招待してもらう → 担当教員に必要な情報を伝える→招待メールが届くので招待を受ける(accept)操作をする
招待されたリモートリポジトリをcloneして自分のPC上にローカルリポジトリを作る
- Git Bashを起動する pp.43-44 ← インストールしたGitを「すべてのアプリ」から見つけてクリックするとGit Bashなどが表示されるので、「Git Bash」を右クリックして「スタートにピン留めする」をクリックし、スタートにピン留めしておくと便利；タスクバーにピン留めしておいてもよい
- カレントディレクトリ（ワーキングディレクトリ）をクローンしたい場所に変更←コマンドプロンプトの最後にカレントディレクトリが示されています。「~」（チルダ）は、ユーザのホームディレクトリを示します。まず、ホームディレクトリの下にgithubディレクトリを作ります（mkdir github）。ホームディレクトリから、作成したgithubディレクトリに移動するには cd github を実行。実行後はコマンドプロンプトの最後は ~/github になります。なお、Git Bashウィンドウの上部（欄外）にもカレントディレクトリが表示されています。Git Bash上でのCopy/Pasteは、Git Bashのウィンドウ上で右クリックするとメニューが現れます。Git Bashの文字サイズ変更→ウィンドゥ上部の枠部分を右クリック→「options...」→「Text」→「Font」の「Select...」ボタンを押して選択 pp.46-53 以下、太字のコマンドを順次実行して下さい

cd ~
mkdir github
- ↑カレントディレクトリがホームディレクトリ（~）であり、かつ、まだ、githubディレクトリを作成していない場合、このコマンドを実行してgithubディレクトリを作成
- mkdir (make directory): ディレクトリを作るコマンド
cd ~/github
- 不要なディレクトリを作ってしまった場合はそれを消しておきましょう。消し方は、次の通りです。消したいディレクトリの親ディレクトリ（一つ上のディレクトリ）に移り、そこで消すコマンドを実行します。githubディレクトリの下にさらにgithubディレクトリを作ってしまったので、下の階層のgithubディレクトリを消したいとすると、カレントディレクトリが下の方のgithubだとして、
  - cd ..
    - ↑一つ上の階層に移動
  - rmdir github
    - ↑消去
- cdコマンドの説明（カレントディレクトリの変更）
- lsコマンドの説明（現在いるディレクトリのファイルやフォルダを一覧表示）
- rmdirコマンドの説明

- githubの下にローカルリポジトリを作る（クローン）pp.132-135
  - cd ~/github
  - git clone https://github.com/okana2ki/Live_Competition_7.git
    - ↑これは、「git clone https: ...(中略)... 7.git」という1行の長いコマンドです
    - ↑クローン中に、認証画面が現れた場合は、GitHubの認証操作をする
    - error setting certificate file: C:/Git/mingw64/etc/ssl/certs/ca-bundle.crtというエラーが出た場合は、Git Bashで git update-git-for-windows でgitを再インストールしてみて下さい
  - cd ~/github/Live_Competition_7
    - ↑作成したディレクトリに移動
  - git remote -v
    - ↑リモートリポジトリの設定を確認：クローン元のリモートリポジトリに初期値としてoriginと言う名前が付けられたことが分かる。
自分の名前のブランチを作成してチェックアウト pp.142-147, pp.186- ：開発の進め方とブランチの使い方：各自、クローンにより作成したローカルリポジトリでブランチを作成して開発を進めます（mainブランチは変更せず、作成したブランチを変更します）；ブランチ名は、次のようにして下さい：「実践人工知能」受講生は ai/<yourname>, 「情報と職業II」受講生は oc/<yourname>, 「岡ゼミ」受講生は lab/<yourname> 。例：「実践人工知能」の受講生田中さんであれば、ブランチ名は、ai/tanaka；「情報と職業II」受講生の武田さんであれば oc/takeda；「岡ゼミ」受講生の和田さんであれば lab/wada となります。氏名のローマ字綴りはmoodleに登録された苗字を使います。共有したリモートリポジトリの画面左上部の「Branches」をクリックするとブランチ名の一覧が表示されます；この各自の名前のブランチでのローカルリポジトリの変更内容を、共有リモートディレクトリの各自の名前のブランチにプッシュすることにより開発したファイルを共有します。毎週少なくとも1回はプッシュするようにして下さい；その後、チームメンバーのブランチを適宜マージしてチームの対話システムを作成します。
- git branch <branchname>
  - ↑ブランチ名のブランチを作成；<branchname>の代わりに git branch oc/tanaka などのように自分のブランチ名を書いて下さい（ブランチ名を挟む < > は外して下さい）
- git branch
  - ↑ブランチ一覧を表示；「*」が使用中のブランチ
- git checkout <branchname>
  - ↑ブランチ名のブランチに切り替え
- git checkout -b <branchname>
  - ↑ブランチを作って、そのブランチに切り替え（ブランチ作成と切り替えの両方を一つのコマンドで行う場合は、このコマンドを使う）
- （不要なブランチがある場合の削除の仕方は後ほど記載） p.206

以下は、その他の初期設定：

エクスプローラでファイルの拡張子を表示するように設定 pp.61-62
- エクスプローラを開いてウィンドウ上部の「・・・（メニュー）」-「オプション」をクリック→「表示」タブの「登録されている拡張子は表示しない」のチェックを外す→「OK」をクリック
Visual Studio Codeのインストール pp.55-59
- ここからダウンロードして、インストール。インストール中の「追加タスクの選択」画面で「PATHへの追加」にチェックを入れて下さい。
GitのエディタとしてVisual Studio Codeを設定（Git Bashで下記のコマンドを実行） p.66
- git config --global core.editor "code --wait"
  - ↑この設定ができていると、Gitの操作中に（コミットメッセージを入力するときなど）必要に応じて立ち上がるエディタがVS Codeになるので使いやすいです（デフォルトのエディタは初心者には使いにくいので）
  - ↑設定の確認は、Git Bashで git config core.editor というコマンドを入力すると code --wait と出力されることで確認できます

以下は、必要に応じて随時、実施：

リモートリポジトリのmainブランチの更新をローカルリポジトリのmainブランチに反映し、続いて、自分の名前のブランチに変更を反映　（自分のPCで音声対話システムを動かすためにここを実行している人は、mainブランチに反映するところまででOK。自分の名前のブランチは使わないので、mainブランチへの反映が終わったら、「開発環境の構築手順」の該当箇所に戻って下さい。） pp.178-, pp.200-202 参考：リモートリポジトリから変更を取得する
- cd ~/github/Live_Competition_7
- git checkout main
- git pull origin main
  - ↑ローカルリポジトリのmainブランチを最新状態に
  - ここで、次のエラーメッセージが出る場合

error: Your local changes to the following files would be overwritten by merge:

config/config.yaml

Please commit your changes or stash them before you merge.

- - - 以下のコマンドを順に実行
      - git add config/config.yaml
      - git commit -m "update config.yaml"
      - git pull origin main
      - ここで、次のメッセージが出る場合

CONFLICT (content): Merge conflict in config/config.yaml

Automatic merge failed; fix conflicts and then commit the result.

- - - - ↑これは、pullしたときに自動でマージできずコンフリクトが発生したことを示す。対処法は下記：
        code .
        ↑このコマンドで vs code を立ち上げ、左カラムのconfigをクリック→config.yamlをクリックすると、コンフリクト箇所（リモートファイルとローカルファイルの差異）が表示されているはず。コンフリクト箇所の表示を見ながら、適宜どちらか残す方を選択することで競合解消したファイルを保存（修正の際、コンフリクトを示す行（<<<<<<<, =======, >>>>>>>のそれぞれで始まる行）が残っていれば、これらも忘れずに消去）
        git add config/config.yaml
        git commit
        コミットメッセージ編集画面が立ち上がるが、メッセージは自動で書かれているので、単に当該タブを閉じればよい
- CGの対話システムを自分のPCで動かそうとしてここを読んでいる人は、これ以降は実行せず、ここで「開発環境の構築手順」に戻って下さい。（mainブランチだけで構築できるので、他のブランチは使いません。）
- git checkout <branchname>
- git merge main
  - ↑mainブランチを自分の名前のブランチにマージ；エディタ（VS Code）が立ち上がった場合、マージメッセージの編集は不要なので「×」を押してエディタを閉じる→マージ完了；マージ不要のときなどはエディタは立ち上がりませんが、それでOKです。
リモートリポジトリのdevelopブランチに、Announce.mdを置きました。運営側からのアナウンスでここ（公開HP）に書くべきでないと判断される情報をAnnouce.mdに随時書き加えるので、時々チェックして下さい。
（開発がまだ始まってない場合は、この12.はいったん飛ばして13.に進んで下さい）自分のPCで開発中（上で作成したブランチで開発）は、適宜ローカルリポジトリにコミットして履歴を保存（変更内容をコミットメッセージに詳しめに書いて下さい）→コミットについて pp.72-3, pp.77-78, pp.80-114
- git add <filename>
  - ↑ファイルをステージングエリアに登録；git statusで確認できる
- git commit -m "commit message"
  - ↑ステージングエリアに登録されているファイルをローカルリポジトリにコミット；commit messageの部分はコミットメッセージです。コミットの内容を説明する文を自分で書いて「"」でメッセージの始めと終わりを囲んで下さい
  - git status
    - ↑修正されたファイル、ステージングエリアに登録されているファイル／登録されていないファイル、等の情報を表示
  - git diff
    - ↑ワークツリーとステージングエリアの差分
  - git diff --cashed
    - ↑ステージングエリアとGitディレクトリ（前回のコミット）の差分
  - git diff main
    - ↑今使っているブランチをmainブランチと比較
  - git log
    - ↑コミット履歴の確認
週に1回以上、GitHubの自分の名前のブランチにプッシュして進捗を共有
- まず、手順10.をすべて実行して、リモートリポジトリのmainブランチの更新をローカルリポジトリのmainブランチに、続いて、自分の名前のブランチに反映しておく
- cd ~/github/Live_Competition_7
- git checkout <branchname>
- progress_report.md （進捗レポート用ファイル）を編集 → add → commit（addとcommitは手順11.参照）
  - ↑progress_report.mdは、git bashのコマンドではなく、ファイル名です。下記の手順でこのファイルを開いて編集します
  - ↑git bashから「code .」（ドットはカレントディレクトリを表す）とコマンドを入力して、VS Codeを立ち上げ、画面左側の該当ファイル（progress_report.md）をクリックして開きます。
  - 開いたら編集（新しい進捗を追記）します →（参考）Markdownの書き方 p.79 （注意）単なる改行1つは、マークダウンでは半角スペース1個として表示され改行されません；改行するには半角スペースを続けて2つ入力します
  - VS Codeでマークダウンをプレビューする（横にプレビューを開いて表示を確認しながら編集する）には、タブ右上の「四角が2つ横に並んで右側に虫眼鏡があるアイコン」をクリック
  - VS Codeのタブ上のファイル名の右に●が表示 → 保存されていない変更があることを示す → 保存は、ウィンドウ左上の「File」→「Save」
  - 変更を保存したら、git status で状態確認し、git add <filename> → git commit により履歴をローカルリポジトリに保存（詳細な手順は下記の通り）
    - 変更したのがprogress_report.mdだったとすると、git status で下記のように表示される
      - Changes not staged for commit:
      - modified: progress_report.md
    - ここで、git add progress_report.md と入力すると、git status で下記のように表示される
      - Changes to be committed:
      - modified: progress_report.md
    - さらに、「git commit と入力すると、エディタが立ち上がるので、コミットメッセージをエディタで入力する（エディタの画面の1行目にコミットメッセージ（例：進捗レポートを更新）を記入します；エディタで入力しそれを保存後にエディタを終了するとコミットされます）」か、または、git commit -m "commit message" のようにコミットメッセージ付きのコマンドを実行する（”commit messsage”の部分は"プログレスレポートを更新"などのように適当に書き換えて下さい）と、git status で下記のように表示される
      - nothing to commit, working tree clean
- git push origin <branchname>
  - ↑ローカルレポジトリの自分の名前のブランチ（変更後）をリモートリポジトリoriginの自分の名前のブランチにプッシュ（ブランチが存在しないときは同じ名前のブランチが作成され同じ内容になる）して変更をみんなと共有 pp.151-152
  - ↑プッシュできたことの確認のしかた：https://github.com/okana2ki/Live_Competition_7をクリック→画面左上部の「main ▼」をクリックしてブランチ一覧を表示→自分の名前のブランチをクリック→自分の名前のブランチのファイル一覧が表示されるので、変更したファイルがいつ更新されたか（一番右の欄に表示）を確認する。コミット時に入力したメッセージも表示されているはず。→更新内容を確認したい場合は、当該ファイル名をクリックすると内容が表示される。→画面右上の「History」をクリック→コミットの履歴（ファイル修正の履歴）が表示される→コミットメッセージをクリックすると、修正の詳細が表示される（赤地で「-」と書かれた行が削除された行、緑地で「+」と書かれた行が追加された行）
  - ↑rejectされてpushできない場合は、origin の<branchname>ブランチが変更されていることが原因。→ git pull origin <baranchname> （このコマンドは、リモートリポジトリの<baranchname>ブランチの内容をローカルの現在使っているブランチに反映）でリモートの変更を取り込んでから、再度 git push origin <branchname> を試みる。
  - ↑pullしたときに自動でマージできずコンフリクトが発生した場合の対処法：
    - git status で、コンフリクトが起こっているファイルを確認 → 例：both modified: <filename> のように表示されます
    - VS Codeでコンフリクトしているファイルを開く→コンフリクト箇所（リモートファイルとローカルファイルの差異）が表示されているはず
    - コンフリクト箇所の表示を見ながら、リモート／ローカル双方での変更を反映するようファイルを修正して保存（修正の際、コンフリクトを示す行（<<<<<<<, =======, >>>>>>>のそれぞれで始まる行）も忘れずに消去）
    - git add <filename> ← 修正後のファイルをadd
    - git commit ← コミットメッセージ編集画面が立ち上がるが、メッセージは自動で書かれているので、単に当該タブを閉じればよい
    - git push origin <branchname> ← 再度push
  - ↑rejectされた原因となったリモート側の変更がミスによるものであることが分かっていてリモート側の当該ブランチをいったん消してしまって構わない等の特殊な事情がある場合は、いったん、リモートリポジトリの自分の名前のブランチを削除した上で、再度、pushする　という手もありえるが、普通はそのような操作は推奨されない。しかし、参考までに削除する方法も示しておく：リモートリポジトリの自分の名前のブランチを削除する方法は、下記のいずれか：
    - GitHub上のリモートリポジトリの画面を開き、画面左上のBranchesをクリックしてブランチ一覧の画面に遷移し、そこで、自分の名前のブランチのゴミ箱アイコンをクリックしてブランチを削除、または、下記の方法でGit Bashから削除
    - git push origin --delete <branchneme>
      - ↑Git Bash から削除する方法　参考：Gitのブランチ機能―リモートブランチ
- （このタイミングではマージはしないので、プルリクエストは作成しません）
適宜、チーム内でマージ

git bash使用時のtips（使いこなすためのコツ）

コマンド入力に対して返ってきたメッセージが英語だからといって、思考停止しない → メッセージを読み飛ばして、何もなかったかのように、そのまま手順通り次のコマンドに進んでしまっては、いけません
返ってきたメッセージは、英語でも必ず読んで、必要な対応をして下さい；英語が苦手な人は、翻訳ソフト（DeepLなど）にコピペするなどして必ず内容を確認して下さい；スマホに翻訳アプリ（Google翻訳）を入れておくと、カメラをパソコン画面にかざすだけで翻訳できるのでお手軽
英語メッセージでもちゃんと読んで対応しないといけない例をいくつか（翻訳して確認しておく癖をつけておいて欲しいので下記も翻訳してみて下さいね）：

$ cd intro

bash: cd: intro: No such file or directory

↑そんなファイルやディレクトリは存在しないよ【ディレクトリ名をタイプミスしたときや、思っていたのと違うディレクトリでこのコマンドを入力してしまったときなど】

$ makedir

bash: makedir: command not found

↑コマンドが見つからないよ【コマンド名の記憶違いやタイプミスなど】

$ git branch

fatal: not a git repository (or any of the parent directories): .git

↑致命的：gitレポジトリではないよ（または、親ディレクトリにいるよ）【Live_Competition_7ディレクトリでなく、親ディレクトリであるgithubディレクトリでこれを実行してしまったとき；リモートからまだcloneできてないとき；Gitの初期設定（名前とメールアドレスの設定）がまだできてないとき；git initをまだ実行してないとき（cloneしたときはgit init不要）など】

ディレクトリの構成（~/github/Live_Competition_7）や、今いるディレクトリはどこかや、どのディレクトリがgitレポジトリかを常に意識して下さい

対話システムを自分のPCで実行できるようにしよう

主催者からの連絡(2024/10/10)：この度、開発環境を構築済みの Docker imageを作成いたしました。こちらのimageをご使用いただくことで、開発環境の構築が簡便になりますので、ぜひご活用ください。具体的な手順については、以下の GitHub ブランチ（下記にコピーしました：岡）をご確認ください。

主催者からの連絡(2024/10/16)：この度、video処理に関する改良を施したパッチを作成いたしました。お手数をおかけしますが、以前配布いたしました feat/docker ブランチをpullしていただけますと幸いです。（下記はpullしたものです：岡）

https://github.com/okana2ki/Live_Competition_7/tree/feat/docker

主催者からの連絡(2024/11/3)：この度、本システムの安定性向上および新機能の追加を反映したバージョンv0.0.2をリリースいたしました。（以下を更新しました：岡）

https://github.com/okana2ki/Live_Competition_7

以下の更新内容についてご確認いただけますと幸いです。

MacOS/Windows に対応した Docker image を配布
Docker を用いるためのドキュメントを追加
本ソフトウェアの安定性向上
TTS のスタイル指定機能を追加
シチュエーショントラック・タスクトラックに応じた MMDAgent の実行環境を追加
TravelViewer を追加

なお、config/config.yaml内のresponse_generation_modelの設定において、デフォルト値を”gpt-4o-mini”から”gpt-4o”に変更しております（予選・本選時のシチュエーショントラックのシステム制約に合わせております）。開発時にご留意ください。

開発環境の構築手順

まず、上記の手順10.をすべて実行（手順11.以降は不要；手順10.だけ実行）して、リモートリポジトリのmainブランチの更新をローカルリポジトリのmainブランチに、続いて、自分の名前のブランチに反映しておく（自分の名前のブランチは使わなくても構築できるので、その部分を省略するよう変更しました）
https://github.com/okana2ki/Live_Competition_7のREADMEのインストール方法に沿ってインストールを進めます→ただし、このリンク先は、主催者のリポジトリからのコピーであるため、主催者のリポジトリを参照するように書かれていますが、皆さんが参照するのは私がコピーしたリポジトリであるため、URLが異なります。また、cloneのしかたなど、皆さんが構築してきた環境とは、合わない点もいくつかあります。さらに、説明不足で分かりにくい点や記載漏れもいくつかあります。したがって、上記のリンク（インストール方法）を参照して進める場合、必ず、以下の「各ステップの補足説明」を合わせて見ながら進めて下さい。なお、主催者による講習会の資料もあるのですが、この公開ページに掲載するのは問題がある可能性があるので、講習会資料はmoodleにて共有します。
1. 「Step 1. 事前準備：Docker Desktop のインストール」の補足説明（Windowsの場合）
  - https://docs.docker.com/desktop/setup/install/windows-install/
  - 自分のパソコンのプロセッサに応じてどちらか（x86_64かArm）のインストーラをダウンロード
    - プロセッサの調べ方：Windowsキーを押す→「設定」→「システム」→「バージョン情報」
  - ダウンロードしたインストーラをダブルクリックしてインストール→変更を許可するか？「はい」をクリック→インストール中にConfigurationの選択肢が提示される→チェックは2か所とも入ったままで（選択肢が1つだけだったらそのチェックが入ったままで）「OK」をクリック
  - 「Close and restart」をクリック → パソコンが再起動されます
  - 再起動後、自動的に立ち上がるDocker Desktopのウィンドウで「Accept」をクリック→選択肢は選ばれているもの（推奨セッティング）をそのまま選んだ状態で「Finish」をクリック
    - WSL update failed: you can manually update using wsl --update と表示された場合、黒い画面で任意のキーを押してWSLをインストールするとよい；その後、Docker Desktopを起動して次の項目に進む
  - 変更を許可するか？「はい」をクリック→初期状態はWorkタブが選ばれているがPersonalタブをクリックして選ぶ→下部に並んだ3つのボタンのどれか（Googleアカウントを使用；GitHubアカウントを使用；アカウントをつくる）を好みに応じて選択
  - Usernameを入力して「Sign up」をクリック→「Docker Desktop.exeを開く」をクリック
  - アンケートに答える（Studentを選択→Learning or teachingを選択）→Docker Desktopが起動
  - Docker Desktopをスタートメニューに追加しておくと、今後、便利
  - （参考）実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本
2. 「Step 2. Remdis 本体のインストール：Clone」の補足説明

READMEのインストール方法の「Step 2. Remdis 本体のインストール：Clone」には、4行のコマンドが書かれています。これを見るとサブモジュールを使う必要があるようですが、皆さんはinstallはすでに実行済みなので、これらの４行の代わりに次のコマンドを実行する必要があるか主催者に尋ねると不要だとの返答でした。よく分からない状態ですが、ここでは下のコマンドもそれ以外のコマンドも何も実行せず、次のステップに進みます。→しかし、この下の２つのコマンドを実行しておかないと、２つのサブモジュール（'MMDAgent-EX/asset/models/uka'と'VAP'）がローカルにクローンされていない状態のようなので、以下の２つのコマンドを実行して下さい。

cd ~/github/Live_Competition_7

git submodule update --init --recursive

（参考）Git のさまざまなツール - サブモジュール
（参考）git submodule関連

1. 「Step 2. Remdis 本体のインストール：Docker ファイルのビルド」の補足説明

cd ~/github/Live_Competition_7/docker
Docker Desktop（「Step 1. 事前準備：Docker Desktop のインストール」でインストールしたプログラム）を起動（すでに起動してある場合はそのまま次に進む）
「# タスクトラックの開発者向け」として書いてあるコマンドは実行せず、「# シチュエーショントラックの開発者向け」に書いてある下記↓のコマンドを実行
docker compose -f docker-compose.prompt-only.yaml build
↑ 実行に45分程度かかると思います。途中でエラーメッセージも出るようですが、とりあえず、特に対応はせず、次に進むことにします。#0から#18までビルドの途中経過が表示されます。#0から#18まで順次表示が進まない場合は、教員に声をかけて下さい。
Windows を使用している方は追加で以下↓を実行してください。
cd ~/github/Live_Competition_7
sed -i 's/\r//g' run.sh

1. 「Step 2. Remdis 本体のインストール：配布ソフトウェアのダウンロード」の補足説明

cd ~/github/Live_Competition_7
↓配布ソフトウェアを Live_Competition_7 の下にクローンします。どのブランチにいても大丈夫（なはず）。
git clone https://huggingface.co/datasets/yubo0306/remdis-tools dist

1. 「Step 3. 各種 API 鍵の取得と設定」の補足説明

OpenAI APIキー取得とRemdisへの反映
- ↑OpenAI APIキーは有料なので、どうするかは別途伝えます（moodleに掲載）。自分で取得して自分で支払っていろいろ好きにやりたい人は、リンク先を参照して取得・支払いをして下さい。最少額では５ドル（約800円）カードで支払うと使えるようになります。
- ↑Remdisへの反映は、~/github/Live_Competition_7/config/config.yaml 内で下記の個所を設定します。cd config ←このコマンドで ~/github/Live_Competition_7/config に移動し、そこで、code . コマンドにより VSCode を起動し、config.yaml を開いて、下記の <enter your API key> （両端の < > を含む）を削除し、そこに、APIキーを入力します。具体的にどうするかは別途伝えます（moodleに掲載）。
  - ChatGPT:
  - api_key: <enter your API key>
  - response_generation_model: "gpt-4o-mini" # 本選・予選時は"gpt-4o", 開発時"gpt-4o-mini"
  - ↑response_generateion_modelは、デフォルト値として”gpt-4o”が入っていますが、これは予選・本戦時の設定です。開発時にいろいろ試す時点では安価で高速な”gpt-4o-mini”と書き換え、これを使い、本番環境での評価のために必要なときだけ高額の”gpt-4o”にして下さい。
Google Speech Cloud APIキー取得とRemdisへの反映
- 手順通りに進めます。https://cloud.google.com/free ←ここをクリックして始める
  - $300 分の無料クレジット
    - 90 日間有効な $300 分のクレジットで Google Cloud をお試しいただけます。
  - 無料トライアル期間が終了しても、自動的に請求されることはありません
    - ロボットでないことを確認するため、お持ちのクレジットカード番号の入力をお願いしています。クレジットカードまたはデビットカードを使用する場合、手動でフルアカウントを有効にしない限り、請求は発生しません。（クレジットカードを持っていない場合どうするかはmoodleに記載）
    - 「フルアカウントを有効化」はクリックしない。これをクリックすると、それ以降は使用量に応じた支払いが発生するので注意。
- Google Cloud Platformへのアカウント登録が完了した後、手順途中で中断した場合の再開は、ここから → https://console.cloud.google.com/
- 手順に沿って、公開鍵（JSONファイル）を取得したら、【Remdisへの反映】を実行して下さい。
  - 公開鍵の保存場所は、~/github/Live_Competition_7/config の下にして下さい。config.yamlが置いてあるディレクトリです。
  - config/config.yaml中にあるASR:のjson_key: <enter your json path>に対して，<enter your json path>を削除し（両端の<>も削除）、ダウンロードしたJSONファイルのパスを入力してください．パスの書き方は： /home/ubuntu/dslc7/config/<filename>
  - ↑<fileneme>は、自分の公開鍵のファイル名（拡張子は.json）を書いて下さい。先頭と末尾の<>は削除。
Azure APIキー取得とRemdisへの反映
- 手順通りに進めて下さい。クレジットカード番号の入力が必要です。（クレジットカードを持っていない場合どうするかはmoodleに記載）無料の30日間を超えて使い続けるためには、その時点で従量課金制に移行することを選択しないといけないようです。従量課金制に移行した場合は、毎月の無料分を超えた分に課金されるようです。
  - config/config.yaml中にあるTTS.azure:の api_key と region をそれぞれ書き換えてください

↓ここからはシステム起動のたびに実行する必要（これより前は初回のみ実行）

1. 「Remdisの実行」の補足説明
  - Dockerの起動
  - cd ~/github/Live_Competition_7/docker
  - git checkout main
  - docker compose -f docker-compose.prompt-only.yaml up -d
  - docker-compose -f docker-compose.prompt-only.yaml exec remdis bash run.sh

1. - - Remdisの実行で次のエラーが出た場合、
      - $ docker-compose -f docker-compose.prompt-only.yaml exec remdis bash run.sh
      - service "remdis" is not running
    - 以下をやり直すと治るかも？　それとも、mainブランチにいないとき、このエラー？
      - # シチュエーショントラックの開発者向け
      - docker compose -f docker-compose.prompt-only.yaml build
      - Windows を使用している方は追加で以下を実行してください。
      - sed -i 's/\r//g' run.sh
2. 「音声/動画入力サーバの起動」の補足説明
  - Windows の場合：エクスプローラから dist/input.exe を実行*
  - Windows の場合：エクスプローラから MMDAgent-EX/run_situation.vbs を実行*
    - 「エクスプローラからの実行*」の補足説明：エクスプローラを開く→PC→Windows(C:)→ユーザー→自分のユーザー名のフォルダー→github→Live_Competition_7→この下にdistフォルダーや、MMDAgent-EXフォルダーがあるので、それぞれのフォルダーから上記のファイルを見つけてダブルクリック
    - さらに解説*：これまで、Git Bashを使って各種コマンドによって、github以下のフォルダやファイルを作ってきたものを、上記では、エクスプローラからアクセスしていることになります。たとえば、私の場合であれば、C:\Users\oka\github\Live_Competition_7\dist\input.exe ←このようなディレクトリ構成になっています。oka の部分は皆さんのユーザ名がきます。
    - ~\github\Live_Competition_7\MMDAgent-EX\asset\models\uka が空だとukaが表示されない。これは、submoduleを使えてないかららしい。講習会では、git submoduleとかを実行した後で必要なファイルをpull？　チームの学生にどう伝えるかについては、運営側でmainを書き換えてくれる（と、単にpullすればよくなる？）らしい。→この点については、「Step 2. Remdis 本体のインストール：Clone」において、git submodule update --init --recursive を実行することで解決したと思う。
3. これでうまく動いているはず

生成AIのAPIを使ってみよう

Colabや、Pythonや、生成AIを利用したプログラミングについて少し経験がある人は、下記の「Gemini APIを使う演習」に進んで下さい；1) Colabは初めて、2) Pythonは初めて、3) 生成AIを利用したプログラミングは未経験、このどれかに当てはまる人は、以下を少し体験してから、「Gemini APIを使う演習」に進んで下さい
- 生成AI利用プログラミングの初めの一歩
- Colab や Gemini の使い方
Gemini APIを使う演習 ← 使用制限はあるが無料で使えます（2024/10/30現在）
- Gemini APIを使うための情報：GeminiAPI.ipynb
- 演習　WB4A_workshop.ipynb ← GeminiAPI quickstart, システム指示の書き方（コンペとかで必要になる、どのように対話して欲しいかとかを設定する方法）他
  - 資料Aや資料Bや資料C(←資料C のpp. 52-61が開発のヒントとしては一番参考になりそう)を参照しながら、演習のノートブックで、いろいろな設定を試してみよう；満たすべき仕様は資料Aに書かれているので、資料Aの参照も必須です
  - 大規模言語モデル活用技術の最前線　 ←これも参考になりそうです！
  - 参考資料の第2項目のロボットの動作の生成方法も参考になるかも
  - システム指示の書き方のtips（使いこなすためのコツ）
    - 否定形（ｘｘしないようにして下さい）は指示通りにならない可能性があると言われています。肯定形（ｘｘして下さい、など）で書き直す工夫ができると、指示通りに返答する可能性が高まります。
    - 日本語で書いたシステム指示よりも英語で書いたシステム指示の方が伝わりやすい可能性があります。英語に翻訳したもので試してみる価値があります。
    - 一貫した分かりやすい形式でAIに伝えるのが望ましいです。たとえば、「# ○○〇」の形式で項目分けするとか。半角の#の後は半角スペースを入れるのが普通（これは、プログラム言語やマークダウンでよく出てくる形式に倣ってそうする）。○○〇のところは、例えば、背景設定、とか、タスク、とか、指示、とか、対話例、とか、注意事項、とか・・・
  - 先週の自分の作業の再開の仕方（この場合、その間に私がノートブックを更新していたとすると、それは反映されてないので注意して下さい）：
    - Googleの検索画面をブラウザで開く→画面右上の「Googleアプリアイコン（3x3で点が並んでいるアイコン）」をクリック→「ドライブ」をクリック→左カラムの「マイドライブ」をクリック→黄色いアイコンの「Colab Notebooks」フォルダをクリック→「最終更新」でソートするなどして、自分が作業していたノートブックを見つけてクリック
    - 別の方法：すでに何かコラボノートを開いているとしたら、ヘッダーが表示された状態（ヘッダーの表示／非表示は、画面右上部の「v」／「＾」アイコンをクリック）で、ヘッダーの一番左にある「ファイル」をクリック→「ノートブックを開く」をクリック→「Googleドライブ」をクリック→そこで「最終更新」でソートするなどして、自分が作業していたノートブックを見つけてクリック
  - 開発経過の共有：各自が工夫したシステム指示や対話履歴を共有して、①よりよいシステム指示の作成や、②改良に必要な問題点を明らかにするためにどのような対話をしたらよいかを明らかにすることを目指して意見交換しましょう
    - 共有のしかた（共有手順の動画解説を掲載する予定）：演習のノートブック WB4A_workshop.ipynb を開いて、 1) 画面上部の「ドライブにコピー」をクリック（これを忘れるとあなたがいろいろ設定・実行したファイルでなく、元の状態のままのファイルが共有されてしまいます）→ 2) 画面右上部の「共有アイコン」をクリック→ 3) 「一般的なアクセス」の「制限付き」をクリック→ 4) 「リンクを知っている全員」をクリック→ 5) 「閲覧者」となっていることを確認→ 6) 「リンクをコピー」をクリック→ 7) 手順13にしたがって、progress_report.md （進捗レポート用ファイル）を編集して共有；この際、レポート末尾でなく先頭付近に今日の日付を記入し、先ほどコピーした共有リンクを貼り付けて下さい。
  - ↑progress_report.md （進捗レポート用ファイル）への記載例：

### 10月30日

- [Colabノートブック](https://colab.research.google.com/drive/1EJQKSjKLSP7hLKO-V01qeHoYwBLvljht?usp=sharing)を更新

- xxxに対してxxxという応答でいまいちだったが、xxにooと記述するといい感じの応答になった

### 10月23日　ここから下は以前の進捗（記載省略）

↑記載例の解説：[リンクになる文章](リンク先URL) の形式で書くと、マークダウンでリンクを記載できます

OpenAI APIを使う場合は、ここを参照

コンペに向けてのToDo list（書きかけ）

締め切りまでの日程：１月９日が開発システムの提出〆切です。12月の授業期間は残り１週間、冬休みが２週間、新年の授業期間は火水木の3日だけです。コンペで高順位を目指すには、12月の授業期間内に、当該授業の授業時間外の時間を確保するか、冬休み中の時間を確保するか、のどちらかが必要かなと思います。

チーム編成：主催者から「複数チームにする場合は、互いに設計方針が大きく異なること」という条件が提示され、これを満たして複数チームにすることは難しそうなため、ゼミと２つの授業の合計３チームから、やる気のある人や開発に貢献できそう（下記の分担項目を参照）な人を集めて選抜チームを１つ作ります。選抜チームはLINEグループで連絡を取り合いながら開発を進めます。
選抜チームに入らなかったメンバーに期待する貢献：①選抜チームの開発経過を共有するので、システム指示の改良すべき点を明らかにするために様々な対話を試してみる（豊富なバリエーションでいかに大量に試せるかが勝敗を分けるのでとても重要）；②①に基づいてシステム指示の改良案を提案する
出発点にするシステム指示（現時点までに私が書いた例）は、ここにあります。現時点では、これでいろいろな対話を試してください。このシステム指示は、今後、選抜チームで継続的に更新していきます。最新版をどうやって共有するかは、別途考えます。
選抜チームは分担方式で開発を進めます。分担項目の案（分担したい項目があれば選抜チームに入ってもらって、選抜チーム内で分担を調整；新たな項目を挙げてくれるのも歓迎）：
- 愚痴を聞いたり、決断の後押しをする対話のノウハウを取り入れる（心理相談員とかの専門家に尋ねる；専門的な知見を調べるなど）
- マルチモーダルの表出を頑張る（多分種類は増やせないという制約があった（要確認）と思うので、そうだとすると、どのようなときにどれを選ぶのがいいかをシステム指示中にどう書くとよいか、例示するのか等；タイミングはコントロールできるのか？）→種類は増やせない。タイミングは一部コントロール可能。
- システム指示中の対話例を充実させる（対話プランに沿った質の高い対話例を複数）
- 今Geminiで開発しているが、GPTに変更する際の変更の仕方や、GPTでの評価を受けての修正の仕方を検討
- コンペのマルチモーダル環境で早めに試せるようにする
- 今サンプルのシステム指示に入れてある「発話候補を３つ生成して、それぞれの発話が与える影響を評価して、高得点のを選ぶ」という岡が発案した方式が有効に働いているか調べ、改良する
- マークダウンでは#が##より大項目なのだが、今のシステム指示は逆になっているのでマークダウンに合わせた方がよいかも？→マークダウンの標準的な書き方に合わせた。　その他、システム指示の表記形式は改良の余地があるだろう
- （その他、これからここに書き足す）
- 開発にあたってのヒント：欠点をなくす／加点を増やすという２つの方針のどちらを狙っているかを明確に
- コンペの要求仕様に合っているかのチェック
- （以下は、（大規模言語モデル活用技術の最前線）を見ながら書き足しました。この資料の中盤から最後にかけてのページと大体対応する順に挙げています）
- 最初に対話プランを立てさせる
- 対話中にメモを取らせ、それを使って、筋の通った対話や決断の後押しを実現
- こう言ったら、こう言ってくるだろう、それに対してこう言うと、・・・のように先読みして、高い評価の状態に至るように発話を決める
- LLM自身に対話出力を修正させる
- LLMにシステム指示を最適化させる→試した例
- 重要な情報はシステム指示の最初か最後に書くのがよい？
- 重要なことは２回書くとよい？
- 複数のペルソナによる自己コラボレーション
- 対話のプラン（大まかな方向性）をシステム指示に書いておく
- 発話前に発話意図を出力させる；例：（指摘されたことについて考える）うーん
- ・・・
本番環境での開発は、~/github/Live_Competition_7/prompts/response_w_tts_style.txt，text_vap.txt，time_out.txt の 3 つのファイルにシステム指示を書き込む
- response_w_tts_style.txt には、通常の場合の対話用のシステム指示を書きます。
- time_out.txt はユーザが沈黙を続けている場合等、新しいユーザ発話が存在せずシステム自ら発話する場合のシステム指示を書き込みます。time_out.txt による発話が起動される具体的な条件は、システム発話終了後、５秒間ユーザ発話がない場合とのことです。
- text_vap.txt は、ユーザが話している途中のうなずき等のバックチャンネル動作の指定(a, b, c)と、テキストのみからユーザの発話終了を判定するための評価値(d)とを出力させるためのシステム指示を書きます。

ユーザ発話の終了判定のしかた：音声から行う発話終了判定（音声認識と同時に出る情報を使用）、もしくは、テキストのみを使用した発話終了判定のうち、どちらかが終了したと判定した場合、ユーザの発話が終了したと判定されます。text_vap.txt は、テキストから発話終了を判断するための評価値を出力するよう指示する形です。

text_vap.txt に関して変更可能な部分としては、基本的にはうなずきの方法や、発話終了の判定のための評価値の出し方を独自に制定する等の変更が取れます。例えば、a:直前のユーザ発話...1つ選択して出力してください。但し、〇〇を考慮してください。等の文を付け加えることや、相槌の種類を消す（aであれば「2_はい」を消す）等の変更を行うことができます。これらにより、取る相槌や発話終了判定のための評価値が変更できることが期待できます。しかし、プログラムの関係上、a, b, c, dはそれぞれかならず出力させるようにして、出力フォーマットも変えないことが望ましいです。

text_vap.txt に従ってa, b, c, dの値を出力するGPTは、どのようなタイミングでa, b, c, dを出力するよう制御されるのか？→基本的にはユーザが喋っている最中に逐次的に音声認識が実行されており、それらが逐次的に送信されるタイミングでtext_vap.txt に従うGPTが動作します。そのため、明確な基準等は特になく、ユーザが発話している最中に逐次的に複数回呼び出される形になっております。

主催者から提供されている text_vap.txt の例↓：a, b, c がバックチャネル動作を決める出力で、d が発話終了の判定に使われる値の出力。d の適切な値を gpt に出力させるためには、この値がどう使われるかを gpt に知らせる必要があると思います。現状は、「d>=6 であればユーザ発話終了と判定する」とのことなので、このことを gpt に知らせると、gpt が適切な d の値を値を出力する可能性が高まると思います。

a:直前のユーザ発話にうつことができる相槌（0_なし,1_うん,2_はい）を1つ選択して出力してください

b:直前のユーザ発話にassistantが表出すべき感情（0_平静,1_喜び,2_感動,3_納得,4_考え中,5_眠い,6_ジト目,7_同情,8_恥ずかしい,9_怒り）を1つ選択して出力してください

c:直前のユーザ発話にassistantが表出すべき動き（0_待機,1_ユーザの声に気づく,2_うなずく,3_首をかしげる,4_考え中,5_会釈,6_お辞儀,7_片手を振る,8_両手を振る,9_見渡す）を1つ選択して出力してください

d:直前のユーザ発話の内容がどの程度確定したかどうかを0（未確定）から9（確定）で出力してください

出力は以下のフォーマットに従ってください

a:0_なし

b:0_平静

c:0_待機

d:3

END

- 「システム側の声のスタイル、感情、動き」を指定することになっていますが、この指定をするためのフォーマットや、指定するタイミングは、変更できないとのことなので、上記の3ファイルに書かれている通りに従うようです。
- TTS の出力スタイルについて（これは、下記のように既になっているはず）
  1. TTS の出力スタイルを発話にあわせて chat・cheerful・customerservice の 3 つからプロンプトを用いて動的に変更することができます．TTS のスタイルを変更したい場合は config/config.yaml の ChatGPT 内の output_tts_style を on に、prompts 内の RESP を prompt/response_w_tts_style.txt に変更してください．
提出物

シチュエーショントラック参加チーム： 以下の５つのファイルをご提出ください。

response_w_tts_style.txt
text_vap.txt
time_out.txt
config.yaml
ASR用のJSONファイルも提出

config.yamlの変更可能箇所：

- 1. initial_utterance

ランダムで一つ、システムの対話開始時に取り出される発話（["発話1", "発話2", ...]で複数指定可能）

- 1. utterance_to_terminate

システム終了時の発話（1つのみ）

- 1. history_length

保持する対話履歴のターン数

- 1. max_tokens

システムの1発話における最大出力トークン数

- 1. response_generation_interval

逐次的に行われる音声認識から送られる部分的な発話に対し、何回毎にプログラム中で応答を生成するかを指定するしきい値

- 1. TIME_OUT: max_silence_time

何秒黙っていたらシステムから話しかけるかを指定

シチュエーショントラックの評価観点

これまで、評価観点は以下の3点としてお伝えしておりました。

文脈に沿った発話内容かどうか
文脈に沿ったジェスチャー・表情を表出できているかどうか
文脈に沿った間や音声の強弱を用いて発話できているかどうか

しかしながら、本トラックの開発範囲を考慮すると、間の柔軟なコントロールが難しいと判断し、2点目と3点目を統合し、以下の2つの評価観点に変更いたしました。

- 1. 文脈に沿った発話内容かどうか
  2. 文脈に沿ったジェスチャー・表情等のマルチモーダル情報を表出できているかどうか

なお、マルチモーダル情報の重要性は引き続き重視されますので、その点はご安心いただけますと幸いです。

OpenAI APIの費用

使用するAPIキーに関しまして、予選では参加者の皆様にご用意いただきます。一方、本選では運営側で用意いたします。

予選では30~40対話を実施予定ですので、そちらを目安にお見積りいただければと思います。

（参考までに、OpenAI API の料金表およびトークン数の算出ページをお載せいたします）→たとえば１対話３ドルとして、１００ドルくらい？最大５ドル／１対話として、最大２００ドル程度？最大で４万円程度の予算？

https://openai.com/ja-JP/api/pricing/

https://platform.openai.com/tokenizer

予選、本選におけるユーザ役のロールプレイの質

予選・本戦においてユーザ役を務める方々についてですが、シチュエーションは事前に読んでもらいますが、特別なスキルを持った方を集めたり、特別な練習を行ったりはしない予定です。あくまで、クラウドソーシングなどで集められた一般の方々が、シチュエーションを一通り読んでから対話に臨む形になります。そのため、ロールプレイの質には個人差が出る可能性があります。ただし、今年のシチュエーションが例年と比べて特に複雑ということはなく、これまでの経験からも、シチュエーションから逸脱する評価が多発するようなことは考えにくいと見ています。また、各システムに対して一定以上の評価数を確保することで、システムごとの評価において一定の質は担保できると考えています。

GitHubリポジトリ管理者用のメモ（一般のコンペ参加者は、ここの情報は無視して大丈夫）

主催者リポジトリ（プライベートリポジトリ）からのGitHub上の複製（プライベートリポジトリ）の作り方

ベアクローンを作成
- git clone --bare https://github.com/p1n0k0/Dialogue_System_Live_Competition_7.git
ミラープッシュする
- cd Dialogue_System_Live_Competition_7.git
- git push --mirror https://github.com/okana2ki/Live_Competition_7.git
一時ローカルリポジトリを削除
- cd ..
- rm -rf Dialogue_System_Live_Competition_7.git

という手順でやります。こうして作成したプライベートリポジトリにてソフトウェアをチームメンバーと共有。

主催者リポジトリの更新を、複製したリポジトリに反映

リポジトリが保存されているディレクトリに移動し、mainブランチにcheckout

- cd github/Live_Competition_7
- git checkout main
（リモートリポジトリの追加）
- git remote add parent https://github.com/p1n0k0/Dialogue_System_Live_Competition_7.git
主催者リモートリポジトリから差分をマージ
- git pull parent main
  - ↑parentからmainブランチをpull
複製したリポジトリに反映
- git push origin main
  - ↑originにmainブランチをpush

主催者リポジトリの新しいブランチを、複製したリポジトリに複製

cd github/Live_Competition_7
git checkout main
git branch feat/docker
git branch
- ↑ブランチ一覧を表示；「*」が使用中のブランチ
git checkout feat/docker
git pull parent feat/docker
- ↑主催者リポジトリのfeat/dockerブランチの内容を現在使っているブランチに複製
git push origin feat/docker
- ↑ローカルリポジトリのfeat/dockerブランチの内容をリモートリポジトリに反映（ブランチがなければ新たに作成される）

Page updated

Google Sites

Report abuse