mkX@おまじない

agent memoryの長期記憶スコアリング計測ってどうすればいいの？ raw text + grep,RAG,GraphRagなどの手法を超えて長期記憶のスコアリングないよな・・・ エビデンスID付きの短期記憶スコアリングしかない

codexのコンテキスト圧縮便利だけど、　24h連続コーディングしたらドリフトします

近いです。ただ Span の前後を見るというより、model turn / tool call を最小単位に正規化する感じでした。 raw trace の階層や attribute 名は framework 依存なので、そこは adapter で吸収して、input / tool schema / tool call / tool result / mutation / verifier / finishみたいな event 列に落とす。 その上で reference agent trace と 開発agent の step を比較して、「この turn からズレた」「ここで probe が増えた」「first-write は速いけど間違った方向に進んだ」みたいに見る感じです。 LangSmith の自動改善系はかなり面白いですね。 こういう泥臭い話、実際に agent 開発してる人とできるの嬉しいです🤗

あぁ、なるほど。OTel のTraceではなく、OTelのTraceでいうところのSpanレベルの前後でだけ見るとかって具合ですかね？ 確かにそういった方法であれば出来そうですね。(漠然とは、トレースを分解していくなら、ある程度は出来そうだなぁとは思ってはいましたけど、それでも机上に空論レベルだったもので…いや、そもそも分解したところでフレームワークごとの差分吸収が難しいか…) 確かに、Agent Loopなんかもそうですが AIエージェントを組み込んだ仕組みだとか面白いですね！AIエージェントでも設計が難しい部分ですから。 ただ、きちんと調べていないのですが、LangSmithがAgentの自動改善の仕組みを作ってるらしいので、そのうち、Agent Loopなんかも設計できるようになっていくのかも知れませんね。

確かに基本自体はそうだけど、フレームワークごとにトレース内のどのspanにユーザーのinputがattribute として設定されているのか？だとかが違ったり、OTelのSemantic Conversations の attributes名に従っていなかったりだとかして、Observabilityや評価のためのスクリプトなんかを作るのが難しい(最悪、アプリごとにトレース構造を正規化する処理を用意しないとならないまである)というのが問題ではある。 MLFlow 3.12.0だとこんな感じだけど、例えばKotlinのKoog とか使うと、トレース内のどこかの階層にユーザーinputがあって…みたいになるので、観測の基本部分以外の課題が厄介なんですよね。 mlflow.org/docs/latest/ge… 基本的には同じでも、フレームワークごとに違う時点で、扱い辛いってなるんですよね。 Koog しか使わないとか、Koogのバージョン自体をアップデートもしないとかでないと、評価し辛いとなるのが問題点。 そこが改善されれば、あとはどんな評価基準で評価していけば良いの？となるんだけどねぇ…(まあ、厳密には他にも考えないとならない部分は色々とあるだろうけど)

なぜみんなオレオレメモリーシステムは作るのに、それを評価する仕組みを作らないのか

memory評価bench がterminal bench並みに育ってなくて自作しないといけないのつれぇ・・・ 今年中には出ると思うけど、待ってられないから作るしか無いか・・・

ぶっちゃけ観測は基本やで。 そもそもこれが無いとagent loopまともに実装できないし、どこを直せばいいかもわからんくなる。 なぜここでtool使わなかったのか？プロンプトが悪いのかtool surfaceが悪いのかtool resultの圧縮方法が悪かったのか 観測性が担保したらrepalyできるようにしとく プロンプト、ツールそれを微妙に変えて同じモデルターンを1回だけreplayできるようにする モデル挙動が変われなければ、元に戻して再設計する github.com/mkXultra/mew でterminalbench でcodex級に育てたので死ぬほど知見は溜まった。 観測性を担保した上で評価ハーネスをまともに作らんと効果的にブラッシュアップできん

codex相当にするためにモデルターン分析は当たり前にいれたけど、このプロンプトが効くか特定ターンのプロンプト変更でのreplay、なぜその判断をしたのかを聞けるプログラムなどめちゃくちゃ頑張った。

ついにterminal bench のcoding taskでcodexと同等のパフォーマンスを実現した

自分用に IRIDOME というサービスを作り始めてます。 焙煎事業と、やりたいIoTもつなげたい、というのが最初のきっかけという感じ。 まだ開発中ですが、LPだけ先に公開しました。 焙煎に関わる方、よかったらのぞいてみてください。興味持ってもらえたら嬉しいです。 iridome.com

marpで作るよりもHTMLスライドの方が綺麗だ ええやん、ええやん

codex経由のgpt 5.5 xhigh品質落とされている気がする・・・

過適応になっている可能性はあるが、そこは少しずつ直せばいい。 codex超えは壁を超えた感がある

初めてcodexスコアをこえたああああああああああああああああああああああああああああああ

エンジニア人生の中で今一番楽しいかもしれない 個人が企業と技術で殴り合えるのは今しか無いぜよ

人間を介在させない1 agent loopですら開発に難しいのマルチエージェントオーケストラとか本当に作れるの？って思う 自然な形での思考誘導とかreasoning chainの固め方とか死ぬほど難しいんだけど ベンチマーク取るしかないし

あああああああああああああああああ どうしてもcodexの挙動を再現できない 初期探索->apply_pathの挙動が早ぎる

いやーまじでclaudeハックだよなー 企業意思決定遅いから、個人はすぐにやめられるけどclaude codeが入り込んだ実績があるから少し高くなってもやめられなさそう そして、各リポでclaudecode用にチューニングしたらさらに抜けられなさそう 12月時点で、かなり怪しい動きだったからclaude依存をなるべく減らしていた意思決定はよかったわ GLM5.1も賢いしローカルLLM環境構築も視野にいれないと

claude -p まで別使用量とかさすがにやばすぎない？ もうこれパワーユーザーの追放じゃん

gemini cliからollama cloudに変えて快適 マルチエージェントワークフローで詰まることもないし