#ベクトル検索

検索基盤の話は、一見すると地味です。けれど、裏側の設計が変わると、検索の速さだけでなく、できることの幅まで変わります。turbopufferはまさにそこをいじり始めました。ベクトル検索を売りにしてきた同社が、次の版では「ベクトルを主キーにしない」構造へ移ると宣言したのです。単なる内部改修ではなく、製品の性格そのものを変える話だと思います。 turbopufferは、検索基盤のストレージ設計を大きく変えると発表した。新しい版である turbopuffer v3 では、文書とインデックスの配置、書き込み、圧縮、クエリの扱い方まで見直す。狙いは単に vector search を速くすることではない。text search、regex search、そして将来的にはより多くの SQL クエリまで、全体を速くする土台を作ることにある。 このサービスは最初、serverless vector database として始まった。オブジェクトストレージを真実の保管場所にし、NVMe SSD とメモリの階層的なキャッシュで速度を出す設計だった。初期の利用者としては Cursor や Notion が挙

LLMに長時間の作業をさせると、途中まで積み上げた前提を忘れたり、いったん否定したはずの仮説をまた持ち出したりする。今回取り上げる記事は、その不安定さをどう抑えるかを考えた末に、著者が「記憶」を会話履歴ではなくプログラム解析の問題として捉え直した話だ。単なるメモリ強化の工夫ではなく、Datalog というルールベースの仕組みまで作ってしまったところが面白い。しかもそれを、脆弱性調査の実務にかなり近い形で組み立てている。 著者はここ数か月、脆弱性調査向けに LLM agent を試していた。大きなコードベースを歩き回ったり、見慣れないサブシステムを説明したり、攻撃面を探したりする用途では、LLM はかなり頼れるようになってきたという。ただ、調査が数時間単位に伸びると、同じ問題が何度も起きた。モデルが、すでに否定された仮説を再び提案したり、間違いだと分かった前提に基づいて推論し続けたりするのだ。人間が「それは違う」と伝えても、その前提にぶら下がっていた他の結論まで自動では消えない。 最初は、こうした混乱を減らすために memory system を探っていた。一般的な方法は、古い会話や観察