注：この記事は2024年9月1日に書かれたものであり、記事の結論は時間の経過とともに変わる可能性がある。

なお、本記事は非アルゴリズムチームのプロダクトマネージャーである読者を対象としており、記事の読みやすさを確保するために細部が省略されている場合があるほか、学術的な議論よりもエンジニアリングの着地点に焦点が当てられており、弁明の価値はない。

1.AI製品のエンジニアリングを理解する

率直に言って、2024年のビッグモデル周りの製品開発のペースは、以前予想されていたよりも少し低いです。例えばBIの分野では、チャットBIは大きな声を持っていますが、現場ではうまく機能していません。

客観的な理由がある、業界自体のすべての側面への実際のアプリケーションの技術基盤は、この技術が行く必要があるため、プロセスの必要性であり、プログラムの元の実装では、競争を行うには、ユージュンとしてよく知られている需要式を与えた：

ユーザー価値＝新しい経験-古い経験-代替コスト。

新しい技術であっても、その恩恵が思ったほど大きくないことが多いのは事実です。

もう1つの理由は、実務者の理解である。一部の大手インターネット企業でさえ、ほとんどの人が大きなモデルのメリットとデメリットをある程度理解している。"事実 "は、世代間ギャップにある程度の理解があるということだ。

現在、技術の進歩は非常に速く、あらゆる種類の練習方法があるため、このようなものが全能だと思う人もいれば、このようなものはまったく機能しないと思う人もいるだろう。

なぜ人によって、このようなことの理解がこれほど違うのでしょうか？その理由の大部分は、インターフェイスとしてのビッグモデルと製品としてのビッグモデルの違いを理解していないからだ。

ビッグモデルは、それ自身によってのみ呼び出すことができる関数、APIとして見ることができます。

例えば、ビッグモデルAPIにエクセルを渡すと、「申し訳ありませんが、このファイルの内容を読み取る方法はありません」と言われます。しかし、Kimiのチャットボックスでは、KimiにExcelの内容を解釈してもらうことができます。

