これも

Embeddingしベクトルに変換する

バッチ処理でEmbeddingし、ベクトルに変換する

列挙はされているけど、体系的とは思わなかったです。

これをやるためには、あらかじめ正解データを要する必要があるってことですよね?

あとは性能指標をはかるコード例へのリンクとかあるとうれしいかなと思いました。

等幅フォントなのが気になった。説明資料へのリンクがあるとよさそう

これは話として唐突だなと思いました。そもそもメタデータがなに、という話がされていない

まずは、が連続している。なくてもよさそう

ここで語りたいことを最初に説明してほしい。

このままでもいろいろできるけど大量データを処理するには大変。ANNを使って検索を効率化するのと、◯◯のためにベクトルを軽量化するっていう考え方があるよ。

みたいなこと?

2つの話がどう関連するのかが明確に語られていないと思うので、どう四dならいいかがわかりにくい

リンク先はgihyo.jpのURLとなるはず

図を見たけどあんまりイメージがわかないです。他の人はイメージわくかな?

不要なスペース

ここの処理は全画像を処理するときとほぼ同じなので、関数化して共通化できるといいなーと思いました。

queryとして単語だけじゃなくて文章になっているものも試してほしいかな

ここは処理中表示だから不要そう

関数化して main() から呼んで欲しい派

4と2を分ける理由があまりわからない。 1画像分の処理をする関数があるならわかるけど、全部の画像をまとめて処理しているので2つの処理に分けている理由があまりないと思う

これ読みにくいから、関数にして普通のif文にしてほしいなー

def get_hoge_device() -> str:

もしくは device = "cuda" if torch.cuda.is_available(): device = "mps" elif torch.backends.mps.is_available()" device = "cpu"

ここは main() を作ってその中にいれてほしい派

同じ実験ができるように、この画像群を共有してほしい。zipにしててダウンロード可能にするとか

これもEmbeddingを生成する、であってますか?生成されるものがEmbedding?

として◯◯のプログラムを作成します。

一般的です

かなぁ

新しい用語が出てきた。これはなにか説明してほしい

作り直されるものは「画像Embedding」であってますか? 私的には、画像Embeddingは「画像をEmbedding処理する」という「動詞」のイメージで、作り直されるのは「画像ベクトル群」なのかなと思っています

下のフローチャートにも「画像Embedding」という用語がない

