保险纠纷裁判文书检索与大数据分析

口径:本页不列「保险纠纷」的地域分布。上游预聚合的案由过滤不是精确匹配,而是按词/子串命中(本站已先去掉「纠纷/案件」这类通用尾缀再送出去),名字里含这个词的相近案由会被一起聚进来。2026-08-01 免 key 实测一例:把同一组条件换成 dim=cause 打回去,cause=劳动争议 在广东省 2022 年聚到的是 8 类 —— 劳动争议 47,852 + 劳动合同纠纷 6,755 + 确认劳动关系纠纷 2,274 + 人事争议 872 + 「劳动争议、人事争议」221 + 辞退争议 3 + 重大劳动安全事故 3 + 重大劳动安全事故罪 2 = 57,982 篇(末两类是刑事罪名,却聚在一个民事案由的页面里)。本次送上游的词是「保险」。上游这一次连「保险」的精确案由桶都取不到,故把分布与总量一并隐去(不是只少了分布)。注意这一支没有量过偏差,方向未知:判偏差要拿「所列桶合计 ÷ 精确桶」,而缺的正是分母,所以既不能说它被一族相近案由撑大、也不能说它被 Top-N 截断少算 —— 本页不替它认领任何一个方向,也请勿把这一格读成「被稀释」。不是上游取不到数字:校验基准取自 dim=cause 那张按件数排名的桶清单,本次它(本次返回 59 行)正常返回了,只是「保险」不在榜上,没有基准就无从校验。这张榜随省份 / 年份筛选一起重算,所以同一个案由全国在榜、加了筛选就可能掉榜 —— 是排名问题,不是有无问题,也就是说这一格重试多少次都一样,不过本页这一次一个筛选都没带(只送了案由本身,没有省份、没有年份),所以这里没有「刚加上的那个筛选」可以去掉 —— 这一格不是靠增删筛选能出来的。在动筛选之前先核写法:2026-08-09 实测 6 个案由 × 4 维(案由 / 地域 / 年份 / 法院):剥掉后缀的词干写法(民间借贷 / 买卖合同 / 机动车交通事故责任 / 物业服务合同 / 离婚 / 劳动)24/24 格全部既无分布也无总量,而补成入库原值后 24/24 格全部拿得到总量(民间借贷纠纷 9,322,422 / 买卖合同纠纷 6,621,749 / 机动车交通事故责任纠纷 3,816,328 / 物业服务合同纠纷 2,830,192 / 离婚纠纷 2,623,555 / 劳动争议 1,932,525)。这张榜的键就是入库案由原值:实测那 6 个词干 0/6 在榜、6 个原值 6/6 在榜。所以词干写法落到这一格不是名次问题,也没有「刚加上的那个筛选」可去掉 ——实测那些格子本来就没带任何省份/年份筛选;同理换一维也不管用,四个维度是一起空的。另注意本页与类案检索要的写法相反:/cases 的案由要送词干(实测 cause=民间借贷 本页 20/20 条精准,而 cause=民间借贷纠纷 只有 3/20),本页要送原值。可照抄的可用值清单:GET /api/analytics?dim=cause 的 items[].key。落进这一格也不等于库里没有「保险」的文书:它说的只是「这一维的分布口径无法校验」,不是数据量的结论。该案由在上游也取不到可校验的精确桶,故上方「文书量」不给数字 —— 本站不拿没把握的数字充数。真修在上游给案由过滤加精确匹配。自查(免 key,一行,就是本页这一次打的那条,原样可跑):curl -sS 'https://tob.wenshucha.com/api/analytics?dim=province&cause=%E4%BF%9D%E9%99%A9%E7%BA%A0%E7%BA%B7' 打回来 items 会是一个空数组([]),连 total 都不在(ok 仍是 true)—— 两样都空正是上面说的「取不到可校验的精确桶」本身,不是接口故障、也不是隧道超时,重打一样空;本页那一格不给数字,原因就是这个。看 _meta.causeExactBucketMissingReason(成因)与 _meta.causeAnchorRows(校验榜单本次返回几行)——这一支没有 _meta.causeExactTotal 与 causeApproxRatio,别去那两个键找。

