FAQ¶

対象: CPersona 2.6.x。 実運用オペレーターから実際に寄せられた質問 (匿名化済み) を種にしています。ここには短い回答だけを置きます。正確な詳細は挙動契約と運用 Runbook (いずれも英語が正本) にあります。

なぜ `recall` は最良のマッチを最後に返すのですか？¶

意図的な契約です。結果はスコア昇順で並び、最強の記憶が注入コンテキストの末尾、つまり LLM が最も強く注意を向ける位置 ("lost in the middle") に来ます。 hit@k を評価するときは末尾から数えてください。先頭から数えると数値が反転します。recall_with_context は別契約で、時系列マージを返します。 → 契約 §1

最新の決定が古い決定に負け続けます。新しさを勝たせるには？¶

優先順に:

負けたら実害が出る事実を recall に賭けない。 現行の決定は決定的に注入される面 (CLAUDE.md / system prompt) に置き、記憶は「問われたときに見つかるべきもの」に使います。
追記でなく上書き。 置き換えられた決定は update_memory で書き換えます。検索空間に存在しない古い決定は、勝ちようがありません。
その上で必要なら、事前分布の年齢の重み CPERSONA_PRIOR_AGE_RATE を設定します。品質ゲートが通した行の中で新しい記憶を上に来させ、古い記憶を除くことはありません。率を選ぶ計測が済むまで既定は無効です。 2.6.0a7 からは CPERSONA_CONFIDENCE_ENABLED=true はランキングに時間を混ぜず、各行の横に confidence の値を返すだけです。

→ recall に頼らないという選択

`CPERSONA_CONFIDENCE_ENABLED=false` は「一時的に無効化された」機能ですか？¶

いいえ。壊れているから無効なのではなく、保守的な出荷既定です。confidence はランキングの意味論を変えるため、opt-in で出荷しています。本番でも使われています (メンテナ自身のインスタンスは rsf + confidence on で運用)。2.6.0a7 からは、有効にしても各行に confidence の値が加わるだけです。 CPERSONA_CONFIDENCE_ORDERING=legacy で、以前のリリースの再ソートと confidence によるゲートに戻ります。 → 契約 §2

Markdown ファイル群の索引を CPersona と同期し続けるには？¶

ファイル監視も upsert も組み込まれていません。CPersona は受動サーバーで、投入は常に呼び出し側が駆動します。サポートされるパターンは 2 つです。(A) 索引専用の agent_id を切り、変更時に丸ごと再構築する方法 (まず推奨。差分ロジックが不要で、常に正本と一致していることを証明できます)。(B) 呼び出し側で content-hash 台帳を持ち、変更チャンクを update_memory で更新する方法。唯一の罠は、変更された内容を同じ msg_id で再 store しても、何も告げられず skip され、更新されないことです。 → コーパス索引パターン

日本語 (CJK) コーパスでは何を設定すべきですか？¶

CPERSONA_RECALL_MODE=rsf を設定します。それだけです。rsf モードは FTS5 の弱い CJK トークナイズを補うために存在します。既定の埋め込みモデルは、クエリと記憶が固有名詞・識別子のアンカーを共有すると強く、語彙が重ならない純粋な概念一致には弱い性質があります。具体的なアンカー語を入れてクエリを書くのは、正しい適応です。 → 日本語 / CJK コーパス

recall の結果が少なすぎます。実際に効くつまみはどれですか？¶

set_recall_precision(agent_id, "lenient") です。既定の fusion mode では実質唯一のポリシーつまみになります。CPERSONA_AUTOCUT_MIN_RESULTS は rsf / rrf では何もしません (autocut はランク融合スコアでは意図的に不発です)。 fused gate 全体の無効化は、最後の手段です。 → recall のチューニング

コーパスが `CPERSONA_MAX_MEMORIES` を超えたらどうなりますか？¶

何も削除されず、何も壊れません。この定数はベクトル走査窓であって、保存上限ではありません。窓より古い行も FTS・keyword 経路からは届きます。大規模コーパスでは env で窓を上げてください。それが想定された使い方で、アーカイブ運用は不要です。 → 契約 §4

`archive_episode` はどの頻度で？過去分の一括投入は害がありますか？¶

想定頻度は、セッション終了ごとに 1 件です。

既定の設定なら、過去分を一括投入しても害はありません。問題になるのは、エピソード境界ペナルティ (2.6.0a7 から既定で無効) を有効にしている場合だけです。このペナルティは現セッションの記憶を穏やかに優先します (境界より古い記憶は下限で半減)。境界は単に最新エピソードのタイムスタンプなので、ペナルティが有効だと 過去の会話を一括投入すると境界が投入時刻に動き、それより古い全記憶がペナルティ対象になります。エピソードの backfill はしないか、する間はペナルティを無効のまま (CPERSONA_EPISODE_PENALTY_ENABLED=false) にしてください。 → 契約 §3

`lock_memory` で記憶の順位は上がりますか？¶

いいえ。lock は削除・編集からの保護です。ランキングには影響せず、locked でも recall で負けることはあります。「失われては困る」なら lock、「常にコンテキストにあってほしい」なら決定的注入です。

プロフィール (update_profile) が確実に浮上する経路になるのは、confidence scoring が on のときだけです。off (既定) ではプロフィール行はスコアを持たず、コーパスが埋まっていると limit で切られます。 → 契約 §7 / §9

operating context は設定が必要ですか？¶

単一クライアント・単一エージェント運用なら不要です。未設定が正しい状態であって、欠落ではありません。operating-context.toml は、1 つのサーバーに複数の MCP クライアントを接続し、共通の運用指示と project-id レジストリを全クライアントに配りたいオペレーターのための道具です。 → OPERATING_CONTEXT_DESIGN

データベースを安全にバックアップするには？¶

サーバー稼働中の素朴な cp は不可です (WAL のため)。sqlite3 ... ".backup ..." か VACUUM INTO を使うか、サーバーを止めて .db を -wal / -shm ごとコピーしてください。月次の export_memories JSONL を併用し、稼働中の DB はクラウド同期フォルダの外に置きます。 → バックアップとリストア

埋め込みサーバーが死んだことに気づくには？¶

自分で見張る必要はありません。劣化中の recall には advisory フィールドが付き (エージェントに表示させてください)、行を書いた store は embedded: true|false を報告し、check_health(fix=true) が停止中に書かれた行を修復します。

ただし embedded だけを見張らないでください。skipped や rejected の store はこのキーを持たないため、コーパスに既にある内容を再 store しても、encoder については何も分かりません。また check_health が緑なだけでは、エンドポイントの生存証明になりません。 → 埋め込みサーバー停止の検知

CPersona が LLM で記憶を統合・要約する日は来ますか？¶

来ません。サーバーは生成モデルを呼ばないことは不変の核ドクトリンです。モデルとの通信は embedding だけなので、記憶自体に API コストがなく、決定論的に動きます。

将来ラインで計画されている想起側の機能も、決定論的な SQL と純関数の範囲に留まり、生成文ではなく出典を追跡できる結果を返し、元の記憶を改変も置換もしません。意味的な要約は従来どおり呼び出し側エージェントの仕事で、その結果の置き場が archive_episode です。

いいえ。MIT ライセンスであり、支援しない人に対して何かを出し惜しみすることはありません。有料ティアも、支援者限定ビルドも無く、issue の扱いにも影響しません。支援についてに「買うもの・買わないもの」と、お金がかからない助け方を書いています。