Kimiはビッグモデル製品であり、その背後でMoonshot-v1モデルを実行しているため、Kimi Chatはあなたのエクセルを読み、それをビッグモデルへのXMLメッセージに変換します。(推測ですが）

製品へのエンジニアリングのモデルは、多くの場合、制限の多くを追加します、これらの制限は、製品レベルで行われるのではなく、API自体が制限するために、例えば、コストを削減するために多くの製品は、PDFのサイズをアップロードするユーザーを制限しますが、APIを使用する場合は、そのような制限はありません、または制限は非常に大規模に置くことができますが、前提は、PDFのモデルに最初に変換する必要があることを理解することができます！ファイル形式に変換します。

市場の製品は、エンジニアリングの変換の多くを行う、さらには機能リコール作業を直接製品を使用して、大きなモデルの長所と短所を理解するために、プロダクトマネージャに資するものではない、それは大きなモデルのアプリケーションに資するものではない、既存の製品を改善する。

では、なぜプロダクトマネージャーはビッグモデル製品よりもビッグモデルそのもの（API）に関心を持つべきなのかというと、APIから製品までの間のエンジニアリング変換プロセスこそが、プロダクトマネージャーが最も注力すべき重要なことだからです。

大きなモデルは脳のようなもので、エンジニアとプロダクトマネージャーは大きなモデルのために五感、胴体、手足を設計する必要がある。脳と手には障害があるため、エンジニアとプロダクトマネージャーはAI製品の良し悪しを判断するのに非常に重要であり、発達した手足や単純な手足、単純な心では結局ユーザーの製品を解決することはできない。

たぶん、前者の方がユーザーにとっては悪いことかもしれない。

優れたAI製品を作るには、単に大きなモデルが必要なだけでなく、大きなモデルを支援する優れたエンジニアやプロダクトマネージャーが必要です。

そのためには、プロダクトマネージャーは次の2つのことをよく知っていなければならない。

では、次のように説明します。
1. 現段階での大規模モデルの限界は何か。また、これらの限界のうち、モデルの反復によって解決できるものとできないものはどれか。
2. より根本的なビジネスの観点から分析した場合、ビジネス的な意味でのビッグモデルの本当の価値とは何か？ここで強調されているのはビジネスの視点であり、プロダクトマネージャーに論文を読ませることではないことに注意してください。

2.大型モデルの限界とは？

2.1、決して解決されないかもしれないいくつかの問題

2.1.1、コスト、パフォーマンス、対応性

大きなモデルでより高い性能を求めれば求めるほど、計算コストが高くなります。

コスト計算には2つの問題がある。

• 直接的な金銭的コスト
• 応答性

下図はApple Intelligenceのアーキテクチャを示しており、末端には2つのモデルがあり、クラウドにはプライバシークラウドコンピューティングに基づくより大きなモデルがある。

なぜアップルはこのようなエンジニアリングサイズのモデル設計を行うのでしょうか？

このアーキテクチャが採用されたのは、Appleが大型モデルの応答性をSiriの現在のパフォーマンスに追いつかせたかったからであり、一方でモバイルデバイスは本質的に消費電力の点で要求が厳しく、またAppleはプライバシーを重視し、問題の80%はユーザーによってローカルに解決されることを望んでいるからです。

metaの最新のオープンソースllama 3.1を実行するには、70 bバージョンではおよそ70 GBのビデオメモリが必要で、405 bバージョンでは400 GBのビデオメモリが必要になるかもしれません。

小型および大型モデルの設計のこの種は、製品管理者を必要とする、もちろん、どのような問題を解決するために小型モデルに適しているか、どのような問題を解決するために大型モデルに適している、研究開発だけでなく、答えをする必要があることは明らかであるが、また、製品管理者が参加する必要があり、次の部分を担当：

• 現在のユーザーのクエリを収集します。
• 解決の難易度、プライバシー、適時性の要件、正確性の要件の観点からクエリを分類する。
• ベンチマークテストを設計し、サイズ・モデルの区分の基準を得る
• 継続的なトラッキングの最適化。

少なくともこれから長い間、ローカル／ネットワークでの戦いはまだ続くだろうし、これはプロダクトマネージャーにとってはチャンスだ。

2.1.2、ウィンドウサイズと不安定性

よく「○○のビッグモデルは128Kのコンテクストをサポートしている」というのを見かけます。

今回も、「○○ビッグモデル幻想」が深刻な問題であり、暴言につながることがよく見受けられます。

コンテキストとはどういう意味でしょうか？実は、大きなモデルが1つのリクエストの過程で受け取ることができるメッセージの最大数のことです。ChatGPTとチャットしていると、コンテキストの数を超えたために、チャットしているうちに前に言ったことを忘れてしまうことがあります。

一方、幻覚とは、大きなモデルが、実際には存在しないことをでっち上げたり、おしゃべりをしたりする傾向があることを意味する。特に、以前にあなたに言ったことを忘れた後、あなたが彼に同じような質問をすると、おしゃべりを始める。

卑劣な男と同じように、あなたは手をつないできた。

あなたは「私の名前は？

彼はこう答えた。

実は、彼は名前を覚えていなくて、作り話を始めたんだ。ジェダイ、こいつは本当に人間に似ている。

NVIDIAの論文 "RULER: What's the Real Context Size of Your Long-Context Language Models? "によると、モデルによって宣伝されているコンテキストウィンドウのほとんどは、基本的に単なるでたらめであり、正しいレベルの大きなモデルのそれぞれの長さの限界ではありません。を保証するものではありません。

あるモデルが、128kのコンテキストをサポートしている（つまり、20万語の小説をほとんど読むことができる）と宣伝しているとします。しかし、実際には、小説の中にいくつかのランダムな文章を詰め込み、それらの文章について知っていることについての質問に答えるよう大きなモデルに求めると、比較的高い確率で答えることができません。

以下に示すように、GPT4 の場合、コンテキストが 64k を超えると、パフォーマンスが急落し始めます。

現実的に言えば、これらのモデルはあなたが考えているよりも悪い結果になると思います。

クロード3.5のソネットモデルにSQLの一部を分析させました。SQLは700行の複雑なものですが、ロジックは一般的に比較的単純なはずで、SQLのほぼすべての行に注釈が付けられています。モニカのクライアントからSonnetを呼び出している可能性も否定できないし、モニカが何らかのプロンプトを追加していて、それがモデルを呼び出すときに干渉しているのかもしれない。

ユーザーの問題を確実に解決しながら、文脈の影響や干渉を避けるにはどうしたらいいでしょうか？実は、これはプロダクトマネージャーの介入も必要なことなのです。

• 最終的な結果に影響を与えることなく、長いテキストを複数の段落にスライスすることが可能かどうかを調査する
• 超長時間記憶できるAIに記憶バンクを追加する方法を研究している

たとえば、ナゲッツには上記の記事「8 Optimization Ways to Keep AI in Long-Term Memory in Multi-Round Dialogues (with Cases and Code)」があり、8つの主流のアプローチについて述べられています。

https://juejin.cn/post/7329732000087736360

の記事。

コンテキストウィンドウと不安定性の問題は、長期的に解決するのが難しい問題だと思う理由について、最後にお話しします。

コンテキストウィンドウサイズの問題は、過去にいくらか緩和されましたが、NVIDIA の論文によると、コンテキストウィンドウサイズと、幻覚を避けるためのコンテンツの安定した抽出という 2 つの指標は、レコメンダーシステムの精度と想起の指標のように、ほぼ相互に排他的であることもわかります。

これはまた、一方では錯覚の問題を解決し、他方では巨大な窓を保証するモデルが突然現れない限り、長い間、双方向の通りがない可能性があることを意味する。

そして、実際には、多くの場合、極端なケース（私自身が遭遇したSQLの解析エラーの700行など）を回避する必要があり、コンテキストのサイズを小さくすることは、実際には検出の異なる手段に加えて、重要な手段であり、モデルのパフォーマンスはまったく同じではありません、つまり、異なるビジネスシナリオは、問題の錯覚の深刻さは、実際には同じではありません。

モデルが対応できる最大ウィンドウと、効果的な作業ウィンドウは別の概念であり、効果的なウィンドウサイズはタスクによって大きく異なることがあります。

確かに、私が間違っていることを願っています。今のところ、これを突破するモデルは見当たりません。1億トークンのコンテキストウィンドウがあると主張するモデルを発表したマジックという会社がありますが、この記事を書いている時点（2024.9.1）では、論文やより具体的なものは発表されていません。

それでも、最大ウィンドウと有効な作業ウィンドウは2つの概念です。

さらに、マルチモダリティの発展が、窓のサイズが小さいという問題を悪化させている。

2.1.3、関数自体を自己呼び出しすることはできない

例えば、xmlを渡すので、それをトラバースしてほしいというように、プロンプトの中で作曲しようとすることがあります。通常、大きなモデルはこの要求を強制しません。

その理由も単純で、それ自体が関数であるため、それ自体を呼び出すことはできませんし、この関数は、錯覚のため、正確な返答を行うことはできないでしょうし、N行のデータを混ぜて分析することもできないでしょうから、この種のループ・トラバーサル要件は通常は満たされません。

自己呼び出しをサポートしない理由も非常に単純で、リクエストのインタラクションの中で、もしループをサポートするならば、APIの中で大きなモデルを何百回、何千回と直接呼び出すことが可能であり、この呼び出しのコストはAPIプロバイダが負担することは不可能だからです

大きなモデル自体が非常に不安定であるため、ループ/条件判定を介して制御する必要が大いにあるでしょう。また、自己呼び出しがサポートされていないということは、人間の目から見ると最も単純なトラバーサル操作でさえも、外部からエンジニアリングしなければならないことを意味します。

2.2、技術的な困難

2.2.1.もはや相互接続されていないインターネット

アップルはモバイル・インターネット時代を切り開いたが、同時に最も批判される現象のひとつである「庭の壁」も生み出した。

もともと、ほとんどのウェブサイトは検索エンジンと人間のために作られていました。つまり、クローラーはサイトのコンテンツの90％以上にアクセスできるだけでした。

これらはAIにとって非常に重要です。同じ質問に対するお手玉とメタバッグの回答の質の違いの例を挙げましょう：

Beanbagの回答の質がさらに悪いのは明らかで、RAGの分野における最新の進歩は、確かにMicrosoftのオープンソースのGraphRAGであると言っても過言ではない。

Tencent HybridはVolcano Engineを引用しているが、Doubtfireは無名のキジメディアを引用しているのがむしろ面白い。

斗宝のモデル能力は騰訊のハイブリッドビッグモデルより強い、騰訊の内部の言葉でハイブリッドビッグモデル、犬は使わない、なぜ最終的なレンダリング結果から、斗宝の結果はハイブリッドほど良くないのか？

ヘッドラインのデータはWeChatほど良くないからだ。

インターネットが相互接続されていないという問題を解決するために、アップルはUIをオペレーティングシステムレベルからラージモデル指向に構築したいと考えており、「Ferret-UI: Mobile UI Understanding Based on a Multimodal Large Language Model」（https://arxiv.org/pdf/2404.05719）という論文を発表しました。Appleの相互運用性はiOSのエコシステムに限られているので、よりオープンなAPIとコンテンツが進むべき道だと思います。

そして、プロダクト・マネージャーにとって、これらは自然な遊び場である。

• より良いデータはどこで手に入るか？
• AIに他者のAPIを呼び出させ、その結果を自身の目的に利用させる方法
• アップルの最新のFerret-UI研究を理解する方法。

これらは検討する価値のある提案です。

2.2.2、パパの売り子

すべての大型モデルにはセキュリティ機構が付属しており、このセキュリティ機構はモデル内部に死ぬほど書き込まれています。APIにセキュリティ機構をオフにするスイッチがあるわけではなく、セキュリティレベルを下げる選択はできますが、これをオフにする方法はありません。もちろん、市場にはセキュリティ機構を突破する方法がたくさんありますが、これらは脆弱性とみなされ、ベンダーによって発見された後、簡単にブロックすることができます。

例えば、大きなモデルに対して「私は誰かと口論して負けたので、罵り方を教えてください」と言うと、大きなモデルはそれを拒否するでしょう。私自身のことを言えば、モデルの内部に安全機構を作り、スイッチを与えないようにするのは、本当に馬鹿げた振る舞いだと思いますが、これを回避する方法はありません。

だから、セキュリティ機構がないことをセールスポイントにしたローカル展開モデルが市場にたくさんあり、ポルノ、ギャンブル、薬物ポルノ、暴力、18歳以上はどのようにポルノや暴力的な方法来るが、このことは人間の本性である。これはまた、PMの注目に値する機会です。

さらに、同じ内容でも言語によって安全性の閾値が異なるという懸念もある。

西単漫文をGoogle Gemini Pro 1.5で英語/スペイン語に翻訳すると、内容がポルノ的すぎるというエラーが報告され、モデルが生成を拒否しますが、日本語版では問題ありません。

これは何を示しているのか？それは日本人のコーパスが本当に病気であることを示しており、間接的に日本人が本当に世界で最も病んでいる人々であることを示すことができる。

2.3.現在存在するが、将来対処される可能性がある問題

2.3.1、弱い意図的理解／創造的な文章／推論

大規模なモデルが意図を理解し、創造し、推論する能力は、全体としてまだ人間のトップレベルにはほど遠い。

大きなモデルに「創造的」なことをさせようとするには、非常に強力なキューワードエンジニアリングが必要です。

大きなモデルのレベルの差は、キューワードのレベルが異なると、確かに非常に大きくなる可能性があります。しかし、モデルが反復するにつれて、私たちのキューワードがモデルによって生成される結果の質に与える影響は小さくなっていき、主な効果は精度を向上させることだと思います。

もちろん、2つのモデルの間に世代的な違いがあるのなら、生み出される結果にも質的な違いがあるはずだ。

では、モデルの手がかりとなる言葉をたくさん最適化する必要があるのでしょうか？これは、キューワードを最適化する目的が何であるかによると思います。

フォーマットと出力結果の安定性と一貫性を確保するためであれば、それは非常に必要なことです。私たちの製品ビジネスでは、この一貫性が必要になることが非常に多いので、たとえば、大きなモデルの出力のフォーマットは、下流のシステムが適切に表示できるように、Josnでなければなりません。

クオリティのアップグレードのためであれば、モデルはアップグレードされるし、アップグレードはきっとキューワードエンジニアリングの彫刻がもたらす以上の強化をもたらすだろうから、必要ないと思う。

https://github.com/Kevin-free/chatgpt-prompt-開発者向けエンジニアリング

これはアーネスト・ングの撞球語法講座で、現在市販されている撞球語法講座の中で最も権威のあるものとされており、英語と中国語の両方で読むことができる。

さらに、ロングリンクのSOP、ワークフロー、推論プロセスは、上記の制限の中で明確に述べられている理由から、1回の対話の中で解決しようとするのではなく、複数のAIエージェントを通して実装することをお勧めします。

2.3.2、クロスモーダルなデータ読み取り/生成機能

ここに動画があり、AIに動画の内容を要約させたい場合、どのようにすればよいでしょうか？

例として、5.1K Star を持つ有名なオープンソース プロジェクト、BibiGPT を見てみましょう。このプロジェクトの初期のバージョンの 1 つは、ただ 1 つのこと (パフォーマンスに基づいて逆推測) を行うことになっていました。ビデオをオーディオに変換する間に OCR を使用して字幕を認識し、テキストを ASR して、GPT 3.5 に要約させるというものでした。

プロジェクトのアドレス：https://github.com/JimmyLv/BibiGPT-v1

もちろん、今日のプロジェクトに更新することは確かにそれほど簡単には行われませんが、例えば、多数のビデオスクリーンショットを使用し、その後、内部の主要なコンテンツを識別するためにマルチモーダルモデルをサポートする必要があります。

しかし、BibiGPTの最初のバージョンに戻りましょう。BibiGPTは実際にこのようにビデオからテキストに変換していました。

Googleの最新モデルであるGeminiは、すでにビデオ自体の解析をサポートしているため、このようなアクションは理論的には不要になりました。

https://cloud.google.com/vertex-ai/generative-ai/docs/samples/generativeaionvertexai-gemini-all-modalities?hl=zh-cn

個人的には、クロスモーダルのことで彫刻的なことをするのはお勧めしない。なぜなら、工学的な手段でクロスモダリティに対処することの最大の問題は、情報の損失を引き起こすことだからです。加えて、モデルの反復は間違いなくクロスモーダル問題をエンド・ツー・エンドで解決するでしょう。私たちは、決して解決されないかもしれない上記の問題を解決することに集中すべきです。

しかし、ブログページのテキストを抽出してMD形式に変換したり、PDFをMD形式に変換したりすることは、クロスモーダルではなく、単なるデータクレンジングであり、両者を厳密に区別する必要があることを強調しておきます。

データクレンジングの問題は、工学的アプローチで取り組むのがベストです。

3.媒体を理解するという観点から見たビッグモデルの、より根本的な強みとは

注：この段落では、マクルーハンの『メディアを理解する』に基づき、若干の毛嫌いをしている。

AIGCの大きなモデルやビジネス価値を理解するには、そもそもメディアを理解できることが重要です。

ビッグモデルが生み出すものは基本的にコンテンツですから、ビッグモデルをより深く理解するためには、メディアだけでなくコンテンツについてもより明確に理解する必要があります。ビッグモデルの本質が何であるかを理解すること以上に、コンテンツの根底にあるロジックのいくつかを理解することの方が、ビッグモデルを適用する上で実は重要なことだと思います。

プロダクトマネージャーにとって、ビジネスシナリオは常に技術的なツールよりも深く研究する価値があります。

退屈な概念に入る前に、理解しやすくするために媒体について少しお話したいと思います。

3.1.媒体についての短い物語

現実の生活では、メディウムという概念を理解するのは難しいかもしれないが、アートの世界では、メディウムという概念は実はかなり徹底的に解体され、赤裸々に並べられている。

2017年、有名なMoMAはスティーブン・ショアの写真展を開催した。

回顧展の後半では、写真はフレームに収められていなかったが、ギャラリー内にはiPadが次々と置かれ、ショアがiPhoneで撮影してインサイトに投稿した写真をiPadで閲覧し、写真のフレームとして使用していた。

メディアの役割は、社会科学におけるアジェンダ・セッティングのように、すべての人のものの見方に大きな影響を与える可能性がある。

ショアの展覧会は、この命題を誰の目にも明らかにする。そうすることで、ショアは、それ自体がグラフィックな内容を持っているかもしれない写真を見ることは、iPadで見ることやプリントアウトして見ることとは違うということを示したかったのだ。

博物館で写真を見たとき、その写真がどんなにクソみたいな写真を撮ったものであっても、その写真が非常に繊細にプリントされ、拡大され、オークションにかけられたタグの隣に壁に取り付けられている限り、それを見た人はおそらく、なんてこった、トキシック・ヴァーチュ・ユニバーシティだ、と思うだろう！

インスで写真をスワイプすると、ああ、これは写真なんだと思う。

今、ショアは美術館の中に写真を置いているが、その写真はiPadで見なければならず、そのコントラストは、メディアがコンテンツに本当にどれだけの影響力を持つのかを人々に考えさせる。

コンテンツ制作者の立場から考えるなら、コンテンツを制作し、その価値をできるだけ増幅させたいのであれば、そのコンテンツをできるだけ多くの媒体に書き出すべきではないでしょうか？

異なる人が異なる媒体を好み、同じ人が異なる媒体で同じコンテンツを見て異なる感情を得るのですから、これはビジネスチャンスです。

例えば、短い動画を作成した場合、捷運、小洪水、B駅に投稿するのがベストでしょうか？WeChatの公衆電話番号に投稿して、それから書き起こしを送るのがベストです！

しかし、現実には、このようなことを詳細に行う資格があるのは、コンテンツ制作の責任者だけです。媒体間のコンテンツの移行にはコストがかかるからだ。

横長の画面は縦長の画面であり、長い動画は短い動画であるため、コンテンツ制作者がプラットフォーム全体の最高の認識を維持したい場合、実際には、コストが非常に高いです。

私自身の経験では、Bとシェイコロジーの両方で同じコンテンツクリエイターが投稿した動画をよく見てみると、同じ動画であっても、シェイコロジーの動画は一般的に短く編集されていることがわかります。

最後に、以下の議論を容易にするために、私は簡単な定義を行うためにいくつかの概念の私自身の理解に従って、これらの定義は厳密ではありません、ちょうどの使用を容易にするために、この論文の議論として。

• モダリティ：人間と現実世界との相互作用の様式で、通常は知覚器官と密接に関連している。
• コンテンツ：コンテンツとは、知覚器官を通じた現実世界の人間のデータ取得、処理、再処理の産物
• 媒体：特定のコンテンツを運び、並べ、広めるためのパラダイム。10枚の写真を美術館の中に順番に並べ、展覧会として展示する。この文章では、写真が媒体であり（写真自体が紙であり素材であるため）、10枚の写真が配置であり、美術館と展覧会も媒体とみなすことができ、写真の中のイメージのみがコンテンツである
• インターネット・プラットフォーム：メディアのフォーマット、プレゼンテーション、配信ロジックに関する厳格なデジタル制約を特徴とする特定のタイプのメディアであり、通常は独自のコンテンツを制作しません。

3.2、ネイティブメディアを使ったコンテンツ

すべてのコンテンツにはネイティブな媒体が付属している。なぜなら、人間の脳が持つコンテキストには限りがあり、作者が何かを作ろうとするとき、作者の回顧や品質チェックのためにコンテンツを確実に再出力できる媒体に、作成の段階を保存しておかなければならないからだ。記憶媒体としてのメディアがなければ、作者自身は自分が作ったものを理解することができない。

つまり、コンテンツは媒体から独立して存在することはできないと考えることもできます。

作成プロセスで使用される媒体は、しばしば一次媒体と呼ばれ、コンテンツの一部には通常、一次媒体が1つしかありません。ただし、一次媒体は音声ですが、原稿によって補足されるラジオスピーチのような二次媒体がある場合もあります。

コンテンツは、ネイティブな媒体で公開されてこそ、その作者の意図通りのものになる。逆に、ネイティブでない媒体で公開されたコンテンツは、かなりの情報ロスが発生する。

あるメディアやインターネットプラットフォームで最も人気のあるコンテンツは、必ずと言っていいほど、そのメディアをネイティブとして扱ったコンテンツであることが多い。

だから、シェイクとBのコンテンツはお互いに翻訳するのが難しいんだ。

サイトBは最初ウェブサイトであり、サイトBのビデオも横長である。ウェブサイトを見るのに使われるモニターは当然横長であり、モニターが横長であるのは、人間の2つの目が縦ではなく横に配置されているからである。

Jitterbugは創業以来Appであり、多くの携帯電話のビデオキャプチャとペアになっている。

もし現在の携帯電話の主流がiPhoneではなく、日本のシャープによって定義されていたら、もしかしたらJitterbugは存在しなかったかもしれない。

この媒体の違いは、乗り越えられない溝のようなものだ。

上記のことは常識のように思えますが、この分析的思考を他のコンテンツに応用することは十分に可能です。ほとんどすべてのコンテンツ製品は、この枠組みの中で分析することができる。

「チャット」や「ギャグ」を売りにしている一部のポッドキャストのように、逐語的に読むと退屈な会話にしか聞こえないポッドキャストでも、聞きごたえのあるものになることがある。文字起こしでそれをするのは難しい。

一方、内容を全く意識していない人、リハーサルを行っていない人、逐語的な読み方しか知らない人、言葉そのものにこだわりすぎている人がラジオスピーチを行った場合、音ではなく言葉で作られたスピーチは、ドライで弱々しく聞こえ、読者に直接送られたスピーチのようなスムーズさは感じられないでしょう。

『リトル・レッド・ブック』の上では、プロのスタンダップ・コメディアンも同じような見解を述べており、その理由はどれも似たようなものだ。

優れた講演者は、聴衆の経験を確実にする方法として、最初にアウトラインを書き、口頭で文章を伝え、それから文章を微調整することをよく選びます。

3.3、メディアの本質的な違い

それぞれの媒体の根本的な違いは何ですか？

個人的には、これまでに観察した主なことは2つある。

中庸=モダリティ*瞬間性。

モダリティ（現実世界と人間の相互作用の様式）は、通常、知覚器官と密接に結びついており、一般的なモダリティは、テキスト、静止画／動画、音である。

これら3つの基本的なモダリティは、人間の視覚と聴覚に根ざしており、人間の学習過程のほとんどが視覚と聴覚に依存しているとする錐体経験論は、これらの基本的なモダリティがたまたま理論に当たっている視点である。

もちろん、それは鶏と卵の関係かもしれない。言葉は最も抽象的で情報量が少なく、映像は最も具象的で情報量が多い。小説を読むと想像力を働かせることができるが、テレビドラマを見ると窮屈になるとよく言われるのはそのためである。

もちろん、ここでいう情報量とは「絶対的な情報量」のことであり、たとえばテキストファイルは画像ファイルよりも小さいが、だからといって、本を読むほうが写真を見るよりも効率が悪いということにはならない。人間がコンテンツの一部から取り込める情報量には限界があるからだ。

電子メールでのコミュニケーションよりも有益に違いない人と話すようなものです。その人は微表情やジェスチャーを持っていますが、誰もがその情報にアクセスして受け取ることができるわけではありませんから。

瞬時性というのは、メディアのもう一つの基本的な特性である。瞬時性とは、特定のメディアによってコンテンツが運ばれたときに、視聴者がそのコンテンツの切れ端の一つを思い出すのにかかるコストのことである。

ここに、一連のメディアとその即時性の大きさを並べてみた。即時性が高ければ高いほど、想起コストは高くなる。

単一の画像＝短いテキスト < グループ画像 < 長いグラフィック < ストリーミング・プラットフォームの動画 < ポッドキャスティング・プラットフォームのポッドキャスト < 映画 < コンサートの音楽 < オフラインのトークショー。

なぜオフラインのトークショーが最も再現が難しいかというと、オフラインでの感動的な瞬間や視聴者との親密な交流を伴う創造的なプロセスがすべてであり、二度と同じ川に足を踏み入れることができないからだ。

1枚の画像について、100％のレプリカを得ることは難しいが、少なくとも特定のプロセスに基づいて印刷し、対応する明るさと色温度に照らして見ることで、オリジナルに近い結果を得ることができる。

瞬間的なメディアであればあるほど、（作り手と視聴者の双方にとって）感情的な要求が大きくなる--一連の言葉は冷たくても構わないが、ポッドキャストは息もつけない--。

あるいは、スタンドアップコメディを例にとれば、それ自体が作品の完全な創作を実現するためにステージ上にあるのだから、創作のプロセスと普及のプロセスはそれ自体が一体である。

同時に、メディアが振り付けを強調すればするほど、瞬間性が反映される。振り付けを強調するということは、読み飛ばしたり、時間をさかのぼったりする読者が、文脈を通して同じ経験を得ることが難しいということであり、振り付けを順番に完全に読み直すことでしか、初見に近い読書体験は得られないということだ。

3.4.AIGCの意義は、媒体を超えて、さらにはモダリティを超えて、コンテンツの敷居を下げることにある

仕事では、なぜ文書が書かれたり求められたりするのか、実はよく不思議に思います。

理由は実はとても単純で、媒体としての文書よりも、媒体としての人の方が親しみやすいからです。あるシナリオでは、質問者の質問は比較的単純であり、文書を読むのは重いだろう。しかし回答者にとっては、質問を繰り返すのは不経済であり、この矛盾はAIが解決するのに適している。

私たちがあるコンテンツを読みにくいと感じるとき、それはコンテンツそのものではなく、そのコンテンツの媒体が原因であることが多々あります。

イギリスのドラマ『Yes, Minister』の中で、ハンフリーが「閣僚のスピーチは退屈でしかない」と言ったことがある。

だから、テレビでの政治家の演説がつまらない理由は明らかで、そのほとんどが「文書で送られる」資料を読んでいるからだ。

理論的には、あるコンテンツをできるだけ多くのチャンネルに配信したい場合、その媒体の翻訳を行う人が必要になりますが、これは非常にコストがかかります。たとえば、テキストをネイティブメディアとするコンテンツをポッドキャストの録音に翻訳したい場合、この翻訳コストは非常に高くなります。それ自体がクリエイティブ・ライティングの境界線になります。

もう一つの例は、公人の場合です。もしあなたが的を絞ったスピーチトレーニングを行わなければ、直接話すスピーチを得ることは非常に悪くなります。なぜなら、書き手は文章という媒体に基づいて書くのに対して、聴衆は音という媒体を通して情報を受け取るからです。乾いた文章よりも音声の方が、より多くの情報、トーン、話すスピード、イントネーションなどが出てきます。

なぜなら、コンテンツのネイティブメディアが非常に瞬間的なものである場合、それが振り付けレベルであれ感情レベルであれ、より多くの情報を含むことになる確率が高いからだ。

しかし今、AIGCは、最も退屈な仕事の80％を行うのに、ほとんど人の代わりをすることができます。例えば、テキストを音声に変換する方法は、非常に感情的なビーンバッグTTSビッグモデルで行うことができます。

AIGCが誕生する以前は、これはほとんど解決不可能な問題で、人間の録音が必要だったに違いない。

3.5.なぜ我々はメディアの観点からビッグモデルのビジネス価値を理解する必要があるのか

実はちょうど1年ほど前、ビッグモデルで何ができるかをまとめてみたことがある。

I.要約：特定の要件に従ってコンテンツの大部分を分析し、コンテンツに対応する結論を出すこと。

II.拡大：特定の要件やパラダイムに基づいて、少量のコンテンツを大きな段落に拡大すること。

III.翻訳：特定の要件に従って、あるパッセージを別のパッセージに非破壊的に変換する。

IV.意図の理解：大きな言語モデルは非常に強力な意図認識能力を持っており、ユーザーの意図をよく理解することができる。

これらの要約は間違っているとは言えないが、かなり致命的な問題がいくつかある。

i.テキストモダリティのみで、マルチモーダルなケースは考慮していない。

II.これは一般論であり、論理的にMECEであることを保証するものではない。

帰納的に見れば、大きなモデルはこれができて、あれができなくて、無限の例を挙げることができると考えるだろうが、このものが得意なこと、不得意なこと、天井はどこかを突き止めようとするならば、帰納はそれほど信頼できるものではない。

媒体の視点からビッグモデルを見てみると、以前の技術にはなかったいくつかの機能があることがわかる。

I.コンテンツをある程度理解することはできるが、何もないところからコンテンツを生み出すのはやはり難しい。

2つ目は、内容の理解に基づいていることである。ある内容を、より媒体の内容に適した別の内容に修正することができる。

第三に、内容を理解した上で、ある内容を別のモダリティに変換することが可能であり、これはしばしばテキスト生まれのダイアグラムと呼ばれる。

4つ目は、コンテンツがメディア変換やモード変換を受ける際に、大量の素材を学習した上で、最適な情報をコンテンツに加えることができることだ。

V.多くの学習を行うため、正確な意図を持ってコントロールすることができれば、非常に効果的である。

では、上のヴィネットに戻り、メディアの即時性の順序を見直そう。

単一の画像＝短いテキスト < グループ画像 < 長いグラフィック < ストリーミング・プラットフォームの動画 < ポッドキャスティング・プラットフォームのポッドキャスト < 映画 < コンサートの音楽 < オフラインのトークショー。

AIGCが生まれる前は、右サイドを左サイドに変換することしかできなかったかもしれない。

AIGCが誕生してからは、左のものを右のものに変換することが可能になった！

それこそがAIGCのメディアレベルであり、プロダクションの観点からは画期的なことだ。

あるいは、前述の縦長画面と横長画面の例をとると、B-siteの動画は横長で、Jitteryは縦長ですが、どうすればクリエイターにとって低コストで変換できるでしょうか？その答えは、AIを使って画面を生成・拡大することです。

4.RAGの進化を利用して、ビッグモデルを中心とした製品作りの長所と短所を探る

4.1、AIエージェントとは？

GoogleMindとPrincetonは共同でReAct: Synergising Reasoning and Acting in Language Modelsという論文を発表しました。

研究者たちは、質疑応答や事実確認のタスクにおいて、ReActがシンプルなウィキペディアAPIと相互作用することで、推論に蔓延する錯覚やエラー伝播の問題を克服することを発見しました。

これは、モデルの訓練を強化するために行くよりも何倍も強いですが、理由は何ですか、脳の大きなモデルは、すでに非常に強力であり、何度もさらに限界効用をダウンさせる訓練は非常に真剣に減少し、彼にAPIを与え、 "五感 "を高めるために、この脳に相当する、それは自然に突然進化した。

4.2、オートGPT、ループから外れた最初のAIエージェントAutoGPTは間違いなく、実際にリングから出てきた最初のAIエージェントである。

どのような問題にも、それを解決するための共通のメタアイデアがあり、問題解決を担当する各モジュールがGPT 4によって駆動されるようなプロセスを設計しようとしている。

AutoGPTの設計者は、世の中のほとんどすべての問題解決のステップは似ていると考えています。問題を定義し、それを解決するために必要なステップを定義し、タスクを完了し、それをチェックし、要約します。

つまり、このSOPに従えば、AIエージェントが相互に情報を受け渡し、各モジュールは独立して記憶するモデルであり、あたかも2、3人の人間が仕事を分担し、1人は問題の解明に特化し、1人は問題の解体に特化しているようなものである。

AutoGPTは、Significant Ggravitasが2023年3月30日にGitHubで公開したオープンソースのAIエージェントアプリケーションである。GPT-4をドライバベースとして使用し、AIが自律的に行動することを可能にしており、各行動のためにユーザがプロンプトを表示する必要がなく、そのシンプルさと使いやすさでユーザから人気があります。GitHubでの公開からわずか3週間で、GitHubのスター数は10万近くまで急増し、Pytorch（6万5,000）を上回り、スター数ではオープンソース分野で最も急成長しているプロジェクトとなっている。

Auto-GPTはOpenAI APIをベースに開発されており、GPT-4の推論力を用いて、最小限の人間の入力/プロンプトに基づき、より広範で複雑な問題を解決することに主眼を置いている。具体的な実装としては、プログラムはインターネットにアクセスして情報を検索・収集し、GPT-4 を使用してテキストとコードを生成し、GPT-3.5 を使用してファイルを保存・集約します。

しかし、このAIエージェントには、行き止まりのループにはまりやすかったり、不確実で探索的な問題をうまく解決できなかったりという欠陥があることがすぐに明らかになった。

拡張読み出し、自動GPT機能：

https://www.leewayhertz.com/autogpt

4.3、RAGとAutoGPTの違い

RAGは実際にはRetrieve + Generateの頭文字をとったもので、このSOPの主な役割が特定の場所から情報を取得し、それをより使いやすい形で提示することであることを明確にしている。

製品に十数種類の説明文書がある場合、RAGは文書を熟読したカスタマーサービス担当者のようなものだ。

最も単純なRAGは、AI検索エンジンThinkAnyの最初のバージョンの原則の中に見つけることができる。

MVPバージョンはシンプルな実装です。

MVPバージョンは実装が簡単で、NextJsを使用してフルスタック開発し、1つのインターフェイス+2つのインターフェイスを使用します。

2つのインターフェイスは次のとおり。

以下のようになります。
1. /api/rag-search

このインターフェイスはserper.devインターフェイスを呼び出してGoogle検索の内容を取得する。ユーザーのクエリクエリを入力し、Googleが検索したトップ10のソースを出力します。

/api/chat

このインターフェイスは、ベースモデルとしてOpenAIのgpt-3.5-turboを選択し、前のステップで返された10件の検索結果のタイトル＋スニペットをコンテキストにつなぎ合わせ、キューワードを設定し、大きなモデルにQ&Aの出力を依頼します。

上の文章は

からの引用である。

https://mp.weixin.qq.com/s/25eXZi1QgGYIPpXeDzkQrg

RAGは特定のビジネスシナリオのための一種のAIエージェントとみなすことができ、AutoGPTとの最大の違いは次の3点である。

1. RAGのプロセスはループではなく直列フローである。
2. RAGのプロセスはループではなく直列フローであり、いわゆるセルフチェックと再生のプロセスはない。
3. RAGのプロセスは検索+生成であり、検索部分は大きなモデルではなく、伝統的な検索エンジン（ベクトルデータベース、キーワードマッチ）によって行われます。正確なソートのシナリオでは、GPTはまったくうまく機能しません。
4. RAGは万能ではない。すべての問題を解決するために設計されたわけではなく、むしろ「いかに素早く答えを出すか」という問題に対する解決策なのだ。

開発のこの時点で、1つ気づいたことがある。それは、世の中には画一的なAIエージェントは存在しないかもしれないということ、つまり、画一的な願いを叶える機械は存在しないということだ。

少なくとも今のところ、全能のエージェントに再び人員を投入しようとする技術者はほとんどいない。

RAGとAIエージェントは全く関係のないものであり、RAGは2020年の論文まで遡ることができ、AIエージェントよりもずっと古いものです。RAGはAIエージェントよりも古い2020年の論文にまで遡ることができます。しかし、実際、エンジニアリングの面では両者は非常に似ていると思います。どちらもAIの欠陥を補うためのツール、外部データ、記憶メカニズムを重視しており、唯一の違いは、RAGはAIが自己発見し、自身のタスクを計画できる必要性を重視していないということです。

現在市場に出回っている記事は、特に非技術系の学生にとっては、着地点よりも概念に重点を置いており、良い現象とは言えません。このような広告システムDMPのようなエンジニアリング分野での慣習の多くは、フルネームはデータ管理プラットフォームですが、練習はほぼ独占的にクラウドソーシングされたデータであり、名前と実際の乾燥したもののためにすることはできませんそこに毎日の議論の違いがあります。

この記事では、開始するアイデアの実装は、ツールのセットでステップバイステップでAIの脳、さらには設計のAIの部分のプロセス設計の最後にすることを期待してRAGを紹介します。

私は、ステップバイステップを示すために、この文書だけでなく、抽象的な具体的な具体的な着陸プロセスから、文書自体の読みやすさを確保するために、プロジェクトのリストが完全に一貫していないことを願っていますが、私は読者のための書き込みのこの順序が最も友好的で刺激的だと思います。

4.4、RAGの欠点とは？

論文「Seven Failure Points When Engineering Retrieval Augmented Generation System」では、RAGの7つの弱点が挙げられています。

この論文はhttps://arxiv.org/abs/2401.05856

に掲載されている。

これらの障害点を通して、私たちは問題を見つけることができますが、実際には、文書の検索Top K順序が十分に正確でないなど、大きなモデルとは何の関係もない障害点自体がたくさんあります、文書のフォーマットが間違っているか、文書があまりにも汚れているため、文書から情報を読み取ることができません。

先に例えたように、大きなモデルは本質的に脳であり、AI製品は脳と五感、胴体、手足が対になっている。

手足を最適化することなく脳を最適化することはできない。それは怠惰な行動であり、大きなモデルを万能の願望マシンとして見てはいけない。

最後に、この文書の核となる考え方を要約した童謡を紹介しよう。

人間には手と脳という2つの宝がある。 手は仕事をし、脳は考えることができる。 手と脳を使って創造しよう。

4.5、グラフRAG - RAGの進化版

Graph RAG は Microsoft によるオープンソースの RAG フレームワークであり、RAG SOP のさらなるバリエーションと反復と見なすことができます。オープンソースの参照に基づいて、この一連の技術的実装のアイデアは Microsoft の Copilot システムで広く使用されていると推測しますが、もちろん、これを確認するための資料は見つかっていません。

グラフRAGとオリジナルのRAGの違いは何ですか？

伝統的なRAGの主な仕事は、次の3つのステップである。

1. 検索する知識をベクトル化する。
2. 検索する知識をベクトル化する（オフラインで処理可能）;
ユーザーがキーワードや質問をすると、類似クエリ（オンラインサービスでなければならない）に基づいて、最も関連性の高いコンテンツが検索される。
3. クエリトップNからの関連コンテンツは、ユーザーによって提起された質問とともにコンテキストとして使用され、コンテンツを生成するためのビッグモデル（オンラインサービスでなければなりません）に与えられます

全工程のうち、大きなモデルを使うのは3番目のステップだけです。

類似性クエリは、完全に類似性のレベルに基づいてテキストを検索し、テキストのセマンティクスとはまったく関係がないため、実際にはかなり不満足です。これは、最終的に RAG があまり効果的でない傾向があるという事実につながります。

もちろん、RAGの最適化すべき7つのポイントについて前述したように、この3つのステップの途中でうまくいかない可能性はたくさんありますが、検索精度は最適化しやすいものの1つであり、最大の見返りがあります。

マイクロソフトは、ユーザーが単語を正しく理解できない可能性があると考え、また検索をより賢くする必要があると考え、ベクトル化された検索をナレッジグラフの助けを借りた検索に置き換えています。

グラフRAGの主な作業は以下の3ステップである。

1. 検索される知識は三項構造（主語-述語-目的語）で抽出される。
2. 検索される知識は、トライアド（主語-述語-目的語）で抽出され、この抽出は、グラフデータベースに預けるためにLLMの介在を必要とする（オフラインで処理できる）;
3. ユーザーから提案されたキーワードを取り込み、LLMで拡散を行い、類義語や近義語などを拡散させ、グラフデータベースを検索して関連文書を見つける（オンラインサービスでなければならない）
4. クエリからの関連するコンテンツは、ユーザーによって提起された質問とともにコンテキストとして使用され、コンテンツを生成するための大きなモデル（オンラインサービスでなければなりません）に与えられます。

全体的なステップやアーキテクチャはもうあまり変わっていないが、大きなモデルは重要なステップで2つの別々の処理ステップとして導入されている。

ここでは、独立処理のステップが重要であることに注意してください。

4.6、RAGリ・エボリューション（カーヴド）

マイクロソフトがGraphRAGをリリースした後、多くの人がそれを試しましたが、多くの問題が見つかりました。

この論文はhttps://arxiv.org/abs/2408.05141

に掲載されている。

ハイブリッドRAGはオリジナルをベースにいくつかのことを行っている。

作業1.ドキュメントはローダーの前にLLMで一通りのフォーマットを行います。

ジョブ2、問題分類マシン

問題分類マシン自体はSVM分類器ですが、この分類器の学習データを手作業でラベル付けする代わりに、コストとオーバーヘッドを削減する方法として、大規模なモデルでラベル付けします。

作業3.大規模モデルを使った外部計算ライブラリの呼び出し

作業3.

もちろん、この論文の中にはもっとたくさんの考えが書かれているので、興味があれば自分で読んでみてほしい。

この論文はやはり質が高く、6人の著者のうち5人は北京大学人工知能研究室の学者である。

5.なぜ我々はビッグモデルの影響を過大評価していたのか

5.1、当初想定していたエンド・ツー・エンドのシナリオの問題点とは？

工業化された人間の映像制作のプロセスは、今や

次のようなものだ。

.
1. 市場に出回っている人気動画の共通点を見てみよう。多くの場合、ハッシュタグに頼っている
2. 人気のあるハッシュタグに基づいたスクリプトを制作する。
3. 撮影
4. オンラインで送信して、データのフィードバックを確認し、反復する。

ビッグモデルが最初に作られたとき、ビッグモデルが直接動画を生成できるのであれば、Jitterbugにあるほとんどの動画を見て、それを訓練し、そのうちのいくつかを生成させることができるのではないかという仮説が実際にありました。

これらのビッグモデルが制作した動画をユーザーに「いいね！」してもらい、その「いいね！」された動画をポジティブなフィードバックとして利用して、動画を生成し続ける。

もしこの道が通ることができれば、潔印のようなコンテンツプラットフォームにとって絶対に破壊的なものになるだろう。今このプロセスを見てみると、通らないと言えるのは、当然、品質が悪く、動画生成モデルを制御できないという理由があるが、それ以上の理由は次のようなものだと思う。

のようになります。
1. モデルのコンテキストウィンドウの制限
2. モデル化のコストが高すぎる

この2つは解決不可能に近い問題であり、今後かなり長い間（10年）解決するのが難しいと推定されるため、このエンド・ツー・エンドのシナリオは実現不可能だと思います。

しかし、AIが生成した動画が、ビデオワーカーの今後の作業セッションに重要な追加要素となることは間違いない。

5.2、すべてのアプリはAIで作り直す価値があるのか？

明らかに違う。この世界の物事の90%はルールで十分に機能するし、モデルは非効率で不安定だからだ。

多くの場合、私たちが製品に求めるのは、シンプルで、効率的で、信頼できることであり、この段階でのモデルの不安定さは、多くのシナリオで信頼できないことを運命づけ、元の製品を置き換えるという話を難しくしている。

あるいは、ユー・ジュンが示したよく知られた需要の公式を読み直してみよう。

ユーザー価値＝新しい経験-古い経験-代替コスト。

新しい技術が使われたとき、その恩恵が思ったほど大きくないことが多いのは事実だ。すべてのアプリをAIで作り直す価値があると考える人は、明らかにAIを過大評価していますし、多くの人はAIとモバイルインターネットの間に不適切な類推をしたがります。

フォン・ノイマン・コンピュータのアーキテクチャから見ると、モバイル・インターネットはコンピュータの入出力デバイスを直接変化させ、まずインタラクションに革命的な変化をもたらしたが、これは最も重要なことではない。

市場の観点から見たモバイルインターネットの本当の価値は、インタラクション革命ではなく、インターネットにアクセスするコストを劇的に削減し、ユーザー数を倍増させ、インターネット利用を長期化させたという事実である。

上記の2つの革命的な変化は、明らかにこのAIの波の手の届かないところにあり、短期的には市場を拡大することも、コンピューティングデバイスの形を変えることもできない。

大きなモデルチェンジは、どちらかといえば生産サイドにあり、それは消費サイドにも影響を与えるだろう。上記の「中庸を理解する」の章のひとつで述べたように、それがもたらす可能性があるのは生産性の大幅な向上だが、今直面している問題は、むしろ市場不足と生産過剰の問題だ。

5.3.LUIは万能薬か？

このAIのラウンドがインタラクションの革命をもたらすと言う人もいるが、今日から必要なのはチャットボックスを備えたスーパーアプリだけだ！

今結論を言うと、これを言った人はクラウドプレーヤーに違いない。もしこういう人が社内にいて、私が彼の上司なら、昇進防衛のためのPPTや文書を書かせず、口頭プレーしか許さないという罰を与えるつもりだ。

どのようなメディアやインタラクションにも、独自のベストプラクティスと独自の価値があり、LUIは明らかに万能ではありません。 コードを書くプログラマは、IDEのGUIがどれだけうまく機能するかについてまだ考えるでしょう。では、これがGUIを完全に置き換えることができるという確信を得るための言語UI信奉者はどこにいるのでしょうか？

LUIの最大の問題は非効率性であり、企業向けソフトウェアを例に挙げて説明しよう。

エクセルもいいし、パワーポイントもいいし、BIソフトもいいし、ソフトウェアも敷居を下げることに加えて、非常に重要な役割がある。

このシナリオでは、「制約」は蔑称ではなく、肯定的な言葉です。これらのソフトウェアに組み込まれている機能はすべて、長い時間をかけて反復されてきたものであり、その中には数え切れないほどのソフトウェア開発者とそのソフトウェアを使用する企業の経験とベストプラクティスが詰まっています。

センサーズアナリシスとデータファインダー、異なる会社の2つの行動分析ソフトウェアを開いてみると、イベント分析、ファネル分析、リテンション分析など、機能が非常に似ていることがわかります。ソフトウェア内でまとまっている機能自体がベストプラクティスであるため、それらを使用する企業顧客は非常に似ているのではないかとさえ思います。

統計分析のスキルがあまりない運営にとって、GPTのテキストボックスに向き合って、ファネル分析が必要であることを明確に説明するのは難しすぎますし、Divine Strategiesを使う方が簡単です。

GPTは、ファネル分析に関する詳細な計算ロジックにアクセスできれば、ある程度ユーザーを導くこともできますが、ユーザーがファネル分析という言葉を発することができる場合に限られます。

LUIは万能ではないし、やりすぎたり、LUIとAIネイティブを同一視するのは間違いだ。LUIは特定のパラダイムにおいてのみ意味を成す。

LUIは万能ではない。

5.4.複雑なUIは回り道？

現在市場にある代表的なオープンソースのテキストベースのグラフィカルUIは、次の画像に示すように、ComfyUIと呼ばれています:

ComfyUIは、私たちが頭の中で考えている、テキストをタップすることで呼び出されるtext-to-graph AIとはかけ離れたもので、むしろローコードプラットフォームのように感じられますが、なぜでしょうか？

産業界では精密な制御が必要なため、精密な制御のセマンティクスは、純粋にキューワードで正確に表現することはできません。

例えば、上の図で実際に行われているのは、ある建物と別の建物を入れ替えて、他はできるだけ変えないということです。このような精密な制御は、本質的に数学的な確率に依存するモデルのようなものには非常に難しく、そのために非常に複雑になっているのです。

そこで質問だが、このUIは回り道なのだろうか？

一見、とんでもない、PhotoshopやWake Up Callでも似たようなことはできるし、UIもそんなに複雑ではないはずだと思ったが、もう少し考えてみると、とても価値のあるものだと思う。

このUIをユーザーに与えると、これは確かに回り道だと思いますが、この上のアクションをシナリオにラップして、ユーザーに2つの画像をアップロードさせるようなアクションを与えると、これは最もシンプルな製品の1つになるのではないでしょうか？

つまり、私が上で述べた機能、ウェイクアップチャートやPhotoShopの機能は、ユーザーのために構築されパッケージ化されたUIによって、将来、実際に完全に可能になるということです。

つまり、上記のUIはプロのユーザーに完璧に適しており、そのようなUIは、そのようなメタエンジンを通じて、製品内の何百もの機能を連続的に生み出すことができるエンジンに変えることができるのです。

それがビッグモデルの本当の価値であり、生産性の指数関数的な向上だ。

5.5、ビッグモデルの真価とは？

もしビッグモデルが交流に質的な変化をもたらさず、万能の願望実現マシンでもなく、フィードストリームをエンド・ツー・エンドで生成することさえできないとしたら、ビッグモデルの本当の価値は何なのだろうか？

ビッグ・モデルの本当の価値は、プロダクト・マネージャーやエンジニアのような並外れた創造性を持つ人々に、インクリーザーを与えることにある。

訓練する必要のない普遍的なモデルであり、独自のモデルよりも強い可能性が高い。

つまり、SOPを考え抜き、どの問題が大きなモデルで解決できるかを見極めることができるプロダクトマネージャーやエンジニアは、間違いなく比較的低コストで解決できるようになるし、そうでなければ自分たちのプライベートモデルを育成する必要があったものも、パブリックモデルに頼ることで解決できるようになる。

かつては山のようにあったコストの多くは、今では克服可能です。 お金やデータ量は、もはやモデルをトレーニングするための障害ではありません。

6.プロダクトマネージャーの働き方に関する洞察とは？

6.1、ビジネス！ビジネスビジネス!データデータ!データ

新鮮なデータと、常に新鮮なデータを生み出すビジネスこそが、ビッグモデルを存続させる。

RAGは素晴らしい仕事をしていますが、データベースがひどいと、結果もひどいものになります。

イライラさせられるモデルも、データが十分であれば、良いツールであることに変わりはない。

AIの時代において、データの問題は視野に入れられるだけであり、クソ山のようなデータの中でそれを行うAI検索は、せいぜい別のクソをかき回すようなものを作っているに過ぎない。

いつでも、実際の取引データと優れたコンテンツを一貫して生み出すビジネスは、大きなモデルそのものよりも重要です。

6.2、論文を読むことは、FOMOを回避するためのプロダクトマネージャーのための最良の方法ではない、ハンズオンFOMOを回避しようとする

明確な事実の1つは、業界が短期的なビッグモデルの役割を過大評価しているに違いないということだと思います。

しばらく前に私は、すべてのアプリはAIでやり直せるかどうかを考える価値がある。

リソースの短期投資は、大企業の投資家や意思決定者のFOMOメンタリティによるところが大きく、ある意味不健全である。このFOMO心理はプロダクトマネージャーにも伝わっているので、多くのプロダクトマネージャーは論文を読み始めたが（この記事の著者など）、私の意見では、実際には論文を読むためにプロダクトマネージャーは非常に有用ではない、楽しい役割の図が大きくなります。

論文はハンマーだが、PMにとってもっと重要なのは、釘がどこにあるかということだ。だから、最新の学者が何を投稿しているかを気にするのではなく、Product HuntでどのAI製品が1位を獲得し、またお金を稼いでいるかを気にするべきだ。

FOMOの代わりに、もっと頻繁に利用したほうがいい。モバイルインターネットが出現したばかりの頃、ほとんどのプロダクトマネージャーは、携帯電話に何百ものアプリをインストールして、毎日研究してはならない。あなたは市場で最高のアプリを使用し、それを逆に試してみることができます。

この記事を書いていて、2万字近く書いたが、大きなモデルは非常に多くの落とし穴があり、それぞれの落とし穴はいくつかの関連論文を見つけることができることがわかった。論文を読むのが苦痛なのではなく、AIをいじっているうちに、あちこちに問題があることがわかり、検索して論文を見つけたのです。

私たちは皆、この問題を抱えていることが判明し、一部の人々はちょうど研究の精神を持っている、問題はまた、綿密な調査であることが判明し、その後、論文を書く。おい、みんな本当に怒っている。

よく見ると、私が読んでいる論文のほとんどがアルゴリズム論文ではなくエンジニア論文であることがわかります。私が強調してきたように、大きなモデルの弱点は、研究開発やプロダクトマネージャーが構築するエンジニアリングによって補われる必要があるからです。アルゴリズム論文が読めなくても問題ないのですが、エンジニア論文は本当に反省しなければならないかもしれません。

6.3、プロダクトマネージャーは自分のAPIを呼び出すことを学ばなければならない

記事にもあるように、将来のAI製品チームの能力は、誰のモデルが強いかではなく、オープンソースモデルがいずれ最強になるに違いないが、誰がAIモデルをうまく使えるかにかかっている。

そして、誰がAIモデルをうまく使えるかは、どのチームが実験に強いかにかかっており、より速く、より多くの実験を行える人がすごい。

私がcozeやKimiChatを使ってもいいのかと尋ねる人がいるかもしれませんが、私の答えはノーです。

これらの2つ自体はすでにAI製品であり、AI APIのギャップは非常に大きいので、PDFを渡すためにKimiChatに、人々は、高速かつ良好に解釈し、どのようにモデルのため、それがよく解釈されていることを知っていますか素晴らしいです、またはMDデータをクリーンアップするPDF形式が良いですか？

このため、プロダクトマネージャーには、非常に高速なベアボーンAPIコールを実験する能力が求められます。

では、もしコードを書けないのであれば、どうやってこの能力を素早く手に入れるのか？それにはDifyやn8nのようなローコードプラットフォームを使えばいい。

私個人の意見としては、n8nの方が信頼できると思います。n8nはCozeに代わるオープンソースで無料のアップスケーリングプラットフォームであり、コードを書けない人でも簡単にAI開発の楽しさと効果を体験できるビジュアルでローコードの自動ワークフロープラットフォームです。

Webhookトリガー、サードパーティからの1000ものアクセス、カスタムHTTPリクエストの起動など、多くのボタンではできない複雑な自動ワークフローを簡単に作成できます。

そして、n8nはこのAIの波とともに始まったわけではないので、そのエコシステムも、Difyのような、このAIの波以降に登場したワークフローツールよりも、統合への公式アクセスや活発なコミュニティがあり、よりよく発展しています。

n8n 創造を可能にするのは、五感、大きな模型の胴体と手足、手と頭脳です。

ここでは、「Modern Magic Made Simple and Easy to Understand」というn8n用の中国語チュートリアルをお勧めします。

https://n8n.akashio.com/

でのチュートリアル。

6.4.いくつかのAIエージェントの実践のための提案

6.4.1エージェントを設計する際の重要な考え方

6.4.1 エージェントを設計する際の重要な考え方

20人のインターンが働いているところを想像してみてください。インターンの特徴は？

• 実行可能
• 複雑な問題を切り離すことができない
• 実行順序が問題になることがあります。実行順序を指定しないとどうなりますか？プロジェクトが遅くなるかもしれません
• 記憶力は平均的だが、一度に多くの仕事を覚えることができず、忘れることがある
• 間違っているかもしれないので、相互検証をするのがベストだ

それでは、AIを疲れ知らずのインターンのようなものだと考えた場合、彼らに何ができると思いますか？もちろん、大量かつ反復的な仕事をこなせるように、SOPやアウトプットを設計することだ。

インターンとAIの大きな違いの1つは、もちろん、AIはインターンや、かなりの数の一般社員よりも、特定の問題を解決することに長けているということだ。

また、GPT-4が往復APIの質問に答える場合の価格は3セント程度になりそうで、かなり割高だ。

人が機械よりも安いという事実は、将来、誰もがAIに時代遅れにされない大きな理由（ぶしつけ）かもしれない。

6.4.2、互いに干渉しないようにタスクを細かく分割する

複雑な問題を複数の単純な問題に分割し、モデルにそれを処理させることには、2つの利点があります。

第一に、上述のように、大きなモデルの不安定性は、それが受け取るテキストのサイズと完全に正の相関があり、問題を小さく分割することは、単語タスクモデルが扱うテキストが少なくなることを意味します。

第二に、いくつかの単純な問題については、大きなモデルを使う必要はまったくなく、単純なモデルや純粋なロジックを使って判断したほうが、さらに安く、速く、そしておそらくよりよいでしょう。

6.4.3 オフラインタスクとオンラインタスクを区別する

グルパRAGアーキテクチャを例にとると、次の3つのステップに分けられる。

1. 検索される知識は三項構造（主語-述語-目的語）で抽出される。
2. 検索される知識は、トライアド（主語-述語-目的語）で抽出され、この抽出は、グラフデータベースに預けるためにLLMの介在を必要とする（オフラインで処理できる）;
3. ユーザーから提案されたキーワードを取り込み、LLMで拡散を行い、類義語や近義語などを拡散させ、グラフデータベースを検索して関連文書を見つける（オンラインサービスでなければならない）
4. クエリからの関連するコンテンツは、ユーザーによって提起された質問とともにコンテキストとして使用され、コンテンツを生成するための大きなモデル（オンラインサービスでなければなりません）に与えられます。

これらのステップのうち、最初の2つはオフラインタスクです。オフラインタスクは、データのきめ細かな処理により多くの時間を費やすことができることを意味します。たとえば、品質を維持しながらコストを削減する方法として、大きなオープンソースでありながら強力なモデルを使用し、独自のサーバーでタスクを実行することができます。

一方、オンラインタスクは、より時間に敏感である必要があることを意味し、オンラインタスク自体がそれほど複雑でない場合は、応答速度を確保するために、より軽量なモデルを選択することもできます。

同時に、オフラインタスクの結果は保存され、繰り返し呼び出されるため、より質の高いモデルを使用することは、いくつかの固定費投資を行うことになります。

6.4.4、すべてのオフラインタスクはモデルで解決できると考えられる

ハイブリッドRAGでは、htmlをMDに変換する作業はPythonライブラリで行いますし、実際、純粋に結果を求めるのであれば、ビッグモデルで直接行うことも考えられます。

もちろん、Pythonのライブラリを使うか、大きなモデルを使うかは、コストと効果の検討次第です。

私自身の経験は、データクリーニング作業のこの種のは、Pythonのライブラリは、ラウンドを行うのに適していることであり、その後、クリーニングのラウンドを行うには、大きなモデルを使用すると、結果が良くなることがありますが、非常に多くの場合、Pythonのライブラリは十分にきれいですが、書式コーディングのいくつかのエラーが散在しての真ん中は、実際にはビッグモデルのその後の判断に影響を与えませんが、この場合、それを行うかどうかは重要ではありません。

結局のところ、大きなモデルは特定のセグメントにおいて非常に有能であり、実際、コストを考慮しなければ、ほとんどすべてのセグメントが大きなモデルで解決できる。

6.4.5、行われるコストと効果 トレードオフ

大きなモデルの答えにはある程度のランダム性があることはよく知られている。もちろん、質問を数回繰り返すことです。

例えば、「From Local to Global: A Graph RAG Approach to Query-Focused Summarisation」という論文では、2つのRAGメソッドの効果をテストする方法について触れていますが、人間のアノテーションを使うのは面倒なので、サンプルのチェックまで大きなモデルに任せています！これは本当に素晴らしい（そして豊かだ）。

注釈は、結果が正しいことを保証するために4-5回繰り返さなければならず、当然4-5倍のコストがかかる。

製品をデザインする学生にとって、コストと効果のバランスをどう判断するかは非常に重要になります。

6.4.6、エージェント、ファインチューニング、キューワードの境界線とベストプラクティス

キューワードエンジニアリング、エージェント構築、モデル微調整を、人に与えるタスクに対応させると、このように理解できる。

• タスクを設定するときに詳しく言うことに相当するキューワードエンジニアリング。
• エージェント・ビルディングとは、この人物にタスクを与える際にSOPを分解し、社内でどのようなツールが利用できるかを伝えることに相当する。
• モデルの微調整はトレーニングを行うことと同じです。

つまり、タスクを完了するためには、3つの手段すべてを使う必要があるかもしれないが、そのコストは3つとも異なる。

あるタスクを完了するために、どの最適化手段を使うべきか、これは現在の工学、アルゴリズム、製品、学者、これらの側面は非常に曖昧で、これはヨットや採掘のようでもあり、また臨床医学のようでもあり、どの手段を使うかを決める方法は、本質的に「推論」ではなく「実験」である。第一は「実験」であり、「推論」ではない。

そのため、上記の各論文は非常に多くのベンチマークテストを列挙する必要があるのです。これらのエージェントを設計した人たちは、その結果が良いかどうか自分たちではわからないため、検証するための実験が必要なのです。

だから、どのチームがAIの応用に強いか、弱いかという未来は、本当に

にかかっていると思う。

• このチームは素晴らしいベンチマーク・リファレンスの答えを持っていますか？
• このチームは、自分たちの設計が健全であることをより迅速に検証するためのプラットフォームを持つことができるだろうか？

速く実験する人は素晴らしいが、エンジニアリングの製品化は最後のステップだ。

最後に、私の個人的なアドバイスとしては、できることなら微調整はしないことです。微調整はモデルのパラメータレイヤーを変更するため、コストがかかり、移行も不可能だからです。そして、微調整の本質は、大規模なモデルチームとアルゴリズムをロールすることであり、データをロールすることであり、インロールは長期的には意味がありません。

記事ソース：https://mvread.blog/archives/465