去年も少し参加していましたが……本当に1年はあっという間ですね（涙）

面白いレビュー事例がたくさんありますね
https://reddit.com/r/MachineLearning/…

https://github.com/acaudwell/Gource

これも面白いです

あの大きな飛行機でハードウェア交換が3〜4時間しかかからないんですね。モジュール化がものすごくうまくできているようで驚きます...

使用したプロンプトがすべて載っていていいですね

bootc ベースの OS なので、参考にするとよさそうです

• https://bootc-dev.github.io/
• https://ja.news.hada.io/topic?id=20479
• https://ja.news.hada.io/topic?id=19473

これは面白いですね

韓国では問題はそれほど大きくないようです。

• 国土交通部と航空業界によると、国内の航空会社でA320系列旅客機を運航しているのは、大韓航空（18機）、アシアナ航空（24機）、エアプサン（21機）、エアソウル（6機）、エアロK（9機）、パラタ航空（2機）の6社
• このうち42機が今回のリコール対象だが、この中に3〜4時間かかるハードウェア交換まで必要な旧型機種はない
• 国土交通部によると、リコール対象の旅客機はすべて操縦席でのソフトウェアアップデートを通じて1時間以内に必要な措置を終えられ、11/30 6時時点で42機中40機（95%）がアップデートを完了

エアバスA320 – 強い太陽放射により飛行制御の中核データが損傷する可能性

本気でWindowsから離れようと思って、今回UMPCを1台購入してBazziteを使ってみているのですが、とても満足しています。韓国語入力の部分ではKDEが少し難しく、GNOME環境に移ってきたのですが、Macに似ていてとても気に入っています。GPTがかなり助けてくれます。

ベクターDBだろうが何だろうが、要するに検索さえ実装すればいいってことでは……

システムが十分な余裕と柔軟性を持って設計され、良い品質を提供できるのが望ましいですよね。そして、組織工学や開発方法論が今ほど発達していなかった時代と比べれば、平均的には確かにそうなっているのでしょう。

ただ、私には、エンジニアとしての自我は肥大しているのに、組織の一員としての責任感は不足している人が、これらすべては自分のせいではなく経営陣のせいだと言い訳しているように聞こえます。

建築技師、インダストリアルデザイナー、アニメーターには納期がなく、生産性ではなく創造性と品質だけで評価されていて、納期があるのはプログラマーだけなのでしょうか?

経験上、CS、特にPLTがしっかりしていれば、結局どんな環境でも比較的よいコードを書けます。

それほど大した知識がなくても、最も基本的な原則を理解している人なら、時間に余裕があり慣れたコードであれば、それなりのコード品質は出せます。リファクタリングをn回やれば、AIが書いたものでもそれなりにもっともらしくなります。

ひとつのソースにいくら長く携わっていても、20年選手を名乗りながらスパゲッティコードしか書けず、なぜそれではいけないのか分かっていない人も多いですよね。

完璧な環境で無限の時間と予算が与えられるのでない限り、あまり大きな意味のない空虚な話に感じます。どんな時代のどんな職種でも、これは同じではないでしょうか。

同じシステムでよりよいコードを書くことは、明らかにエンジニアの能力そのものです。

ここに投稿される文章は、おおむね OCP すら無視する国内SI市場の一部の視点や経験とは、やや異なる環境かもしれません。

いずれにせよ、リーナス・トーバルズはジュニアではありませんね……

Gemini：
はい、RAG（Retrieval-Augmented Generation）におけるベクトルデータベース（Vector Database） の利用は、2020年に関連論文が初めて発表された時点から、その概念的な土台が築かれていました。
RAGは基本的に検索（Retrieval） と生成（Generation） を組み合わせる方式ですが、この検索段階でベクトル埋め込みと、それを効率的に保存・検索するベクトルデータベースが不可欠な役割を果たします。
💡 RAGとベクトルDBの出発点
RAGでベクトルDBが必要だというアイデアは、次の主要な論文と概念から始まりました。

1. RAGの誕生：Lewis et al.（2020）の論文

• 論文タイトル: "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"（知識集約型自然言語処理タスクのための検索拡張生成）
• 核心: この論文でRAGという用語とフレームワークが初めて提示されました。
• Retrieverの役割: 論文で提案されたRAGモデルはRetriever（検索器） とGenerator（生成器） で構成されます。RetrieverはWikipediaのような大規模データセットから、クエリに関連する文書（latent documents） を検索します。
• ベクトルインデックスの使用: この初期のRAGモデルは、文書を検索するためにデータセットにベクトルインデックス（Vector Index） を使用し、事前学習済み検索器（pretrained retriever） が文書を取得できるようにしていました。
• 結論: RAGの中核段階である**「検索」** は、クエリおよび文書のベクトル表現に基づいて類似性を計算することで行われるため、効率的な検索のためのベクトルストア（Vector Store）またはベクトルインデックスという概念が必然的に内包されていました。

2. ベクトル埋め込みと類似度検索
   ベクトルデータベースがRAGの必須要素となった根本的な理由は次の通りです。

• 埋め込み（Embedding）: RAGシステムでは、外部知識（文書、テキスト）とユーザーのクエリ（質問）はすべてベクトル（Vector） という数学的表現に変換されます。このベクトルは、テキストの意味を高次元空間における密な数値配列として表します。
• 類似度検索（Similarity Search）: ベクトル空間でクエリベクトルに最も近い距離にある文書ベクトルを見つけることは、すなわち意味的に最も類似した（Relevant）文書を見つけることを意味します。
• ベクトルDBの役割: ベクトルデータベースは、このような膨大な文書ベクトルを保存し、与えられたクエリベクトルに対して最も類似したベクトルを高速かつ効率的に検索するために特化したデータベースです。したがって、RAGの検索性能を最大化するうえで不可欠です。
  要約: ベクトルDBが必要な理由
  LLMが学習していない最新の知識やドメイン特化の知識にアクセスできるようにするには、単純なキーワードマッチング（従来の検索）ではなく、意味的類似性に基づいて情報を探す必要があります。ベクトルDBは、この意味的類似性ベースの検索を効率的に実行するために、RAGフレームワークへ自然に統合された中核技術です。

ほんとにめちゃくちゃだな……。悪いコードだの良いコードだのっていう話はジュニアが騒いでることで、その業界に合ったソフトウェア設計をきちんとできるシニアがいるかいないかのほうが、もっと重要だ。

広告は始まりにすぎず、製品やサービスの購入につながるユーザー体験を提供することになるでしょう。ひょっとすると、Worldcoinまで提供するかもしれません。

RAGにベクターDBが必要だなんて、いったいどこから出てきた話なんだろう……

とても楽しく読みました。これからも続けて出していただけるとうれしいです（笑）

filebeat のような processor 的な機能を実装しようとするときに便利そうでもありますね..
https://www.elastic.co/docs/reference/beats/filebeat/processor-script