メモをたくさん取る人として、私は自分のメモの取り方を洗練させるのに役立つツールや戦略（コーネルメソッドなど）を常に探しています。私は一般的にペンと紙を好みますが（記憶と統合に役立つことがわかっているため）、テクノロジーが蓄積された能力を高めるのに役立つことは否定できません。これは、積極的に参加しながらメモを取ることが互いに矛盾する可能性がある会議などの状況に特に当てはまります。メモを取るために下を向いたり、キーボードを叩いたりすると気が散って会話に集中できなくなります。重要な詳細について素早く判断しなければならず、以前の詳細を書き留めようとして重要な詳細を見逃すリスクが常にあるからです。言うまでもなく、連続した会議に直面した場合、何ページにも及ぶメモから重要な詳細を要約して抽出するという課題は複雑になります。そして、グループレベルで考えると、現代のビジネスでは、この種の管理オーバーヘッドにより、個人とグループの時間の無駄が大幅に生じます。
日々こうした問題に直面している私のチーム (私は OCTO (Office of the CTO) と呼んでいます) は、AI を使用してチーム ミーティングを強化する機会を見出しました。彼らは、Lambda、Transcribe、Bedrock などの AWS サービスを使用して仮想チーム ミーティングを書き起こして要約するという、シンプルでわかりやすい概念実証を開発しました。これにより、ミーティングのメモを収集できますが、議論の詳細な内容が自動的に記録されるため (ToDo リストも作成されます)、会話自体に集中できます。そして今日、私たちのチームが「Distill」と呼んでいるこのツールをオープンソース化します。他の人にも役立つことを期待しています: https://github.com/aws-samples/amazon-bedrock-audio-summarizer。
この記事では、私たちのプロジェクトの高レベルなアーキテクチャとその仕組みについて説明し、Amazon Q Developer と協力して Distill を Rust CLI に変換する方法についてプレビューします。
アプリ自体はシンプルです。これは意図的なものです。システムはできる限りシンプルにすべきですが、シンプルすぎるのはよくないという考えに私は賛成です。まず、会議の音声ファイルを S3 バケットにアップロードします。次に、S3 トリガーが Lambda 関数に通知し、文字起こしプロセスが開始されます。event bridge ルールを使用して、summarizer- で始まる Transcribe ジョブのステータスが COMPLETED に新しく更新されると、2 番目の Lambda 関数が自動的に呼び出されます。文字起こしが完了すると、この Lambda 関数が文字起こしを受け取り、要約を作成するための指示プロンプトとともに Bedrock に送信します。今回の場合、推論には Claude 3 Sonnet を使用していますが、コードを適応させて、Bedrock で利用できる任意のモデルを使用することもできます。推論が完了すると、会議の要約 (概要と ToDo を含む) が S3 バケットに保存されます。
私はインフラストラクチャをコードとして扱うことの重要性について何度も話してきました。そのため、このプロジェクトのインフラストラクチャの管理には AWS CDK を使用しました。CDK は、リソースをデプロイするための信頼性が高く一貫性のある方法を提供し、インフラストラクチャを誰とでも共有できるようにします。さらに、アイデアを迅速に反復する優れた方法も提供してくれました。
これを試してみると (ぜひ試してみてください)、セットアップは簡単です。リポジトリをクローンし、README の手順に従って、CDK を使用してアプリ インフラストラクチャをアカウントにデプロイします。その後、ツールを使用する方法は 2 つあります。
以下は、チームの一部のみが出席できた最近の OCTO チーム ミーティングからの出力例 (最小限のサニタイズ済み) です。
読みやすい段落で会話を要約すると次のようになります。
グループは、VivaTech や re:Invent などの今後のイベントの潜在的なコンテンツのアイデアやアプローチについて話し合いました。基調講演を行うか、炉辺談話やパネルディスカッションを行うかについての提案がありました。今後のイベントで考えさせられるものを作り上げることの重要性が強調されました。
チームは、ヴェルナー氏の最近のアジアツアーを振り返り、地元の大学生、開発者、スタートアップ企業、恵まれないコミュニティとの交流などのハイライトを振り返りました。インドネシアの障害者のインクルージョンに関する取り組みは称賛されました。ロジスティクス、仕事と休憩時間のバランス、ヴェルナー氏にとって最適なイベント形式などについて、有益なフィードバックが共有されました。グループは、これらの学習内容を社内ニュースレターにまとめることを検討する予定です。
取り上げられたその他のトピックには、ジェフが仮想的に出席する可能性のある今後の諮問会議や、社会的影響とグローバルな視点に重点が置かれた現代の CTO の進化する役割などが含まれます。
さらに、チームはこれらの要約をチーム チャンネルに自動的に投稿する Slack Webhook を作成しました。これにより、参加できなかったメンバーも議論の内容を把握し、アクション項目をすばやく確認できるようになります。
覚えておいてください、AI は完璧ではありません。上記を含め、私たちが返す要約の一部には、手動で調整する必要があるエラーがあります。しかし、それでもプロセスはスピードアップするので問題ありません。これは単に、私たちが依然として識別力を持ち、プロセスに関与する必要があることを思い出させるだけです。批判的思考は、これまでと同様に今も重要です。
これは、すばやく構築してクラウドに展開し、組織の効率化につながるシンプルなアプリの一例にすぎません。どの調査を見るかによって異なりますが、企業の従業員の約 30% が、会議の重要な情報を思い出せないためにアクション アイテムを完了できないと回答しています。会議の直後にカスタマイズされたメモを配信したり、会議から作業項目を自動的に作成して適切な人に割り当てるアシスタントを使用したりすることで、このような統計を少しずつ減らすことができます。テクノロジーで「大きな」問題を一挙に解決することが常に重要というわけではありません。時には、日常的な問題を少しずつ解決することが重要なこともあります。漸進的で有意義なイノベーションの基盤となるシンプルなソリューションを見つけることです。
私は特に、これが次にどうなるかに興味があります。私たちは今、AI 搭載のボットが通話中にリアルタイムで行動できる世界に住んでいます。メモを取ったり、質問に答えたり、タスクを追跡したり、個人情報を削除したり、1 人がデータを探している間に通話が滞ったり遅くなったりしていたようなことを調べたりもします。私たちのシンプルなアプリを共有することで、その意図は「何か新しくて輝かしいもの」を披露することではなく、私たちが作れるのならあなたにもできるということを示すことです。そして、オープンソース コミュニティがそれをどのように使うのか、どのように拡張するのか、その上に何を作成するのか、とても興味があります。そして、これが私が本当にワクワクすることなのです ― シンプルな AI ベースのツールが、ますます多くの方法で私たちを助けてくれる可能性。人間の創意工夫に代わるものではなく、私たちをより良くする補助として。
そのため、チームと一緒にこのプロジェクトに取り組んでいるうちに、このツールを Rust CLI に変換するという私自身のプロジェクトに取り組むようになりました。
私が Rust の熱狂者になったのは、Marc Brooker と Colm MacCárthaigh のおかげです。私は根っからのシステム プログラマーで、この言語に慣れるにつれて、その熱狂はどんどん高まりました。そして、さまざまなプログラミング言語のエネルギー、時間、メモリ消費に関する Rui Pereira の素晴らしい研究に出会ったとき、それがクラウドでより持続可能な構築を行う上で大きな可能性を秘めていることに気付き、私にとってそれがさらに重要になりました。
Distill での実験中、関数を Python から Rust に移行するとどのような影響があるかを確認したいと考えました。CDK を使用すると、スタックに簡単な変更を加えるだけで、Lambda 関数を AL2023 ランタイムに移行し、Rust ベースのコード バージョンをデプロイできるようになりました。興味がある方のために説明すると、この関数の平均コールド スタートは、Python バリアントに比べて 12 倍高速 (34 ミリ秒対 410 ミリ秒) で、メモリ使用量は 73% 少なくなっています (21 MB 対 79 MB)。これに刺激を受けて、実際に手を動かしてみることにしました。このプロジェクトをコマンド ライン ユーティリティに変換し、Ken Youens-Clark の「Command Line Rust」で学んだことを実践するつもりでした。
私はいつもコマンドラインで作業するのが好きでした。小さな黒いボックスで grep、cat、curl を実行するたびに、古い車を運転しているのを思い出します。少し曲がりにくく、音を立てて不満を言うかもしれませんが、マシンとのつながりを感じます。そして、メモを取るのと同じように、コードを積極的に操作すると、覚えやすくなります。
私は Rust の達人ではないので、Q を試してみることにしました。サンプル コードで見た言語、イディオム、所有権モデル、Tokio などの共通ライブラリについて、まだ多くの疑問があります。正直に言うと、コンパイラが何に反対しているのかを解釈する方法を学ぶことは、おそらく私にとって Rust プログラミングで最も難しい部分です。IDE で Q を開いておくと、恥ずかしい思いをせずに「愚かな」質問を簡単に投げかけることができ、Q が提供するリファレンスを使用すると、大量のドキュメントを掘り起こす必要がありません。
CLI が形になり始めると、Q の役割はより重要になり、コーディングや設計の決定に役立つより深い洞察を提供しました。たとえば、スライス参照を使用すると、アイテムの大きなリストで非効率性が生じるかどうかが気になりました。Q はすぐに、配列のスライスは新しい配列を作成するよりも効率的である可能性があるが、大規模な場合はパフォーマンスに影響する可能性があると説明しました。会話をしているような感じでした。Q にアイデアをぶつけ、自由にフォローアップの質問をし、即座に非批判的な回答を受け取ることができました。
最後に、コードを Q に直接送信する機能について触れておきます。私はコードのリファクタリングと最適化を試してきましたが、これによって Rust の理解が深まり、自分が書いたコードについてより批判的に考えるようになりました。これは、開発者が慣れ親しんでいる場所 (私の場合は IDE) に適したツールを作成することがいかに重要であるかを示しています。
今後数週間で、Rust CLI のコードを共有する予定です。これを仕上げるには少し時間が必要ですし、もう少し経験のある人にレビューしてもらう必要がありますが、ここでちょっとだけお見せします。
いつものように、さあ構築しましょう! 構築中は手を汚してください。
元記事: https://www.allthingsdistributed.com/2024/05/hacking-our-way-to-better-team-meetings.html