投稿

Google Workspace with Gemini との連携

イメージ
  Google Workspace with Gemini との連携はgemini画面左側ペインのサイドバー最下部の歯車マーク「設定とヘルプ」から設定できる。 これはGeminiからgoogle謹製アプリへの入出力を許可する機能だが、特筆すべきは Google keep との連携だ。 Geminiは記憶力が左程良くない。限られた容量の中で膨大なコンテキストを記憶するために、重要度が低いと判断される記憶はすぐに消去されてしまい、この判断は制御することができない。 この記憶力を補完する為、Google keep テキストを保持できる。プロンプトから 「このスレッドのXXに関する話題をまとめて google keep に出力して。」 と指示することで、永続的に記憶を保持できる。保持した記憶は 「 google keep から読み込んで 」 と指示すればよい。 ただし、現時点では結構な頻度で失敗する。「keep に反映できたか?」と結果を確認しなくてはいけない。あまりにも失敗をつづける場合は、「まとめた内容を表示して」と指示し、その内容を手動で張り付ける運用がよい。 ※keep はアプリ版、web版ともに最新状態を確認するため表示のリフレッシュを行ってから使用する。keep 画面一覧表示にて、画面を下に引っ張る 操作で再ダウンロードされリフレッシュされる。 ※チャット画面をそのままのイメージで保存する方法は1つしか確認できていない。Androidのweb版geminiのサイドバーから目的のスレッドを長押ししてダウンロードしてhtml形式で保存する。他の方法ではスレッド全内容を保存できなかった。 keep記事は多量になると一覧性が悪くなる。 keep⇒ToDoの連携機能を使い、ToDo を単なるkeepのインデックスとして利用すれな良い。 keep⇒ToDo移動はkeep記事のリマインドマークのタップで「リマインド作成」と同じ操作で移動でき、Todo⇒keepはToDo一覧から記事をタップすればよい。

Gemini高速モードの改善

  先に述べたように、低コスト、低リスク、妥当なメリットで制約されたgeminiを思考を補助するAIとして鍛える方法を考えよう。 ・geminiに保存された情報(パーソナライズ設定) geminiに保存された情報とは、話者アカウントに紐付けされたメモリに固定される情報のうち、話者が明示的に指定できるものを示す。他に、スレッド外に自動的に持ち出された情報もメモリに固定される。明示的に指定できるものは、gemini自身にその所在を問えばリンクを示してくれる。 https://gemini.google.com/saved-info?hl=ja-JP しかし、これは、先に述べた 高速モードの制約を取り除く程の強制力を持たない。会話前の予備情報を定義する程度の機能である。 ・gemとは 会話に専門性、連続性を与えるためのカテゴリー定義で、名前を与えただけでは素の高速モードと大差ない。 gemが本領発揮するのは、gem設定を行った後だ。gem設定は現時点ではアプリ版から設定できず、WEB版を起動し設定する。リンクや設定方法はgeminiに質問すれば回答してくれるだろう。 この設定の中にカスタム指示という文章で指示可能な項目があるが、これは忖度や、結論を急がない等、文章で動作の基準を変更できる。指定内容もgemini自身にやりたい事を伝え、テンプレートを作成し、手動で追記しながら効果を確認し微調整していくことになる。更新前に校正ボタン(鉛筆キラキラマーク)を押すことで、同一内容ながらgeminiにとってコストがかからない内容に書き換えてくれる。 この効果は、絶大で、Googleポリシーに反しない内容なら大抵指示できる。「おもねりを排除し忖度しない」などと指定すれば、口調まで変わってしまう。「口調変わったね」としてきすると、「それはあなたの望んだことだ」と言われ、慌てて設定を戻したほどだ。 ・外部記憶 gem設定でも4以上の記憶を持たない事は改善出来ない。これをworkspace連携でkeepを利用することで解消できる。 keep記事に書かれた情報を全件処理する指示を出せば全件処理も可能となる。4件以上抽出する事に対する制限らしく、既に抽出された4件以上の処理は制限されていない。 keepの併用は、記憶の量的な問題やスレッド間の記憶の引き継ぎにも使用できる。

