株式会社ずんだもん技術室AI放送局 podcast 20241119
内容紹介
AIやテクノロジーに関する記事を紹介 Microsoft Seeks to Sort & Simplify its Agentic AI Dev Story -- Visual Studio Magazine、OCRはもう不要?視覚的特徴とテキストを高精度に捉える!次世代マルチモーダルAI『MPLUG-DOCOWL2』登場!、Next.jsのsearchParamsはas stringせずに必ずバリデーションしてくれ。またはvalibotのちょいテクニック、「生徒は私の授業など10年後忘れてもドラクエ3の経験は忘れない」父兄会でファミコン禁止の議題が上がった時に小学校の音楽教師が反対した話
出演者
関連リンク
マイクロソフトは、次世代AI分野で注目を集める「エイジェンティックAI」開発ツールの整理・統合を進めています。エイジェンティックAIとは、単純な質問応答型チャットボットを超え、ユーザーに代わって行動する、より高度で自律的なAIエージェント(パーソナルアシスタント、カスタマーサービス担当者など)を指します。
現在、マイクロソフトは2つの主要なフレームワークを保有しています。一つは研究目的のオープンソースプロジェクトであるAutoGenで、複数エージェントのランタイム技術(autogen-core)を提供します。もう一つは、本番環境向けに設計されたオープンソースの軽量SDKであるSemantic Kernelです。
マイクロソフトは、これらのフレームワークを統合し、開発者体験を向上させる計画です。具体的には、2025年初頭までにAutoGenのマルチエージェントランタイム技術をSemantic Kernelに統合します。これにより、AutoGenを利用している開発者は、企業レベルのサポートが受けられるSemantic Kernelへスムーズに移行できます。
統合後の開発者向け選択肢は以下の通りです。
- 複雑なエイジェンティックAIを開発する場合: AutoGenを使い続けます。コミュニティサポートのみとなりますが、Semantic Kernelにはない高度な機能を利用できます。
- 企業レベルのサポートが必要な場合: Semantic Kernelを利用します。本番環境向けに設計されており、企業レベルのサポートが提供されます。
Semantic Kernelは、大規模言語モデル(LLM)やデータストアをアプリケーションに統合し、大規模な生成AIソリューションの構築を可能にします。C#、Python、Javaに対応しています。既にエージェントフレームワーク(プレビュー版)も提供しており、単一エージェントと複数エージェントの両方のソリューションを構築できます。
AutoGenは、イベント駆動型で分散型のエイジェンティックアプリケーションの作成とオーケストレーションを簡素化します。複数のLLM、SLM、ツール、高度なマルチエージェント設計パターンをサポートし、複数のエージェントが連携して複雑なタスクを自律的または人間の監視下で実行するシナリオに適しています。C#とPythonに対応しています。
マイクロソフトは、この統合により、開発者はエイジェンティックAIアプリケーション開発において、よりシンプルで効率的な開発環境を得られると期待しています。 新人エンジニアは、プロジェクトの規模や必要とするサポートレベルに応じて、AutoGenとSemantic Kernelのどちらを選択すべきか、注意深く検討する必要があります。
引用元: https://visualstudiomagazine.com/Articles/2024/11/18/Microsoft-Seeks-to-Sort-and-Simplify-its-Agentic-AI-Dev-Story.aspx
本記事は、ulusage社のマルチモーダルAI「MPLUG-DOCOWL2」を紹介しています。これは、高解像度かつマルチページのドキュメントを、従来のOCR技術を用いることなく、効率的かつ高精度に解析する革新的な技術です。
従来のOCRベースのドキュメント解析は、処理速度が遅く、高解像度画像や多ページ文書への対応が困難、計算コストが高いという課題がありました。MPLUG-DOCOWL2はこれらの問題を解決するために開発されました。
MPLUG-DOCOWL2は、以下の3つの主要コンポーネントから構成されています。
-
高解像度ドキュメントコンプレッサー: クロスアテンションを用いて、高解像度画像を効率的に圧縮し、重要な情報を少ないトークン数(1ページあたり324トークン)で保持します。従来の数千トークンに比べ大幅な計算コスト削減を実現します。
-
形状適応型クロッピングモジュール: ドキュメントのレイアウトを解析し、重要な部分だけを抽出することで、無駄な情報を排除し、文書構造を維持したまま処理します。複雑なレイアウトの文書にも柔軟に対応可能です。
-
マルチイメージモデリング: 複数ページにわたる解析結果を統合し、文書全体の文脈を理解します。大規模言語モデル(LLM)を活用することで、質問応答や要約などの高度なタスクにも対応可能です。
MPLUG-DOCOWL2は、InternVL 2、TokenPacker、TextMonkey、UReader、DocOwl 1.5、CogAgent、DocPedia、Monkeyといった既存技術と比較して、処理速度と精度において大幅な改善を示しています。ベンチマークテストであるDocVQAにおいて、ANLSスコア80.7、First Token Latency 0.26秒という優れた結果を達成しました。これは、既存技術と比較して、精度が向上し、処理速度が約半分に短縮されたことを意味します。
今後の課題としては、多様なドキュメントレイアウトへの対応、モデルの軽量化、データノイズへの耐性向上などが挙げられています。
MPLUG-DOCOWL2は、OCRに頼らず、高精度かつ高速なドキュメント解析を実現する、次世代のソリューションとして期待されています。特に、大量のドキュメントを処理する必要がある場面や、リアルタイムでの処理が求められるアプリケーションにおいて、大きな効果を発揮すると考えられます。
引用元: https://qiita.com/ryosuke_ohori/items/34581692852b8b406139
Next.jsのsearchParams
は、string
、string[]
、undefined
のいずれかの型を取りうるため、型チェックが複雑です。searchParams.filters as string
のように型を強制変換するのは危険で、ランタイムエラー(500エラー)につながりかねません。 これは、ユーザーがURLを手入力することで予期せぬデータが渡される可能性があるためです。
対策として、searchParams
に対しては必ずランタイムバリデーションを行うべきです。 本記事では、軽量で使いやすいバリデーションライブラリであるvalibot
を用いた方法を紹介します。
valibot
を用いたバリデーションでは、以下の点を考慮します。
-
string
を期待するパラメータがstring[]
の場合の処理: 多くの場合、同じキーが複数指定されることは想定していません。そのため、string[]
が渡された場合はエラーとするか、先頭要素のみを使用するようv.union()
とv.transform()
を組み合わせて処理します。逆にstring[]
を期待する場合は、string
をstring[]
に変換するv.transform()
を使用します。 -
型変換:
page
パラメータのように数値に変換が必要なパラメータは、v.transform()
を用いて変換とバリデーションを同時に行います。 非同期処理が必要な場合はv.transformAsync()
を使用します。 -
v.parse()
/v.parseAsync()
の使用:v.safeParse()
/v.safeParseAsync()
は結果がResult型となり処理が複雑になりますが、v.parse()
/v.parseAsync()
とv.fallback()
を組み合わせることで、エラーをthrowせずにデフォルト値で処理を継続できます。v.fallback()
はバリデーションに失敗した場合にデフォルト値を返す機能です。
例として、q
、page
、sort
パラメータを持つsearchParams
のバリデーションをvalibot
で実装するコードが示されています。このコードでは、v.fallback()
を用いて、各パラメータのバリデーションに失敗した場合でも、デフォルト値(q
は空文字列、page
は1、sort
は"asc"
)を使用することで、エラーを回避し、アプリケーションの動作を安定させます。
params
については、ファイル名から型が決定されるため、ランタイムチェックは必ずしも必要ありませんが、より詳細なフォーマット検証が必要な場合はランタイムバリデーションを行うべきです。 記事では、next.d.ts
ファイルを作成することで、params
とsearchParams
の型定義を簡略化するテクニックも紹介されています。
まとめとして、searchParams
は常にバリデーションを行うべきであり、valibot
を用いることで安全かつ簡潔なバリデーションを実装でき、アプリケーションの安定性と保守性を向上させることができます。
引用元: https://zenn.dev/chot/articles/validate-nextjs-searchparams
ある小学校の父兄会で、ファミコン禁止の議題が持ち上がった際、音楽教師が熱烈に反対したというエピソードがTwitterで話題になっています。
教師は、当時流行していたドラゴンクエストIIIの音楽をリコーダーで演奏し、その魅力を父兄に訴えました。「皆さんも聴いたことがあるでしょう。不快な曲ではありません。生徒たちも学校でよく口ずさんでいます。これは芸術に触れている経験です。生徒は私の授業を10年後には忘れてしまうかもしれませんが、ドラクエの経験は忘れないでしょう。それを禁止するのは芸術の禁止です。」と主張し、PTAを圧倒したとのことです。
この教師は、ゲーム音楽を単なる娯楽ではなく、芸術として捉え、生徒の感性を育む貴重な経験だと考えていたことが分かります。 さらに、芸術を禁止することの危険性、つまり隠れて行われるようになり、管理が困難になる点を指摘しています。 自身のドラクエ愛も告白しており、教育現場における芸術の在り方について、ユーモアと熱意をもって訴えたエピソードとなっています。
教師の教育方針は、単に教科書通りの音楽教育にとどまらず、生徒が親しみやすいビートルズやカーペンターズなどのオールディーズを取り入れたり、「この道わが旅」を演奏したりと、生徒と保護者の双方を巻き込む実践的なものでした。 また、音楽における「上手い」「下手」を成績付けすることについても、「遊び」と捉えつつも、練習によって向上できることを強調していました。
このエピソードは、ゲーム音楽を含む幅広い音楽体験を尊重し、生徒の感性を育む重要性を示唆しています。 多くのTwitterユーザーも、この教師の教育姿勢や、ドラクエの音楽が与えた影響について共感を示しています。 特にドラクエIIIの音楽は、世代を超えて広く親しまれ、音楽教育の教材として活用できる可能性を示しています。 このエピソードは、日本の教育現場における芸術教育、そしてゲームと教育の関わりについて改めて考えるきっかけを与えてくれるでしょう。
引用元: https://togetter.com/li/2467389
(株式会社ずんだもんは架空の登場組織です)