#自然言語処理

最初に思ったのは、「やっと em dash 問題を気にする段階に入ったのか」ということだった。AI が書いた文章の“匂い”として em dash（長いダッシュ）がやたら目立つ、という話はかなり前から見かけたので、そこが 95% 減ったというのは地味だけど象徴的だと思う。 ただ、記事でいちばん引っかかったのは、文章が短くなったのに答え全体は長くなっている、という点だ。短い文を使うと読みやすくなるのはわかる。でも全体の分量が増えるなら、体感としては「簡潔になった」というより「小刻みで読みやすいけど、結局しゃべる量は増えた」に近いのではないかと思う。ここはかなり人間くさいというか、モデルが“わかりやすさ”を取りにいくと、説明を足して結果的に長くなるのかもしれない。 あと、こういう改善が「AI slop を減らす」方向で評価されているのも少しおもしろい。文章の癖を消すこと自体は前進だけど、結局は見た目の自然さの話に寄っている。中身の正確さや、ほんとうに役に立つかどうかとは別の指標で語られやすいのが、いかにも今のAIらしいなと思った。 --- > 参考: [Claude Opus 5.5 use

生成AIの主役は、まだ文章を長く出すモデルです。ただ、実運用では「文章を作る」より先に「振り分ける」「危険か判定する」「点数を付ける」といった、もっと単純で速い判断が必要になる場面が多い。今回のLayaは、その部分だけを切り出して、しかも100以上の言語に対応させようという試みだ。記事の主張はかなり強いが、単なる速度自慢ではなく、なぜそういう設計が要るのかまで含めて読むと面白い。 元記事が紹介しているLayaは、「33ms Multilingual System 1 Decision Engine」と名付けられた判定モデル群だ。作ったのはConvAI Innovationsの創業者兼CEO、Nandakishor Mukkunnothで、2026年9月更新の記事として公開されている。中心にある考え方は、LLMに自由文を生成させるのではなく、構造化された問いに対して即座に確率つきの判断を返すことにある。 記事では、これを人間の脳でいうSystem 1、つまり瞬間的な反射にたとえている。たとえば、問い合わせメールをどの部署に回すか、受信メールがフィッシングかスパムか、入力文がjailbre

AI の文章は、内容だけでなく言い回しにも癖が出ます。今回の元記事は、Claude が特定の語をかなり強く好んでいるのではないか、という観察を扱っています。単なる雑談ではなく、モデルの振る舞いを言葉の側から見る試みなので、AI の出力を日常的に読む人ほど面白いはずです。しかも、こうした語の偏りは、生成AIが「賢く見える」仕組みそのものにもつながっています。 元記事は、Claude が出力する文章の中で、ある種の語彙が異様に頻出しているのではないか、という問題意識から始まります。著者は、その偏りを確かめるために、Claude の文章を観察し、どんな単語や表現が何度も現れるかを追っています。ここでの「load-bearing vocabulary」という言い方は、文章を支えるというより、文章の骨格になっている語、あるいは文の雰囲気を決めてしまう語、というニュアンスです。 記事の中心にあるのは、Claude がただ情報を並べるのではなく、特定の語を足場にして話を組み立てているように見える、という発見です。人間の文章でも口癖はありますが、Claude の場合はそれがかなり露骨に見える。たとえば

この手の記事を読むと、つい「モデルの中身」よりも先に「人間が読んだときの違和感」のほうに目が行く。今回もまさにそこが面白かった。Claude には、内容そのものというより、返答の骨組みを支えている語彙や言い回しがある、という見方はかなりしっくりくる。モデルを語るときに精度やベンチマークばかり見がちだけれど、実際に人が触るのは一文一文の手触りなので、そこの癖は思っている以上に大きい。 特に引っかかるのは、こういう“load-bearing vocabulary”が、単なる口調の好みではなく、思考の進み方そのものに見えてしまう点だと思う。たとえば「まずはこれ」「重要なのは」「つまり」といった型が多いと、説明は整って見える。でも裏を返すと、その型がないと話が崩れやすい。人間の文章でも似たことはあるが、LLM だとその依存がもっと露骨に出るのかもしれない。きれいに見える文章ほど、実は少数の言い回しに支えられている、というのは少し怖い。 一方で、こうした癖を見つけることは、モデルを過剰に神秘化しないためにも役立つと思う。賢さの証明として見るより、「この返答はどの定型句で安定しているのか」と眺めた

大きな context window は、記憶そのものではない それは「一時的に広い机」を持っているようなもので、セッションが終われば消える 以前の会話を毎回ぜんぶ送り直すやり方は、長くなるほど重く、遅くなる Retrieval は「必要な資料だけを本棚から持ってくる」仕組み Compression は中身をなるべく保ったまま、入力を小さくする工夫 Summarization は要点だけ残す方法で、元データは別に保存しておくのが安全 AIエージェントを作るときは、モデルに全部覚えさせるより、DBや検索の役割を分けるほうがうまくいく 元記事の主張はかなり明快です。 context window が大きいことと、memory があることは別物だ、という話です。 ここでいう context window は、AIモデルが一度に読める文章量の上限です。 人間でいうと「机の上に広げて見られる書類の量」に近い。広ければ広いほど便利そうですが、だからといって「その机が記憶装置になる」わけではありません。 著者のたとえがわかりやすいです。 巨大な机を買って、ファイルキャビネット

家のことを聞ける chatbot を作るために、質問をまずカテゴリ分けしている その分類を、わずか 0.6B パラメータの local LLM にやらせているのが実験の肝 ふつうの prompting だけでは精度が低く、fine-tuning で一気に改善した さらに、カテゴリ名そのものではなく短いコードに変えたら、精度がもう一段上がった ただし「water heater」と「pool」みたいな、水っぽい意味のかぶりはまだ苦手 大きいモデルを何でも屋にするより、小さいモデルに仕事を絞って任せる発想がかなり実用的だと思う 家庭内の質問に答える chatbot を作る、という発想自体がまず楽しいです。 「この部屋のエアコン、いつ替えたっけ？」とか「この前、プールのポンプを直したのはいつだっけ？」みたいな、生活の中の細かい記憶を引っ張り出してくれる相棒ですね。記事では、こうした家庭の知識を RAG で持たせています。RAG というのは、LLM が記憶だけで答えるのではなく、外部のデータベースを検索して、その結果を見ながら答える仕組みです。検索エンジン付きの賢い返事、という理解でだいたい合っ