tmaehara.bsky.social
https://tmaehara.gitlab.io/; TCS Researcher & ML Engineer.
Brilliant British Foods: https://bsky.app/profile/did:plc:dqxsa5cjfrzulhalom4kuyd2/feed/aaaiqwjhlzavy
Bluesky Bots https://gitlab.com/tmaehara/bluesky-newsbots
2,353 posts
1,188 followers
790 following
Prolific Poster
Conversation Starter
comment in response to
post
Sure, there are dedicated conferences for AI/ML. But if you go to, say, a software engineering conference, these days they are full of papers of the flavor "AI for SoftEng" and "SoftEng for AI".
Where are the prominent TCS analogues, esp. of the flavor "using AI to accelerate core TCS research"?
comment in response to
post
こうして得られる実装は有限状態トランスデューサと似たものになるので（状態は会話の段階，入力はユーザのメッセージ，出力はBotメッセージ），個人的に「FST 的な実装」って呼んでる．いまのところのわたしのベストプラクティスがこの実装方針．
comment in response to
post
この２段階構成の問題は複数ラウンドの会話．例えばbotに書籍購入機能を足すことを考えると「この本が欲しい→本当に買いますか？→はい」みたいな確認ラウンドを入れたくなるけど，これを２段階でやろうとしたらトップレベルが「『本当に買いますか』に対する反応」を分類しないといけなくなる．これはそもそも難しく，複数ラウンドが必要なケースが増えたときに先述した足した部分以外が壊れる問題が容易に発生する．
これを解決するには，２段階をやめて多段階（複数状態）にし，状態を陽に持ち歩いて「『本当に買いますか』に対する反応」はそれが必要な部分で判定する（i.e., トップレベルでは判定しない）になる．
comment in response to
post
従来のプログラムであれば if then else の if 側の変更は else 側に影響を与えないんだけど LLM-based ではそうならない．開発のそれなりに大きなエフォートがこれを防ぐことに費やされる．
経験上，これを防ける唯一の手段はプロンプトを動的生成すること．まずトップレベルに「これは著者クエリか書籍クエリか」を判定する LLM を置く．そして，その結果に応じて著者クエリ用のプロンプトと書籍クエリ用のプロンプトを動的に展開して継続実行する．こうすれば著者クエリ側の変更は原理上書籍クエリ側に影響を与えないので，それぞれを自由に開発できるようになる．
comment in response to
post
LLM-basedで難しいのは「一部の変更が全体に影響を与える」こと．例として「この本の著者は誰？（著者クエリ）」と「この著者の本を列挙して（書籍クエリ）」という２機能をもつ書籍検索botを考える．素朴にはプロンプトにこれらに対する応答を書けばいいんだけど，この方針は割とすぐに破綻する．
どう破綻するかというと，例えば書籍クエリのほうに「結果はリストで表示して」と書くと，何もしてないのに（＆そうしてほしくないのに）著者クエリも結果をリストで返してくるようになる．機能が増えるとこういうのが抑制できなくなり，それ以上どの部分にも変更を加えられなくなって開発が停止する．
comment in response to
post
きっと次の段階として (1) 80% (2) 20% with Claude Code みたいなことをしないといけなくなり，おわりですね……．
comment in response to
post
よくよく考えたら，わたしが従来やってた仕事が減ってるだけだった．大きく分けて (1) 複雑度が高いコード，(2) 複雑度が低いコードの２つがあり，従来わたしの作業時間は (1) 80% (2) 20% くらいだったけど，Claude Code ぶん回しワークだと (1) 40% (2) 60% くらいになっていて，頭を休められる時間がめっちゃ長い．
comment in response to
post
Chat Bot を書くのに FST を使うのは古き良きアレだと思ってたけど，LLM になったところで変わらんね．状態をうまく選んで遷移幅を減らすのがとても大事．遷移が広い = プロンプトが長い = LLM が間違えやすい，に直結するので FST そのものの設計の重要度は古き良きより大事になってる気がする．
comment in response to
post
生命保険は良い例っすね．「被保険者があと 5 年以内に死ぬ確率」みたいなのを見積もらないといけない．
comment in response to
post
tool の連鎖とか if else もできる。もっと書きやすいほうがいいけど、トランスレータは簡単に書けるからそんなには困ってない。
comment in response to
post
普通こういうのを実装しようと思ったら各タスクに対して組み合わせを自分で実装することになるんだけど，LLM + Tool だとその部分を省略できる．別の言い方をすると「指数個の API 呼び出しの組み合わせの実装を LLM １個で代替できる」のがとてもアドい．
comment in response to
post
イメージとしては，例えば書籍をタイトルまたは著者で検索する機能と書籍のメタデータをとってくる機能を別々に API で実装して MCP compatible にしておくだけで，手元のクライアントが勝手に「カラマーゾフの兄弟を書いた人の他の作品を教えて」に答えられるようになってくれる．
comment in response to
post
ちなみに先月はこんな感じ．今月が怖いわ．
comment in response to
post
そのとおりです
comment in response to
post
もちろんこれが刺さるプログラムとそうでないプログラムはあるんだけど（例えば latency が重要なものとか inference の対象が膨大なものとかは対象外）、刺さる場合があまりに強い。chat client で置き換えられるアプリはもうこれでいいや。
comment in response to
post
大きなプログラムを作る代わりに小さな単一目的の API を複数作って MCP で LLM に公開するだけで LLM が勝手に plan して処理してくれる。これはかなりすごい。