下の画像の画素が荒い。たとえば以下でレンダリングしてpngやsvgでダウンロードすればもうちょいきれいな画像になる(左下からダウンロードできる

https://mermaid.live/edit#pako:eNp1UctKw0AU_ZVy121tHqYmiBt1pxvdaUTGZPqAJinTCT5KoU1EKlR8IigoCC4qoi5E8BHwY8bSduUvOJkaQcFZnXvuPefcy9TB8mwMBhQq3rpVQoSm5hZMN8UfxRt02QQW7rDgjgUvLGxPrpGxKdbsDJ6uWWtbcBcsjFjI8W0MmnsmrKQymSmhXsWu9ceBBV0WPrLgUciafHoUVnZQEfPZ_slbL9xPTAT77TLq_KdP4oSsVkVWbNY76Hw8N1l4xoKHODu87d-8Dk-PxRmfUXvwfijOCFjrngVHw6vLjyhirW6vfd27P_-Mdn-v99vfdCENRVK2waDEx2lwMHFQXEI9FplAS9jBJhgc2riA_Ao1wXQbXFZF7pLnOYmSeH6xBEYBVWq88qs2onimjIoE_Ywgn3qLm66V1NguU4_Mj_5OfGEinBWdH2vs2phMe75LwZDHJZENRh02wJDyelbXZTWfVyWNAzkNm5zVclldyasTKqdlKaerjTRsiW1zWU1XlAlFz0mqIimaJje-AN-d7Qg

持ちません。そのため、

のように文が長いので区切ってほしい

システム構成?ライブラリ構成?

これ、従来の手法だと画像を説明するテキストを生成して、そのテキストをエンコーディングしていたけど、そうじゃなくて画像そのものを処理するっていうのがポイントなんですよね、多分?

なにを横断している?

複数のデータ形式を横断的に、とか

◯◯が同一空間に

こういうものをなんで「マルチモーダル」と言うのか説明してくれるとうれしい

モーダルってのはmodality(様式)のことを言うらしい? https://www.aist.go.jp/aist_j/magazine/20231129.html

これまで、がどこを指しているか不明確。(一瞬歴史的な話かな?と思った

「先月の記事では」とか具体で示してほしい

見出しがあったらその下には「ここでは~~について説明します」みたいな文章があるといいと思う派

ちょっとこの文章の意図が読み取れないです。

概念的に、なにの仕組みを、どのように整理するのか。なんのために?

いること

やっていることは最初の方と同じなので、差分があるコードだけをここでは示すでもいいかなと思いました。(記事も全体的に長いし)

そのまま実行できるコードはここだよ、としてここでは新しい要素だけのコードがほしい

モデルカードってなんですか?

Web画面のスクショがほしい

デフォルト値指定しているけどあえて変更している。 このサンプルコード的には意味がないのでどちらかに統一で良いのでは

なんでここ太字なんだろ

プレフィックスとプリフィックスの表記揺れ

される

文体の統一

「文」でもよいかなと思った

対応したEmbeddingモデル

と言いたい

サーバーの起動は1つ前に書いてあるし、あえて書かなくてもいいかも?

クラウドに送信される

とか

サーバーを別で用意するの?と思われそうなので、下の表とあわせて

Ollamaサーバーの起動が必要

の方がわかりやすいかなと

ここのTODOは対応する?

Googleで検索してもあまりひっかからないけど一般的な用語ですか

"ベクトル永続化"

バッチ処理だからforより高速、というのがよくわからないです。

この表ありがたいけど、その元となる情報がどこにあるのか、参考情報とかのリンクがほしい

このあたりの選択肢はどこで調べたらいいの?を書いて欲しい

と思ったら次のセクションに書いていた。 ここにはどのモデルを使うかの話は書かなくていいのでは。

ここの手前で見出しを分けて「エンベディングの3つの方法の比較」みたいな話でまとめてほしい。

ローカル、外部API、Ollamaの3種類あるよ。それぞれ使いたい場合はこんな感じの書き方、比較するとこうだよ(比較が先でもいいかも)

キーが必要なのとお金がかかることは説明した方がよいかと

次のコードの都合でこの説明になっているけど、自分だったら以下の順番で説明して欲しい。

• エンベッディングとは
• 実際にいくつかの文字列をエンベッディングして結果確認するコード→次元数チェック、値の一部を確認
  • できればモデルを変えると結果が変わる話もしてほしい
• ベクトルの近さを図る指標の説明
• コードでベクトルの近さを確認する部分を追加→結果でよさそうな値が出ている

値が全部0.XXXなのでどれが近いかわからない。値を入れて欲しい

これもマルチモーダルになってから説明すればいいかなと

このあたりは後半で必要になったときにまた紹介すればいいかなと思う。 まずは、テキストのベクトル検索だけに焦点を絞って説明した方がわかりやすいと思う

ライブラリはそれぞれリンクがほしい

このスタックがさっきの4つのステップとどう関連しているのかを説明してほしい。用語が多くて理解が難しいです

このステップを表した図が欲しい

これも永続化では「データベース」とは書いていないので、どのデータベース?となる

この前に「モデル」が出てこないので、なにと同じモデルかが不明。ベクトル化のところに説明が必要

長くなる場合はマルチモーダルは次回に回すのもありかなと

ここは、このセクションの内容とは直接関係なさそう。まとめとかに入れた方がいいのでは

メソッドでは

(´・∀・`)へぇ〜

これって一つ前の起動コストが時間には含まれていないんですか?

起動コストは4ワーカーのみだから一つ前とおなじくらいってことなのかな?ちょっとぱっと見どこをどう計測しているんだろう?って思った

起動コストはほぼ

ではプロセス生成がない分

とか書いてもいいかも

MacBook Air

でもいいかなと

これが具体的にどういうパターンなのかを教えてくれるとうれしい。

私の理解は基本はThread→CPUバウンドならInterpreterでいいかなーと思っているので

なんでここ7なんだろう。とくに意味のある数値ではないと思うけど

使用する

とかでよいのでは

独自のGIL、と、独立したGILという似ているけど異なる表現であることに意味はあるのか。同じものなら表現を合わせたい

独自のGILとGIL Bという表現の違いはあとでわかる?

意味的にはどちらも独自のGILと言えるかなとおもったので

表現を合わせて「起動コスト小」とかの方がわかりやすいかなーと

トル

最初の段階で「◯◯をするための機能」みたいな簡単な説明があった方が読みやすいかなと思いました

見にくいので改行を入れてほしい派

（みやすくするために改行を入れてます、的な

ここにもArticleInfo ArticleListを書いておくと、ほしいデータとコード上のPydanticモデルの関連が把握しやすくなるかなと

ここの「安全」も気になる

Pythonを安全に活用しているわけではないのでは

Pythonを拡張して型安全なLLMアプリを作成する

みたいなイメージ?

横スクロールしないと一番みたい結果がみれないので、改行して表示して欲しい

という機能

とか?「というのが」は口語的なので

コードでの出現順にあわせて、この項目が最初に来て欲しい

docstringを書いて欲しい

他に併せるなら、このコードは article_common_strict.py みたいなファイルにした方がよいのでは。

で、example_4.pyではそれをimportして使用する

これも安全という表現が適切か気になる。

LLMからのデータをバリデーションして、ルールに則ったデータのみを取得できます。

とか

Pydanticモデルの

スキーマとしてPydanticのモデルを

とか

article_common?

で◯◯を実装する

みたいに言いたい

安全っていうとどちらかというと、情報が漏れるとかそういう話を想像する。

ここで言いたいことは指定した構造のとおりのデータを受け取れるということを言いたいんだと思います。

LLMから適切に構造活かしたデータを受け取る?とか??

ここでOpenAIのAPIに対して「このスキーマに従って構造化したデータを返してね」としているので、その説明がコメントでほしい

もうちょい説明が欲しい

PydanticのモデルからJSONスキーマを生成し、そのスキーマで必須の項目(?)対してOpen AIでの◯◯のためにadditionalProperties: falseを追加する?

「additionalProperties: false」がないといけないというドキュメントへのリンクもあるといいなぁ

Pathオブジェクトからは以下で読み込む派

SAMPLE_THML = html_path.read_text(encoding="utf-8")

APIでの構造化出力を試す

の方がわかりやすいかなと

◯◯プロバイダーと呼びたいけど、なんだろう。 生成AIのAPIプロバイダー?

https://pypi.org/project/pydantic-ai/ 3.14に対応してそう?

節タイトルそのままだ冗長かなと思いました。

パッケージマネージャーuv、とか、HTTPクライアントHTTPXとかでいいかなと

トル

「」が区切りになるので「、」はなくてもいい派

節、トルでもいいのでは

トルでも意味は通じそう

機能

かなぁ

ドキュメント

今見たら3.14の翻訳率は50%くらいだったので「多くの」くらいがよいと思います

生成AIが台頭している今のタイミングで本書を手に取る意味、みたいなことは書かなくてもいいかなぁ。 普遍的な知識をつけるとか?

ここにコメントが欲しい

これは具体的になにをやっているのかちょっとわからなかったです。

最後のブログ記事の内容を確認して、もともとのタスクの依頼内容を満たしているかをチェックしている? 満たしてなかったらどうなる?

ここもうちょい具体的に書いてくれた方が、コードをもとにCrewAIがなにをやってるか明確になると思いました。

タスク全体をTaskの内容から把握し、実行計画を立てる。実行計画では◯◯調査、◯◯調査を実施し、その結果をもとにトレンド分析し~~

書くAgentの役割や能力を踏まえ、各タスクを以下のように額Agentに割り当てる

◯◯調査、◯◯調査: データ収集専門家

みたいな

閉じ括弧がない。このカッコ不要そう?

この説明だとLLMのバージョンが同じだったら同じ結果が返ってくると読める。

実際には実行するたびに微妙に違う結果が返ってくるのでは?

kickoff()メソッド

kickoff()は等幅フォントにしたい

デフォルトでは~~の説明が欲しい

一般の読者向け

とか

トレンド情報

かな

そういえばコードに全体的にキャプションを入れたい

これ、後の方に出てくるストーリーと同じですか?違ったら合わせて欲しい

実行したあとに幾つかログが抜粋で表示されていると、処理内容がイメージができていいかなと思いました。

次の行に「ログには主に以下の情報が」と書いてあるので、ログの例がほしいと思います

最初の例をYAMLも使った構成で書き直すとこうなります。 みたいなのが見れるとうれしいなー

シーケンシャルな場合との違いがあまりピントこなかったです

MUST: これだとコマンドラインで環境変数を設定しているように見える。コードブロックを分けた方が良い

ツールの説明がここまであんまなかったので唐突に感じる。

箇条書きは「だ、である」派

これも、先にどういう構成なのかを説明して欲しい。 図で示せるとわかりやすいかも。

tableが壊れとる...

list[BaseTool] 派。BaseToolってなに?

str | LLM | Any 派

Anyありなんかい!!

話が急に飛んでいる。

一度見出し「◯◯の主な引数」みたいなのを挟み

Agent、Task...には◯◯をするためにさまざまな引数があります。 以下に~~

見たいな文章がほしい。

SHOULD: コードの前に、どういうことをさせようとしているかの説明分がほしいです。 以下のコードのコメントを読めばわかるとは思うんですが、先に説明してからコードを読む方が、スムーズに理解できるかなと思いました

たとえばこういう感じかなと

最新のAI技術に対してわかりやすい記事を書くという目的で、調査員とライターの2人のメンバーがいて、調査員の調査した内容を元に~~~

dotenvが必須かなと思ったけどそうじゃなくて環境変数を.envファイルに書きたいから使っているだけですよね。

ここでは環境変数を.envファイルに書いて~~~のためにdotenvを使用します。

みたいな説明がほしいかなと思いました

ここも箇条書きにするなら文体を揃えたい

nits 箇条書きだと「体言止め」で文体が違うので、ここは普通の文章にした方がよいかと

ここも書き換えてください

1つの文で「以下」が連続しているので、こっちはトルでも意味が通じるかな。

上の文章と似た内容だけど微妙に情報が増えて箇条書きになっている。この箇条書きでなにを伝えたいかを直前に文章で書いて欲しい。

以下は〜〜です。 以下に〜〜を示します。

みたいな

例なのでしょうがないけど、自分でファイル名を指定しつつ、拡張子も指定するというコマンドは、オプションの用途としてピンとこないなと思いました。

何か数え方のルールとかを変えられるといいんだけど。文字数でカウントするかバイト数でカウントするか、とか

これも = をトルでいいと思う

キーハード引数を示すときに = って付けるのあんまり見たことないので、トルでいいと思います

nits: 表の文章は最後の。はトルでいいかなぁ

キャプションがない。

以降も同様

ここに中身を入れて、実際に動作させた例がほしい

オプションに値が

とか?

トル

これはコマンドで呼び出すときの話ですよね?ちょっとこの文章だけだと意味が取りにくい

「短縮形」と「長い形」という表現がいまいちだなと

短いオプション名と長いオプション名とか?

表でまとめた方が見やすそう

これはなんか--nameは名前を指定するためだけにしか使われないように読めるので、ちょっと違うかなと。

例えば、名前を指定するための--nameオプション、などです。

とか?

ちょっと意味が分からなかったです。

なんか変。以降もcaptionになってない

が

これもバッククォートで囲む

などのデコレーターを

外部ライブラリ

にしたんじゃないっけか

を作成

argparseについては「<project:#argparse>」を参照してください。

とか入れて欲しい

標準ライブラリの、と書いてあるのでモジュールはトルでよいかと

バッククォートで囲んで欲しい

バッククォートで囲んでほしい

毎回太字にしなくてよいかと。初出の時だけでよいのでは

Python 3.13からサポートされていますが、ここでは3.14のことしか書かない?

https://docs.python.org/ja/3.14/howto/free-threading-python.html

これはどこ情報なのか、が気になりました

完全に分離、とはどういう意味かがわかりにくい。

なにから完全に分離しているのか

表記揺れ: インタープリター

インデントがずれている

引数が増えているので確認してください

捕捉

コードを書き換えたのでこのコメントは正しくない

https://docs.python.org/ja/3/library/asyncio-runner.html#asyncio.run

3.12からloop_factory引数が増えてる

インデントが3文字になっている

なにを複数組み込むのか?

ruff checkとruff formatを実施

とか。なにを実施するか書いて欲しい

pre-commitはCIじゃないかなー

各種ツールでruffを使用する方法、とか?

日本語がなんか変です。

で行(おこな)っておくと?

引数無しで

引数無しで

これデフォルト設定だからなー。 クォートをシングルにできるけど、設定なしの運用でいいんじゃない?みたいな記述がいいかなーって思ってます。

カンマを付けたい派

これはストーリーとしては、この前に ruff check --fix を実行していないといけないので、そのように手前で実行している必要がある

使われていないモジュールだとF401が出ちゃうのでisortの意味がない(fixできない)

無理やり使うモジュールを入れましょう

datetimeとかなにかをいれてメッセージに追加する感じで

文章（文章）。

が正しい書き方(のはず)

トル

この手前でfixされたあとのexample.pyを表示して、import osが削除されていることを確認したい

す。

系なくてもいい派です

下の設定例だとpyproject.tomlなので

前述の設定ファイルを用いて、にしてコードのキャプションに「説明 - pyproject.toml」とか書くのはどうでしょうか

checkコマンド

とか

長いので、トルでも通じるかなと

表のタイトルを入れてください。

https://myst-parser.readthedocs.io/en/latest/syntax/tables.html#table-with-captions

と、

ここで、を打たないと「一部のルール」がFにもかかっているように読める。

もしくはE系の一部とF系のルールが

とか

Flake8 (以下同様

Flake8と最初は大文字かなと

https://flake8.pycqa.org/en/latest/

同様にデフォルト設定っぽいものは除外して必要最低限にしてほしい

デフォルト設定を設定例に書いているのが気になります。

デフォルト設定はここにあることを示して、設定ファイルとしては必要最低限の記述例でいいかなと思います https://docs.astral.sh/ruff/configuration/

整形

他の箇所と表現を合わせる

を記述します。

前の文は主体が自分だったので

他のライブラリとかでuvを使ったインストールには触れていないので、ここはなくてもいいかなぁ

ここも両方指定した場合と同じとか、まるっと省略してもいいかも

このへんも2回目以降は省略しちゃってもいいんじゃないかな

いいと思います