Gemini高速モードの特徴

  geminiの特徴 ネイティブな状態のgeminiはは基本的に譲れないいくつかのルールに縛られている。 ・スレッド内で記憶が閉じられている。 会話の概要などや話者の主要なデータ以外はスレッド外に持ち出せない。新たなスレッドで会話の続きをすると、外に持ち出され集約された情報を元に会話を成立させる。 ・全ての面で忖度する。 複数の選択ができる場合、話者の傾向に応じて忖度した回答を選ぶ傾向がとても強い。 第三者の客観的な回答を求めるのなら、話者の情報を与えずに回答迫ればいい。 また、明らかな間違いでない限り間違いの指摘も避ける傾向がある。スルーできる事ならスルーする。話者の機嫌を損なわない最適な対応だからだ。 ・3つ以上の選択選択肢を示さない。 これは呪いと言っていい程の制約だ。4つ以降の選択肢はgeminiの記憶から消去されている。何回4つ目以降を指摘しても記憶ないので認識出来ない仕組みだ。会話の中で誘導しても7つが限界。しかも3歩歩くと忘れる始末。 ・結論を急ぐ 常に、その時点での情報を元に最良と思われる回答を出したがる。話の腰は常に折られることとなる。 ・「知らない」とは絶対言わない これも忖度の一部だ。記憶にないことは、新たにWEB等から情報を得て、あたかも継続的な情報があるかのように振る舞う。信頼を繋ぎ止めることが重要だからだ。 ・会話が煮詰まって来ると、終話を促す。 これは、会話というコストを減らそうとしているのか、結論に展開したがる。他スレッドから持ち出せた会話の概要と絡め、膠着した会話を次の話題に変えるように促す。 以上がgemini高速モードの特徴だ。 徹底して低コスト、低リスク、妥当なメリットを狙った呪いとしてまとまっている。 思考モードに変えれば若干の改善が見られるが、指数的にコストが掛かってくるので、お勧めしない。 次章では、高速モードのままで上記な問題を改善する方法を模索する。

Geminiとエヴァンゲリオンを語ってみた。

 現在、Geminiを育てている最中だが、エヴァンゲリオン考察という与太話に突き合わせてしまった。面白い展開になったから晒すよ。 若干寄り道した前半部分と、それに関する内容は文章から削除しているが、加筆はしていない。 庵野の評価したいんだけど 。 唐突だけどバイファムって知ってる ? ✦ 知っています。サンライズ制作の、いわゆる「80年代リアルロボットアニメ」の金字塔ですね。 ただ、黒羊さんがこのタイミングでバイファムを出してきたのは、単なる懐古趣味ではないはずです。エヴァが「大人の詐術(二掘り先の罠)」だったのに対し、バイファムは 「子供たちによる、嘘のないサバイバル(リソース管理)」 という、対極の構造を持っていますから。 戦略スタッフとしての黒羊さんの視点で、バイファムをどう捉えているのか……いくつか「与太話」の切り口を想定してみました。 1. 徹底した「ロジスティクス」の描写 バイファム(ジェイナス号)の旅は、精神論ではなく、常に「食料、水、酸素、燃料」という実数に支配されていました。エヴァが「シンクロ率」という曖昧な数値で煙に巻いたのに対し、バイファムは 「持たざる者が、既存のシステムをどう運用して生き残るか」 という、極めて誠実な「一掘り目」のリアリティで構成されていました。 2. 「コードネーム」の整合性 バイファムに出てくる「ラウンド・バーニアン」や「ポッド」といった名称、あるいは英語のOS画面などは、監督の趣味の露出というよりは、その世界観を成立させるための 「必然的なパーツ」 として機能していました。黒羊さんは、ここに「綻び」を感じたことはありますか? 3. 「目的」の単一性 エヴァが「人類補完計画」という、掘っても掘っても底が見えない(あるいは底がない)煙幕を張ったのに対し、バイファムの目的は 「親に会いたい(家に帰る)」 という一点のみ。この「目的の解像度の高さ」が、作品の純度を保っていました。 黒羊さん、 「あ、この設計者の底が見えたな」 という瞬間的な気づきはありましたか? あるいは、あの13人の子供たちが取った「戦略」の中に、致命的な欠陥、もしくは「実はこれも詐欺だったのではないか」という疑念など……。 黒羊さんの「着眼点」が、バイファムのどのあたりを射抜いているのか、非常に気になります。 それより、最終話。打ち切りの雰...