口径:本页不列「保险纠纷」的裁判年份趋势。上游预聚合的案由过滤不是精确匹配,而是按词/子串命中(本站已先去掉「纠纷/案件」这类通用尾缀再送出去),名字里含这个词的相近案由会被一起聚进来。2026-08-01 免 key 实测一例:把同一组条件换成 dim=cause 打回去,cause=劳动争议 在广东省 2022 年聚到的是 8 类 —— 劳动争议 47,852 + 劳动合同纠纷 6,755 + 确认劳动关系纠纷 2,274 + 人事争议 872 + 「劳动争议、人事争议」221 + 辞退争议 3 + 重大劳动安全事故 3 + 重大劳动安全事故罪 2 = 57,982 篇(末两类是刑事罪名,却聚在一个民事案由的页面里)。本次送上游的词是「保险」。上游这一次连「保险」的精确案由桶都取不到,故把分布与总量一并隐去(不是只少了分布)。注意这一支没有量过偏差,方向未知:判偏差要拿「所列桶合计 ÷ 精确桶」,而缺的正是分母,所以既不能说它被一族相近案由撑大、也不能说它被 Top-N 截断少算 —— 本页不替它认领任何一个方向,也请勿把这一格读成「被稀释」。不是上游取不到数字:校验基准取自 dim=cause 那张按件数排名的桶清单,本次它(本次返回 59 行)正常返回了,只是「保险」不在榜上,没有基准就无从校验。这张榜随省份 / 年份筛选一起重算,所以同一个案由全国在榜、加了筛选就可能掉榜 —— 是排名问题,不是有无问题,也就是说这一格重试多少次都一样,不过本页这一次一个筛选都没带(只送了案由本身,没有省份、没有年份),所以这里没有「刚加上的那个筛选」可以去掉 —— 这一格不是靠增删筛选能出来的。在动筛选之前先核写法:2026-08-09 实测 6 个案由 × 4 维(案由 / 地域 / 年份 / 法院):剥掉后缀的词干写法(民间借贷 / 买卖合同 / 机动车交通事故责任 / 物业服务合同 / 离婚 / 劳动)24/24 格全部既无分布也无总量,而补成入库原值后 24/24 格全部拿得到总量(民间借贷纠纷 9,322,422 / 买卖合同纠纷 6,621,749 / 机动车交通事故责任纠纷 3,816,328 / 物业服务合同纠纷 2,830,192 / 离婚纠纷 2,623,555 / 劳动争议 1,932,525)。这张榜的键就是入库案由原值:实测那 6 个词干 0/6 在榜、6 个原值 6/6 在榜。所以词干写法落到这一格不是名次问题,也没有「刚加上的那个筛选」可去掉 ——实测那些格子本来就没带任何省份/年份筛选;同理换一维也不管用,四个维度是一起空的。另注意本页与类案检索要的写法相反:/cases 的案由要送词干(实测 cause=民间借贷 本页 20/20 条精准,而 cause=民间借贷纠纷 只有 3/20),本页要送原值。可照抄的可用值清单:GET /api/analytics?dim=cause 的 items[].key。落进这一格也不等于库里没有「保险」的文书:它说的只是「这一维的分布口径无法校验」,不是数据量的结论。该案由在上游也取不到可校验的精确桶,故上方「文书量」不给数字 —— 本站不拿没把握的数字充数。真修在上游给案由过滤加精确匹配。自查(免 key,一行,就是本页这一次打的那条,原样可跑):curl -sS 'https://tob.wenshucha.com/api/analytics?dim=year&cause=%E4%BF%9D%E9%99%A9%E7%BA%A0%E7%BA%B7' 打回来 items 会是一个空数组([]),连 total 都不在(ok 仍是 true)—— 两样都空正是上面说的「取不到可校验的精确桶」本身,不是接口故障、也不是隧道超时,重打一样空;本页那一格不给数字,原因就是这个。看 _meta.causeExactBucketMissingReason(成因)与 _meta.causeAnchorRows(校验榜单本次返回几行)——这一支没有 _meta.causeExactTotal 与 causeApproxRatio,别去那两个键找。