LLM groupingの最初の実験については、専用の記録ページを持った方がよい。理由は、この実験が単なる bugfix ではなく、analysis_mode=llm_grouping の product 価値、scatter 互換の限界、次の view 設計、という複数の論点を同時に含むからである。llm-grouping-implementation-planより
2026-05-25 時点の最初の実験データとしては、work/kouchou-ai/apps/admin/public/sample_comments.csv を使うのがよい。このファイルは 400 行の日本語コメント を持ち、現在の analysis-core 実装に対して「少なすぎず、多すぎず、最初の LLM grouping 実験として扱いやすい」サイズである。source-codeより
目的
この実験の目的は 3 つある。
analysis_mode=llm_groupingが raw argument を直接 LLM 分類しつつ、viewer 互換の artifact を本当に生成できるか確かめる- embedding 由来
x/yに LLM grouping の結果を重ねた散布図が、どの程度「見えるがいまいち」になるかを観察する - その観察をもとに、
hierarchyList/treemap/ 専用 view のどれを次に優先すべきか判断する
今回使うデータ
対象ファイル:
work/kouchou-ai/apps/admin/public/sample_comments.csv
観測できた性質:
- 行数は 400
- カラムは
comment1 列だけ - コメントは日本語
- 中身は AI に関する賛成・期待・懸念・規制・雇用・教育・プライバシーなど、ある程度テーマが散っている
なぜこのデータがよいか
1. 日本語で観察できる
今回の実装と prompt は日本語前提の観察がしやすい。example-polis.csv は量としては良いが英語データなので、最初の「結果を人間がざっと見て違和感を掴む」実験には、日本語 400 行の方が向いている。
2. 400 行は初回実験としてちょうどよい
small_comments.csvの 5 行では LLM grouping の性質が見えにくいdummy-comments-japan.csvの 20 行でも scatter の違和感は観察しづらい- 400 行あれば top-level grouping の崩れ方、cluster size の偏り、scatter 上の混ざり方がある程度見える
3. Admin 公開サンプルなので later に UI 経路へ戻しやすい
このファイルは apps/admin/public/ にあるので、analysis-core 単体での実験後に Admin/API 経路へ戻す時も文脈が切れにくい。
注意点
このデータには今のところ comment-id, comment-body 形式ではなく、comment 列しかない。したがって、現在の CLI canonical path にそのまま流すには 入力前処理 が要る。
最小の前処理は次で十分である。
comment-id: 連番を付けるcomment-body:commentを rename する
source や属性列は無くても、今回の first experiment には支障がない。
観察したいポイント
実験後に最低限見るべきなのは次の 4 点である。
- LLM grouping 自体のまとまり
label / description が人間から見て自然か - scatter 上の違和感
同じ group が 2D 上で無理に散って見えないか - cluster size の偏り
1 グループに吸い込みすぎていないか - 次の view 候補
scatter よりhierarchyListやtreemapの方が自然に見えそうか
次の実務
このページの次の更新で残すべきなのは、少なくとも次である。
- 400 行データを
analysis-core入力形式へ変換したか analysis_mode=llm_groupingで実際に完走したか- scatter 互換の見え方がどうだったか
- 次に優先する view が何か
Open Questions
sample_comments.csvはテーマが AI 周辺に偏っているので、LLM grouping での「対立軸発見」の観察には十分か- 400 行を 1 回で group discovery させるより、先に sampling して top-level groups を決める今の実装で十分か
- 実験 2 本目は
example-polis.csvのような英語・実データ寄りサンプルに広げるべきか
Updates
- 2026-05-25: 初版作成。
sample_comments.csv400 行日本語データを、LLM grouping の最初の観察対象として採用する判断を記録 - 2026-05-25: 実験を実施。
sample_comments.csv400 件をcomment-id, comment-body形式へ整形し、analysis_mode=llm_groupingで 422 argument を 8 群へ分類できた。群ラベル自体は自然だが、embedding 由来x/y上の separation は弱く、silhouette score は-0.039、centroid ベース再分類精度も0.488だった。したがって、短期互換案としては成立するが、次に優先すべきは scatter 改善より group-first な別 view の検討である。llm-grouping-experiment-output-2026-05-25より - 2026-05-25: 同じ 422 argument / 同じ embedding を使って
cluster_nums: [8]の従来 hierarchical clustering と比較した。従来法は silhouette score0.400、centroid ベース再分類精度1.000で、scatter の見やすさでは明確に優位だった。つまりこの比較は、「LLM grouping が悪い」のではなく、「LLM grouping を散布図に載せるのが不自然」という解釈を支持する。llm-grouping-experiment-output-2026-05-25より - 2026-05-25:
~/broadlistening-researchの 2025-02 judge を参考に、OpenAI API で top-level ラベル品質も比較した。一貫性 / 具体性 / 網羅性 / 区別性の平均点はLLM grouping 85.0、hierarchical 80.4で、judge の全体判定もllm_grouping勝ちだった。よって今回の結論は「geometry は従来法、label semantics は LLM grouping」と二軸で持つべきである。llm-grouping-experiment-output-2026-05-25より - 2026-05-25: 費用対効果まで含めると、same-args downstream 比較で
LLM groupingは35,654 tokens / 149s、従来法は7,088 tokens / 49sだった。つまりLLM groupingは scatter を良くするには割高で、label semantics を良くするための追加コストと解釈すべきである。次に view を変えずに mode だけ増やしても費用対効果は出にくい。llm-grouping-experiment-output-2026-05-25より - 2026-05-25:
K=20でも実験した。geometry はK=8と同じく従来 hierarchical が優位だったが、label quality はLLM grouping K20 83.3、hierarchical K20 85.0と平均点ベースでは逆転した。一方で集合全体を見た direct judge はllm_grouping_k20勝ちを返しており、judge の粒度によって結論が揺れることも分かった。今後はmethodだけでなくKとjudge granularityも主要変数として扱うべきである。llm-grouping-experiment-output-2026-05-25より - 2026-05-25: 多層 hierarchical
[8, 40]も試した。40layer を先に作ってから8へ集約すると、geometry は単層K=8と大差ない一方、top-level label はより abstract で representative になった。OpenAI judge でも[8, 40] level1は単層K=8より平均82.1 vs 79.4で上回り、差は「クラスタリング境界」より「上位レイヤーの意味づけ」に現れると分かった。llm-grouping-experiment-output-2026-05-25より - 2026-05-25:
LLM grouping K=8とhierarchical [8,40] level1も直接比べた。cluster 平均点では[8,40] level1が88.0とLLM grouping K=8の85.6を上回ったが、ラベル集合全体の direct judge はllm_grouping_k8勝ちだった。つまり[8,40]は代表性が強い一方、そのままだと見出しが長くなりやすく、readability では LLM grouping に分がある。次に見るべきは、集約構造は hierarchical のまま、top-level label だけを短く言い換える折衷案である。llm-grouping-experiment-output-2026-05-25より - 2026-05-25: product 含意もかなり絞れた。
K=8では LLM grouping が強かったが、K=20では従来 hierarchical の方が個別ラベル品質で勝ち、しかも LLM grouping は token を増やして品質が下がった。したがって、LLM grouping は粗い俯瞰向き、従来 hierarchical は細粒度分析向きという役割分担の方が自然かもしれない。さらに[8,40]実験で一貫性 / 網羅性が上がり区別性が少し下がったので、今後の改善焦点は clustering 本体よりaggregationにおける top-level ラベル同士の差別化と見出し短縮にある可能性が高い。llm-grouping-experiment-output-2026-05-25より - 2026-05-25: ここから先の改善を独立した実験系として回せるよう、
analysis-coreにhierarchical_label_refinementstep を追加した。merge_labellingの後ろで top-level label set をまとめて見直す step で、mode = none / setwise_refine / setwise_refine_shortを config で切り替えられる。workflow と rerun spec も更新し、以後は clustering を固定したまま「aggregation 的なラベル改善」だけを比較実験できる土台ができた。source-codeより - 2026-05-25: その新実験系で、同じ
[8,40]構造に対してnone / setwise_refine / setwise_refine_shortを比較した。cluster 平均点では baselinenoneが87.0で最も高かったが、ラベル集合全体の direct judge はsetwise_refineを 1 位とした。つまり top-level label set の改善では、個別クラスタの代表性よりも「一覧で見た時の読みやすさ」と「粒度の揃い」が別の評価軸として効いている。短くしすぎたsetwise_refine_shortは情報不足寄りだったので、次の焦点はsetwise_refineをベースに sibling 差分と長さ制約をどう両立させるかである。llm-grouping-experiment-output-2026-05-25より - 2026-05-25: さらに
setwise_refineの prompt variation としてcontrastとbalancedも試した。cluster 平均点ではcontrast 85.0 > setwise 84.4 > balanced 83.8で、個別品質の best tradeoff はcontrastに見えた。一方で direct judge はbalancedを 1 位にしており、やはり top-level label set では「情報密度」と「一覧 readability」の最適点がずれる。現時点では algorithm 改善の本線はcontrast系、UI heading 候補としてはbalanced系、という二系統で持つのが自然である。llm-grouping-experiment-output-2026-05-25より - 2026-05-25: ただしここまでの judge は OpenAI/GPT ベースであり、生成側も judge 側も同系統 LLM になっている。したがってこの順位をそのまま設計判断に使うのではなく、まず label-judge-mechanism-2026-05-25 で仕組みを説明し、label-refinement-judge-bundle-2026-05-25 を使って Claude / 人間 judge による較正を挟むべき、という段階に入った。llm-grouping-experiment-output-2026-05-25より