チャンク分割は、文字数ではなく、発言者単位
8 Matching Annotations
- Last 7 days
-
127.0.0.1:5500 127.0.0.1:5500
-
-
会議全体を見る必要があるため大きめ
- Map → Reduce 正規化（推奨の主軸）
Map: 各チャンクから候補テーマを独立に抽出。この段では重複を気にしない（＝プロンプトが軽くなり、チャンクを並列処理できる） Reduce: 全チャンクの候補テーマ名＋カテゴリ＋（可能なら1行の根拠）と、DBの既存nearby-topicsを1プロンプトに入れ、「同一テーマの統合・既存テーマへの名寄せ・正規名の決定」だけをやらせる dialogue-digest が既に map/reduce ＋チェックポイント再開の基盤を持っているので（仕様マップ§9でも「共通基盤化すべき」と指摘済み）、構造の流用先があります。副産物として、現行から存在する表記ゆれ問題そのものの修正にもなります。
- チャンクのオーバーラップ（補助策）
境界をまたぐ議論が文脈ごと切れて「テーマとして認識されない」ことへの対策として、10〜15%程度の重複を持たせる。ただしこれは取りこぼしへの対策であって、名前の割れは防げません（むしろ重複候補は増える）。Reduce があって初めて成立する補助策です。現行の splitMdBySpeakers が発言境界で切るのは維持すべき良い性質です。
-
Qwen
これ一本にする
-
API
セキュリティ要件の確認 適当に接続できないか
-
この差が設計を歪めている箇所が2つある。 既定の CLI モードでは systemPrompt も JSON Schema も効かないため、全ステージが 「system 文字列 + 空行 + 本文」を1本の user プロンプトに連結する方式になっている。 dialogue-digest が NDJSON + {"record_type":"end"} サーティネルという独自の壊れにくい形式を採ったのも、 Structured Outputs が使えないことへの対処である。 Gemini 経路では prompts.json の *_model が完全に無視される。 モデルは GEMINI_{STAGE}_MODEL → GEMINI_MODEL → gemini-2.5-flash の順で解決される。 しかも topic-aggregation は env 名が GEMINI_TOPIC-AGGREGATION_MODEL（ハイフン入り）になり、実質設定できない。
一本設計にしてきれいにする
-
"counters": [ { "name": "short", "max_tokens": 6000000, "window_hours": 5 }, { "name": "weekly", "max_tokens": 90000000, "window_hours": 168 } ]
リミットは不要
-
チャンク分割
qwenはもっと分割しないと
-
puller
これ何？
-