印度14亿人的官方统计 — eSankhyiki 数据门户

31 套数据集 / 汇总表开放 / 微数据须注册

来源 https://esankhyiki.mospi.gov.in发布时间: 2026-10-27最后更新: 2026-10-27 阅读 22
印度14亿人的官方统计 — eSankhyiki 数据门户

信息速览

数据集名称印度14亿人的官方统计 — eSankhyiki 数据门户
数据类型元数据,原始数据链接,文献引用
规模不适用(原因:为跨轮次全国抽样调查的集合门户,各轮样本框与规模互不相同,不存在单一受试者队列口径)
接入方式https://esankhyiki.mospi.gov.in
AI 就绪度

印度是全球最大的健康与人口数据生产国之一:每过一两年就有一轮覆盖数十万户的全国抽样调查,跑完就发布厚厚一套报告。但这些数据在国际文献里的出现频率,与它的体量严重不匹配——谈印度健康,英文论文大多引家庭健康调查(NFHS),抽样设计更复杂、覆盖主题更宽的全国抽样调查(NSS),往往只在方法学附录里出现一行。

卡住使用者的不是数据质量,而是三层门槛。发布形态上,NSS 一轮调查不是 CSV,而是门户条目加几十张分表加说明文档,字段名是 b5q1 这类缩写;口径上,同样问「看病花多少钱」,NSS 第 75 轮和 NFHS 的参照期与目标人群都不同,拼起来就是两个总体;条款上,个体级记录要单独注册申请,限制再分发。

eSankhyiki 是印度统计与计划执行部(MoSPI)为这些数据建的门户,「Sankhyiki」在印地语里是「统计」。它把调查与行政数据收进一个入口,还提供了机器可读目录与官方 MCP 服务器。本文讲三点:门户实际提供什么、NSS 各轮的跨度与主题、以及最容易踩的一脚——忽略抽样权重会系统性偏差。一屏速览见下表。

维度 内容
中文名 印度统计与计划执行部官方统计门户
英文名 eSankhyiki — MoSPI Official Statistics Data Portal
运营方 MoSPI(Ministry of Statistics and Programme Implementation),印度联邦政府
词源 Sankhyiki 为印地语「统计」
上线时间 2024 年前后,官方未在公开页面给出确切首发日期
门户条目数 官方 llms.txt 列出 23 个产品入口,另有 5 个机器可读资源条目
接口数据集数 官方 MCP 服务器 list_datasets 返回 31 套
指标规模 官方称 500 余项,服务器描述为「500+ indicators」
数据形态 汇总表(门户)+ 指标值(接口)+ 单位数据(另站申请)
核心调查 NSS 各轮、PLFS、HCES、ASI、ASUSE、TUS
健康相关 NSS 第 71 / 75 / 79 轮健康与社会消费模块、NFHS 聚合序列
取数接口 官方 MCP 服务器,JSON-RPC over HTTP,4 个工具
汇总表许可 政府公开数据实践,站点未挂 SPDX 标识
微数据许可 注册 + 使用承诺,限制再分发,部分轮次收费
主要门槛 分层多阶段设计需加权;口径跨轮断裂;个体级需申请
最容易被误当成 「一个能下载全印度调查原始记录的数据集」
本文关注点 三层门槛的成因、抽样设计的后果、接口的可接程度

§1 它要解决的具体麻烦

1.1 一个国家统计体系的痛点,不是缺数据,是数据散在几十个页面里

在 eSankhyiki 之前,印度的官方统计分散在几个互不相通的地方:MoSPI 主站的报告 PDF、各轮调查的说明文档、微数据门户的申请入口、以及各部门自己的发布页。想追一个失业率序列,要去 PLFS 的季度报告里翻表格;想追医疗支出,要去 NSS 第 75 轮的报告附录里找;想对比同一年份的消费与健康,要确认两轮调查的抽样框是不是同一版。这不是印度独有的问题,但印度的调查轮次多、改版频繁,问题被放大了。

门户的第一层价值是收敛:把 NAS、CPI、IIP、PLFS、HCES、ASI、ASUSE、TUS 以及 NSS 各轮的主题产物收进一套产品编号里,统一了入口、更新节奏与元数据描述。第二层价值更少见:它没有停在网页上,而是同步发布了 llms.txt、ai-catalog.json、.well-known/ard.json 三个机器可读目录,外加一个独立域名的 MCP 服务器。这套做法在各国统计机构里属于先行者——美国、英国、欧盟的统计门户都还没有同等程度的智能体接入层。

所以它的定位要说清楚:它是一个「统计产品目录 + 指标服务」,不是一个「数据仓库」。目录这一层做的很完整,仓库那一层(个体级原始记录)它明确交给了另一个系统。把这两层混为一谈,是使用中最常见的起点错误。

1.2 三条常见的错误期待

期待一:以为下一份就是个几百 GB 的调查原始记录包。 门户上能点到的是分析过的汇总表,行列是「邦 × 性别 × 年龄段 × 指标」,不是「一户一行」。个体级记录在 MoSPI 的微数据门户,另一个域名、另一套注册流程。想拿到能跑回归的微观数据,门户只是路标,不是终点。

期待二:以为接口能当数据库查。 官方 MCP 服务器的四个工具是「列数据集 → 拿指标清单 → 拿筛选值字典 → 取数」,取数一次返回一页,带分页元信息。它适合取一个序列、几个维度组合,不适合把某轮调查的全部记录拖下来。有人试着用分页把整张表拉走,结果拿到的是汇总表的全部单元格,仍然不是微观记录。

期待三:以为 NSS 的健康数据就是印度的健康数据。 NSS 健康模块问的是「过去 15 天有没有生病、有没有住院、花了多少钱」,样本以住户为单位,参照期很短,适合估医疗支出的分布,不适合估慢性病患病率。慢性病与儿童营养要看 NFHS,而 NFHS 是另一个体系(DHS 家族),有自己的抽样框与加权变量。两者的数放在一张图里,纵轴单位相同,含义并不相同。

1.3 它能给到的与给不到的

你的需求 它给的 够不够
印度失业率、劳动参与率的年度与季度序列 PLFS 数据集,8 项指标,年度/季度/月度三档频次 够,可直接取数
印度家庭消费与不平等(基尼系数) HCES 数据集,9 项指标,含 12 个分位段的 MPCE 够,但只到分位段层面
印度住院与非住院医疗支出 NSS 第 75 轮健康模块的 34 项指标 够用来看均值与结构
各邦医疗支出的异质性 指标可按 state_code 筛选 大体够,小邦估计不稳
个体级记录,用于回归或机器学习 门户不给,须去微数据门户注册 不够,需另走流程
疾病的临床指标(血压、血糖、HbA1c) 门户指标层没有;NFHS 只有 BMI 与贫血等自报/测量项 不够,另寻来源
与其他国家做统一口径的跨国比较 指标定义按印度问卷,未附国际映射 不够,需自行对齐
让大模型自动查统计数 官方 MCP 服务器,4 个工具,31 套数据集 很好,是本文最推荐的部分

1.4 你的处境与它能帮到的事

你的处境 它能帮你什么 下一步该做什么
写论文要一段印度医疗支出的描述性统计 NSS 第 75 轮健康模块的现成指标 直接引用并标明轮次与参照期
要给模型喂「印度就业市场」的时序特征 PLFS 的年度/季度/月度三级频次 走 MCP 取数,按 frequency_code 分流
要做中印住户消费对比 HCES 的 MPCE 与分位段 先核对两国的消费篮子定义再比
想拿微观数据做因果推断 门户只做路标 转微数据门户,预留注册与审核时间
要搭一个自动取官方统计的问答机器人 官方 MCP 服务器现成可用 按 §5.3 的最小客户端接入
想找一份「印度全量健康数据」的下载包 不存在 放弃这个设想,按主题拆分来源

1.5 一句话判断

想快速拿到印度官方口径的宏观与分组统计,它是目前最省事的入口;想拿个体级记录做建模,它只是一块写着「请到别处申请」的路牌。

1.6 不适合谁:四条边界

第一条:想要开箱即用的微观数据表。 门户的主入口是汇总表,个体级记录在另一个系统,注册、审核、下载之间有等待。如果项目排期不允许等,这个门户帮不上。它不会把单位数据放在同一个下载按钮后面。

第二条:想要临床指标而非自报指标。 NSS 与 HCES 的核心变量是自报的消费、就业与就医行为;NFHS 虽然有部分测量项(身高体重、血红蛋白),但在门户里只以聚合指标出现。需要血压、血糖、影像或检验结果的研究,这里没有对应的资源。

第三条:需要单一机构、连续随访的队列。 每轮 NSS 抽的是不同的住户(少数轮次有重叠设计),个体层面不可追踪。把两轮数据拼起来当随访用,是方法上的硬错误——两轮之间的人不是同一批人。

第四条:想用默认设置直接算出可信数字。 抽样是分层多阶段,不同邦、不同城乡的抽取概率不同,等权求平均得到的是「样本的平均」而不是「总体的平均」。不做加权处理,结果会系统性偏离,而且偏离方向可预测——城市住户被过度代表时,消费类指标会被抬高,农村贫困类指标会被压低。

§2 数据构成与规格

2.1 一个门户条目里到底装着什么

点开任何一个产品入口(例如 macroindicators?product=nss75),看到的结构大体一致:一张按指标分组的表格清单,若干张跨年份或跨邦的分表,一组筛选项(年份、邦、城乡、性别、社会群体),以及一份说明文档的链接。表格本身是分析后的产物,单元格里是数值,行列头是维度标签。维度标签常有缩写:PS+SS 指主要活动与次要活动合并口径,UR 指失业率,MPCE 指月人均消费支出。

这套结构对人是友好的,对程序不友好——页面靠 JavaScript 渲染,静态抓取只能拿到空壳(这一点在 §7.3 展开)。所以程序化接入的正路不是爬页面,而是走官方 MCP 服务器,它把同样的内容换成了结构化的 JSON。门户的 llms.txt 自己也这么建议:优先用 MCP 接口获取最新数据,而不是依赖网页抓取或训练数据里的旧值。

理解这一点的实际意义是:「门户」和「接口」是同一个数据的两副面孔,门户给的是人看的切片,接口给的是程序取的值。两者内容一致,粒度也一致——都是汇总层面,都不含个体记录。

2.2 字段/记录的完整字典

下面这张表按接口返回的字段整理,覆盖维度字段与值字段。字段名取自官方 MCP 的实际响应,含义按官方描述与印度统计惯例补注。

字段 所属层 取值示例 含义 使用注意
dataset 请求参数 PLFS、HCES、NSS71 数据集代码,共 31 个 同一主题可能有多个代码,如 NSS79 与 NSS79C
indicator_code 请求参数 3 指标在该数据集内的编号 编号跨数据集不通用,同号可能是完全不同的指标
frequency_code 请求参数 1 / 2 / 3 年度 / 季度 / 月度 仅 PLFS、ASUSE 等支持多频次
survey_code 请求参数 1 / 2 同一轮内的模块切分 NSS76、NSS79 等多模块轮次必填
module 请求参数 land_livestock、aidis 模块名,部分数据集用名不用号 编号区间重叠时用它消歧
state_code 维度 99 = All India,1 = 安得拉邦 邦/中央直辖区代码 不同数据集的全区代码不一致:NSS74 用 37,NSS72 用 36
sector 维度 rural / urban / combined 城乡 合并口径的字段名在响应里是 rural + urban
gender 维度 male / female / person 性别 person 为男女合计
age / AgeGroup 维度 15 years and above 年龄段 字段名大小写在不同数据集里不一致
social_category 维度 scheduled tribe、other backward class 社会群体 对应表列种姓/表列部落/其他落后阶层/其他
religion 维度 Hinduism、Islam 宗教 仅部分指标提供
education 维度 7 = graduate 教育程度代码 代码表随数据集变化
year 维度 2022、2023-24 参照年 混用日历年与财政年/农业年
year_type 维度 Calendar Year、Agriculture Year 年份类型 PLFS 同时提供两种,取值不同
quarter 维度 Q1 季度 季度序列的年度汇总不可直接比较
month 维度 1–12 月 月度序列起始于近年
weekly_status 维度 PS+SS 劳动力调查的参照期口径 与「当前周」「通常状态」口径不可混用
indicator 返回值 UR (Unemployment Rate, in per cent) 指标全称 英文全称常用于核对
value 返回值 "1.9" 指标值 以字符串返回,需显式转数值
unit 返回值 %、Rs. 单位 单位随指标变化,不可假定
meta_data 返回值 totalRecords、totalPages 分页元信息 必须读,否则只拿到第一页

这张表里最该记住的是两行:indicator_code 跨数据集不通用,value 是字符串。前者决定你不可能凭直觉写参数,必须两步走——先取指标清单;后者决定任何批量处理前都要先做类型转换,否则排序会按字典序走,"9" 会排在 "10" 后面。

2.3 一条记录的完整解剖

下面是从官方 MCP 服务器真实取回的一条记录(PLFS,失业率,2022 日历年,全印,男性,农村,表列部落),原样保留字段名。

{
  "year_type": "Calendar Year",
  "year": "2022",
  "frequency": "Annually",
  "indicator": "UR (Unemployment Rate, in per cent)",
  "state": "All India",
  "gender": "male",
  "sector": "rural",
  "AgeGroup": "15 years and above",
  "weekly_status": "PS+SS",
  "religion": "all",
  "socialGroup": "scheduled tribe",
  "General_Education": "all",
  "quarter": null,
  "month": null,
  "value": "1.9",
  "unit": "%"
}

逐段读这条记录:weekly_status: PS+SS 说明这是把主要活动(Principal Status)与次要活动(Subsidiary Status)合并计算的劳动力状态口径,换句话说,一个人在参照周里只要有少量劳动,就会被计入劳动力;换成只看主要活动的口径,同一批人的失业率会更高。AgeGroup 与 All ages 在同一批返回里成对出现,且数值完全相同(都是 1.9),说明这个指标对年龄并不敏感,或者官方在不同年龄分层上用了同一估计——这一点官方没解释,使用时应以 15 years and above 这档为准。

socialGroup 与 religion 同时出现,且 religion 为 all,说明这一行是社会群体维度的切片,宗教维度被压平了。想同时切两个维度,需要另取一组。value 为字符串 "1.9",unit 为 %——这两个字段必须成对读取,单看数值会把「1.9%」当成「1.9 人」。

最后是 quarter 与 month 全为 null:年度记录在这两个字段上留空,而不是省略字段。这意味着 CSV 化之后会出现空列,用 dropna 一刀切会把这些行误删。

2.4 31 套数据集的结构分布

官方 MCP 返回的数据集清单可按主题分组。下表按主题归类,列出每组的代表数据集与官方描述的规模。

主题组 代表代码 品种数 指标规模(官方描述) 主要维度
劳动力与就业 PLFS 1 8 项,三档频次 邦、城乡、性别、年龄、教育、宗教、社会群体
消费、贫困与时间使用 HCES、TUS 2 9 项 + 41 项 分位段、户主类型、社会群体
产业与企业 ASI、ASUSE、NSS73、NSS74、EC 5 57 + 50 + 6 + 21 + 3 NIC 行业、企业类型、邦
价格与产出指数 CPI、WPI、IIP、ISP、CPIALRL 5 商品层级 600+ 与 1000+ 商品层级、基年、邦
国民核算与对外 NAS、RBI 2 34 + 39 邦、账户类型、币种
NSS 社会专题轮次 NSS71/72/72T/75E/76/77/78/79/80 9 11 至 46 项不等 模块、邦、社会群体
健康与人口 NFHS、GENDER 2 21 + 154 邦、年龄、性别
教育 AISHE、UDISE 2 9 + 46 邦、管理层级
能源与环境 ENERGY、ENVSTATS、MNRE 3 2 + 126 + 5 邦、行业、月份
门户与元资源 portal、ARD、llms.txt、MCP 卡片 4 无指标 —

这张表最有信息量的一行是「NSS 社会专题轮次」:九套数据集分属九个不同轮次,每轮一个入口。这不是设计缺陷,而是印度调查体系的真实形态——NSS 按轮次滚动,每轮换一个主题,第 71 轮做社会消费(教育 + 健康),第 75 轮做健康与教育,第 76 轮做残疾与住房饮水,第 77 轮做农业家庭与债务投资,第 78 轮做多重指标(生活条件),第 79 轮做综合年度模块(CAMS)与 AYUSH,第 80 轮做电信与教育。

2.5 与同类资源的字段差异

把 eSankhyiki 与三类常见替代源放在一起比,差异集中在字段的语义密度上。

资源 记录粒度 维度字段 权重字段 单位说明 适合的用途
eSankhyiki 门户汇总表 单元格 邦、城乡、性别、年龄 无(已加权) 表头注明 引用官方口径
eSankhyiki MCP 接口 标量记录 同上,带代码 无(已加权) unit 字段 自动取数与看板
NSS 单位数据(微数据门户) 住户/个体 全套问卷变量 有,随附 需读说明文档 回归与建模
NFHS(DHS 体系) 住户/个体 生殖健康为主 有,随附 需读说明文档 妇幼与营养
World Bank / UN 数据库 国年 国家、年 无 统一 跨国比较

最关键的一列是「权重字段」。门户层没有,因为它给的是已经加权后的估计;单位数据层有,而且必须用。这条差异决定了同一个研究在两个层面上做,得到的是两套数——不一致不是错误,是加权与未加权的区别。

§3 它的身份:一个国家统计机构的对外窗口

3.1 MoSPI 与 NSS:谁在做调查,谁在发布

要理解这个门户,得先分清三个机构名词。MoSPI 是印度联邦政府的统计与计划执行部,负责国家统计体系的组织与协调。国家统计办公室(NSO)是 MoSPI 下属的执行机构。全国抽样调查(NSS)是 NSO 主持的连续住户调查体系,按轮次滚动,每轮换主题,从 1950 年代起一直做到现在。

eSankhyiki 是这套体系在 2020 年代中期做的对外窗口。它不是新的数据来源,而是既有产品的重新编排——把散落在报告 PDF 与旧版网站里的表格,收进一套带产品编号的页面,再补上一套机器可读接口。这个定位很重要:门户上出现的每一个数,都可以在 MoSPI 的正式报告里找到对应表格;门户的价值在可达性,不在新增信息。

3.2 命名的含义:「Sankhyiki」不止是一个品牌词

「Sankhyiki」(印地语 संख्यिकी)直译是「统计」,更贴合语境的译法是「统计学之物」。选这个词而不是英文 statistics,是一个有意的姿态:印度官方统计长期以英文发布为主,本地语言版本往往是转载。门户用一个印地语词做域名与品牌,等于在宣示这是「国家的统计」而非「某个部门的英文报表」。

这个姿态有实际后果。门户的页面标题、元描述都是英文,但品牌名、导航与部分栏目说明保留印地语词根;llms.txt 的开篇第一句也是先给全称再给代码。对使用者的影响是:检索这个资源时,用 eSankhyiki 比用 MoSPI statistics portal 更容易命中官方页面,因为后者会混进第三方镜像与旧版站点。

3.3 一个门户,三种时间尺度

看它的更新节奏,会发现三种时间尺度并存。最慢的是轮次级:NSS 的一轮调查从启动到发布报告要几年,发布后基本上不再变,除非修订。居中的是年度级:PLFS、ASI、ASUSE 的年度结果按固定周期发布,年末年初各一批。最快的是月度级:CPI、IIP、WPI 按月发布,MCP 接口的 frequency_code 里 3 就是月度。

这三种尺度混在同一个产品目录里,意味着「数据是最新的吗」这个问题没有统一答案。正确问法是「我说的是哪个数据集、哪一档频次、哪一个参照期」。接口的响应里带 year、quarter、month,就是为了回答这个问题;不看这三个字段就拿数,等于不知道自己在看哪段时间。

§4 质量控制:它做得好的和做得勉强的

4.1 做得好的三件事

第一件是把机器可读目录当一等公民。 大多数国家统计门户的机器接入层是要么没有,要么藏在开放数据平台的角落里。这个门户把 llms.txt、ai-catalog.json、ARD 清单与 MCP 服务器并列写在站点说明里,还专门写了一节「AI and Agent Access」,明确建议智能体优先走 MCP 而不是爬页面。这不是技术炫技,是省事:CORS、分页、字段命名这些琐碎问题,官方替你处理了。

第二件是把筛选值字典单独暴露。 接口的第二步是 get_metadata,返回的是「这个指标下哪些年份、哪些邦、哪些性别取值是合法的」。这一步看似多余,实则解决了最关键的一类错误——参数猜测。有了它,你不必从报告附录里逐条抄代码表,也不必担心把 state_code=99 当成某个具体邦。

第三件是保留了大量原始标签。 返回的记录里能看到 PS+SS、scheduled tribe、other backward class 这类原样保留的分类标签,而不是全部翻译成通用的「其他」。这对研究印度社会结构的人来说很重要,因为种姓类别是印度社会分层分析的核心变量,抹平了就失去意义。

4.2 做得勉强的三件事

第一件是粒度。 接口给的是单元格,不是记录。同一个指标在 8 个邦、2 个性别、4 个年龄段上交叉,就是一张 64 行的表,但行与行之间是独立估计,不带协方差。想做显著性检验或区间估计,这些数不够用。

第二件是权重不可见。 门户层的数已经加权,但你拿不到权重的具体形式,也拿不到标准误。这意味着只能引用,不能复核。对于需要声明不确定性的研究,这是硬约束。

第三件是跨数据集的一致性。 全印代码在同一家族的接口里是 99,在较早的 NSS74 里是 37,在 NSS72 里是 36。字段名也时有出入:state 与 state_code 并存,age 与 AgeGroup 大小写不一。这些都是在集成时才暴露的坑,官方描述里没有集中说明。

4.3 案例:第 75 轮健康调查里的「一次住院花了多少钱」

用一个具体案例把上面这些抽象说法落下来。NSS 第 75 轮(2017–18 年)的健康模块,是研究印度医疗支出的主要来源之一,门户上有 34 项指标。其中「住院病例每十万人中的例数」与「住院医疗支出」是两项最常被引用的指标。

假设你要回答一个问题:印度农村和城市的一次住院,自付支出差多少。在门户上,你可以直接取到这两个指标按城乡、邦、社会群体切片的均值,这些数已经加权,可以直接引用。但如果你的问题是「控制了年龄和收入之后,差额还剩多少」,门户给不了——那需要个体级记录与回归。

再假设你要把这个差额与 NFHS 第 4 轮(2015–16 年)的住院数据对照。表面上看,两轮年份接近、都是全国调查、都问住院,可以并排。实际上不能:NSS 的住院参照期是「过去 365 天」,NFHS 问的是「过去 3 年内的最近一次」,两条时间轴的回忆偏差不同;NSS 的支出问的是整套住院费用,NFHS 的问法更接近单项。把两者的均值放进同一张图,看图的人会以为是同一现象的两个估计,其实是两个问题的两个答案。§4.3 的案例在下文还会再出现两次,分别落在取数方法(§5.4)与偏差清单(§7.3)里:前者说明官方已经把「住院支出」算好、你只需取;后者说明哪些算法会让这个数变大或变小。

4.4 一份指标从调查到门户的路径

把一份数据从现场走到门户的路径画出来,能看清每一层加了什么、丢了什么。

环节 产出 新增了什么 丢掉了什么
抽样设计 样本框与层标识 分层、多阶段、PPS 抽样 —
入户调查 问卷原答 住户与个体变量 —
数据清理 单位数据文件 权重、层、PSU 标识 可识别信息
加权汇总 估计表 按维度交叉的估计值 个案、方差、协方差
门户发布 产品条目 统一入口、可视化 权重与标准误
接口发布 JSON 标量 机器可读、分页 跨维度关联

这张表最重要的一行是「加权汇总」:从这一步开始,个案消失了,取而代之的是估计值。研究者在门户层能做的,是在既有估计上再分组或再比较;能做的边界,就是官方已经切好的那些维度。想越过这条边界,只能回到第三行的单位数据。

§5 怎么拿到:从浏览器点击到代码取数

5.1 三条取数路径的分工

先分清三条路,再决定走哪条。路径一,浏览器直看:打开产品页,用筛选器选年份、邦、人群,直接看表、看图、下表格。适合快速的描述性引用。路径二,官方 MCP 接口:四个工具串成一条流水线,适合批量取序列、做看板、接模型。路径三,微数据门户:注册、申请、下载单位数据文件,适合建模。三条路的入口不同,数据粒度也不同,混用会出错。

判断走哪条路的标准很简单:如果答案是「引用一个官方数字」,走路径一或二;如果答案是「算一个官方没算的数」,走路径三。

5.2 路径一:在门户上把一张表找出来

门户的地址结构是 macroindicators?product=<代码>,代码与 llms.txt 的链接一一对应。下表把最常用的几个列出来,方便直接拼地址。

主题 product 代码 页面标题
定期劳动力调查 plfs Periodic Labour Force Survey
家庭消费支出 hces Household Consumption Expenditure Survey
健康(第 75 轮) nss75 Health in India (NSS 75th Round)
教育(第 75 轮) nss75e Household Social Consumption on Education
饮水与住房(第 76 轮) nss76 Drinking Water, Sanitation, Hygiene and Housing
残疾(第 76 轮) nss76c Persons with Disabilities in India
多重指标(第 78 轮) nss78 Multiple Indicator Survey
综合模块 CAMS(第 79 轮) nss79c Comprehensive Annual Modular Survey
AYUSH(第 79 轮) nss79 Survey on AYUSH
农业家庭(第 77 轮) nss77 Situation Assessment of Agricultural Households
债务投资(第 77 轮) nss77a All India Debt & Investment Survey

在浏览器里打开这些页面后,先看右上角的年份选择器,再看表头注明的基年与版本说明。这两个信息决定了你取到的是哪一版口径,也决定了能不能和别处的数对齐。

5.3 路径二:三行代码接上官方 MCP 服务器

官方 MCP 服务器是标准的 JSON-RPC over HTTP,端点为 https://mcp.mospi.gov.in/mcp。下面的脚本只依赖 Python 标准库,可以直接跑。

#-- 最小 MCP 客户端:初始化与工具调用
import json, urllib.request

URL = "https://mcp.mospi.gov.in/mcp"
HDR = {
    "Content-Type": "application/json",
    "Accept": "application/json, text/event-stream",
    "MCP-Protocol-Version": "2025-06-18",
}

def rpc(payload):
    req = urllib.request.Request(URL, data=json.dumps(payload).encode(),
                                 headers=HDR, method="POST")
    with urllib.request.urlopen(req, timeout=60) as resp:
        raw = resp.read().decode("utf-8")
    #-- 响应是 SSE 流,逐行找 data: 开头的 JSON
    for line in raw.splitlines():
        if line.startswith("data: "):
            return json.loads(line[6:])
    raise RuntimeError("no data frame in response")

def call_tool(name, args, rid):
    out = rpc({"jsonrpc": "2.0", "id": rid, "method": "tools/call",
               "params": {"name": name, "arguments": args}})
    return json.loads(out["result"]["content"][0]["text"])

datasets = call_tool("list_datasets", {}, 1)
print(datasets["total_datasets"])          #-- 31
print(list(datasets["datasets"])[:5])      #-- PLFS, CPI, IIP, ISP, ASI

这段脚本跑通后,第一步的问题就解决了——你知道官方到底有哪几套数据集。注意 list_datasets 不接受任何参数,传了会返回参数校验错误,这一点是官方 schema 写的(additionalProperties: false)。

5.4 路径二续:先查指标,再查筛选值,最后取数

官方把取数拆成三步,顺序不能省。下面这段接着上文的 call_tool 继续,走的是取数流水线的标准形态:先拿指标清单,再拿筛选值字典,最后取数。§4.3 的案例问的是住院支出,这里改用同一路径上的失业率作示范,因为它的维度最全(邦、城乡、性别、年龄、教育、宗教、社会群体七层),最能体现「同一指标切出上千行」的样子。

#-- 第一步:拿某个数据集的指标清单
inds = call_tool("get_indicators", {"dataset": "PLFS"}, 2)
annual = inds["indicators_by_frequency"]["frequency_code_1_Annual"]
for i in annual:
    print(i["indicator_code"], i["description"][:60])
#-- 1 LFPR / 2 WPR / 3 UR / 4 分布 / 5 就业条件 / 6-8 三类收入

#-- 第二步:拿筛选值字典,确认合法取值
meta = call_tool("get_metadata",
                 {"dataset": "PLFS", "indicator_code": 3}, 3)
fv = meta["filter_values"]["data"]
print([s["state_code"] for s in fv["state"]][:5])   #-- 99 是全印
print([y["year"] for y in fv["year"]][:4])          #-- 2025 2024 2023-24 2023

#-- 第三步:取数,所有筛选参数都放进 filters
data = call_tool("get_data",
                 {"dataset": "PLFS",
                  "filters": {"indicator_code": 3, "frequency_code": 1,
                              "state_code": 99, "limit": 5}}, 4)
print(data["meta_data"])        #-- totalRecords / totalPages
for r in data["data"][:3]:
    print(r["year"], r["gender"], r["sector"], r["value"], r["unit"])

三步里最容易出错的是第二步被跳过。indicator_code=3 在 PLFS 里是失业率,在别的数据集里可能是完全无关的指标;state_code=99 在 PLFS 里是全印,在 NSS72 里未必。官方 schema 的说明写得很直白:这些代码「无法从参数名推断或猜测」。

5.5 泛化取数:把分页拉完

单次请求返回一页。要做完整序列,得按 totalPages 循环。下面的函数把某个数据集在某组固定筛选下的全部记录拉下来。

#-- 按分页拉完一个筛选组合下的全部记录
def fetch_all(ds, filters, page_size=100):
    rows, page = [], 1
    while True:
        f = dict(filters)
        f["limit"] = page_size
        f["page"] = page
        r = call_tool("get_data", {"dataset": ds, "filters": f}, 100 + page)
        rows.extend(r["data"])
        md = r["meta_data"]
        if page >= md["totalPages"]:
            break
        page += 1
    return rows, md["totalRecords"]

rows, total = fetch_all("PLFS", {"indicator_code": 3, "frequency_code": 1})
print(len(rows), total)

这段的价值在于它把「一页五条」变成「全部记录」,同时保留官方给的 totalRecords 做对账。如果拉回来的行数与 totalRecords 不符,说明中途有筛选值非法被静默丢弃,应当回查筛选字典。

5.6 把结果落成表:一条最小可用流程

取到数之后,第一步不是分析,是把字段摊平并做类型转换。下面这段只做两件事:把 value 转成浮点,把维度字段拼成键。

#-- 落表前的清洗:类型转换 + 维度拼接
def to_rows(raw):
    out = []
    for r in raw:
        out.append({
            "key": "|".join([str(r.get("year")), str(r.get("gender")),
                             str(r.get("sector")), str(r.get("AgeGroup"))]),
            "indicator": r.get("indicator"),
            "value": float(r["value"]) if r.get("value") not in (None, "") else None,
            "unit": r.get("unit"),
        })
    return out

clean = to_rows(rows)
print(len(clean), clean[0])

这段代码只有二十行,但避开了两个常见错误:把 "1.9" 当字符串排序,以及把 null 的季度字段当成有效值。落表之后再做任何聚合,都要先确认自己是在「官方已加权的估计」之上再聚合,这时的「平均」是估计值的平均,不是总体的平均。

5.7 路径三:个体级数据该去哪里申请

个体级记录不在门户上,这条路要说清楚,否则前面几节会给人一个错误印象——以为拿到了接口就等于拿到了数据。可行路径分四步:先是确认目标轮次与模块(例如第 75 轮的健康模块),再在 MoSPI 的微数据门户注册账号,然后按轮次提交申请并写明研究用途,通过后下载单位数据文件与说明文档。

申请环节有三个容易忽略的点。第一,说明文档比数据文件更重要:单位数据的字段是问卷变量名,含义、取值编码与缺失规则全在文档里,没有文档的文件基本不可用。第二,权重与层标识是随文件给的独立变量,不是内置属性,分析时必须显式引用。第三,条款限制再分发,意味着不能把文件转给同事,也不能把它上传到公开仓库或模型训练集;合作方的处理方式是让每位合作者各自申请。

这条路径的代价是时间。注册与审核不以天计,若项目排期紧,应当先确认能否用门户层的汇总值回答研究问题——相当一部分描述性研究并不需要个体记录,用接口取数几天就能完成。

下面这段代码用来核对「申请到的到底是哪一轮」,读的是单位数据文件附带的说明文档元信息。

#-- 核对单位数据文件的轮次与模块标识(示意:从随附说明里抽取)
import re

def probe_round(meta_path):
    txt = open(meta_path, encoding="utf-8", errors="ignore").read()
    pat = {
        "round": r"(?:Round|round)\s*[:\-]?\s*(\d{2}[a-zA-Z]?)",
        "schedule": r"Schedule\s*[:\-]?\s*(\d+(?:\.\d+)?)",
        "period": r"(\d{4})\s*[-–]\s*(\d{4})",
    }
    out = {}
    for k, p in pat.items():
        m = re.search(p, txt)
        out[k] = m.groups() if m else None
    return out

print(probe_round("NSS75_Health_Readme.txt"))
#-- 期望看到 round='75'、schedule='25.0'、period=('2017','2018')

这段代码不依赖网络,作用是把「文件名与内容对不上」这类事故挡在分析之前——同一个目录里放两轮文件、或者把 71 轮的文件命名成 75 轮,是合作项目里常见的事故。

§6 与库内条目的关系

6.1 关系图谱

这个门户在库内的位置,是「印度官方统计的入口层」。它同时与三类词条相邻:印度本地的健康与数字基础设施条目、国际住户调查家族条目、以及跨国统计聚合条目。

相邻词条类型 代表条目 与本文的关系 怎么配合用
印度健康调查 NFHS 系列词条 同属印度官方调查,但抽样框与主题不同 妇幼营养看 NFHS,医疗支出看 NSS
印度数字健康 ABDM 词条 前者是健康信息系统,后者是统计产物 系统侧看 ABDM,指标侧看本文
跨国住户调查 DHS 系列词条 DHS 与 NFHS 同源,NSS 不在其中 要跨国比较优先用 DHS
国际聚合库 World Bank、UN 数据条目 从各国官方统计再加工而来 印度分项值以本文为准,跨国比用聚合库
劳动力统计 ILO 数据库条目 从 PLFS 等再加工 印度单国看 PLFS,跨国看 ILO

这张图的核心判断是:本文处在上游,聚合库处在下游。下游的便利在于统一口径,代价是丢失印度特有的分类(种姓类别、社会群体、邦级细分)。研究印度本身时回到上游,做跨国比较时用下游。

6.2 检索路径

按使用者可能的需求,给出四条检索路径。

你想要的 检索词 落点
印度医疗支出全国数据 NSS 75th round health、India out-of-pocket 门户 nss75 页 + Europe PMC 论文
印度失业率季度序列 PLFS quarterly、India unemployment rate 门户 plfs 页 + MCP PLFS 数据集
印度消费不平等 HCES、India Gini consumption 门户 hces 页,第 9 项指标
印度妇幼健康 NFHS、India maternal health NFHS 官方站 + 本文 NFHS 聚合序列

第一条与第二条是使用频率最高的。它们的共同点是「官方已经在算,你只要取」,适合用接口;第三条的基尼系数官方也算了,但只到分位段层面,想做分解研究还得回到单位数据。

§7 质量评估与局限性

7.0 阅读本节前的一个前置校正

先把一个常见误判拆掉:很多人把「官方发布」等同于「可以直接拿来算」。在印度这个问题上,这两个判断要分开。官方的每一个汇总数都是加权后的估计,它的可信度取决于抽样设计与响应率;你从门户拿到的是估计值,不是观测值。一旦在这个层面做二次计算(把两个邦的数相加、把两个轮次的数相减),误差的传播与协方差就不在你的控制之内了。

第二层误判是把「没有标准误」理解为「没有不确定性」。门户与接口都不随表给出方差估计,这不是说估计没有方差,而是说官方把它留在了发布层的技术报告里。引用时如果需要说明区间,只能回查原始报告的处理,不能自己臆造一个。

把这两层校正放在前面,下面五个维度的评分才有意义——它们评的是「这个门户作为入口有多好用」,不是「印度统计的估计有多准」。

7.1 五维评分

评分采用一至五分制,标准是本库对数据资源的通用维度,说明写的是扣分理由而不是表扬。

维度 评分 评分理由
可得性 4 汇总层完全开放且接口免费;个体层需注册,扣一分
可理解性 3 维度标签清楚,但代码表分散、全印代码不统一
可互操作性 4 官方 MCP + ARD + llms.txt,接模型很省事;缺国际编码映射
覆盖度 4 31 套数据集横跨经济、社会、健康;临床指标缺席
可复核性 2 无标准误、无权重形态暴露,门户层无法复核估计的不确定性

合计 17 分(满分 25)。这一分数在库内属于「入口优秀、深用受限」的类型。扣分最重的两项分别是可复核性与可理解性,都指向同一件事:它对「引用的人」友好,对「重算的人」不友好。

7.2 质量的核心在抽样设计,不在平台

门户的好坏可以打分,数据的好坏要回到抽样。NSS 的设计是分层多阶段:以人口普查的行政单元为抽样框,按邦与城乡分层,第一阶段按人口规模成比例抽村或街区(PPS),第二阶段在抽中单元内系统抽住户。这个设计的目标是让每个住户有已知的入样概率,从而可以用权重还原总体。

设计带来的三个后果必须记住。其一,抽样概率不等:城市住户、大邦住户与小邦住户的入样概率不同,等权求和会偏向抽样率高的群体。其二,设计效应大于一:同一批样本量,分层多阶段的有效样本量小于简单随机抽样,方差会放大,通常放大一点五到三倍(具体随指标变化)。其三,小域估计不稳:小邦、小社会群体、细分年龄段的样本量可能只有几十人,估计值的摆动很大,官方通常不单列这些格。

这三条不是本文的推测,是抽样设计的直接推论。任何在单位数据上做分析的人,都必须同时使用权重变量与层/PSU 标识,否则算出来的标准差会偏小,显著性会被高估。

7.3 已知的、可枚举的偏差

把已知的偏差按成因归类,逐条写清后果。

偏差 成因 后果 应对
加权缺失偏差 等权求和替代加权估计 城市化程度高时消费被高估,农村收入被低估 必须用权重
设计效应低估 按简单随机抽样算方差 置信区间过窄,显著性虚高 用层与 PSU 做方差估计
口径断裂 NSS 与 NFHS 问法不同 两套数并列会造成「同一现象两个估计」的错觉 只做趋势对照,不做合并
年份类型混用 日历年与农业年并存 同一指标错位一年 认准 year_type 字段
回忆期偏差 参照期长短不同(15 天/365 天/3 年) 短期参照低估慢性病负担,长期参照高估就医次数 按参照期分组解读
小域不稳定 细分格样本量过小 邦级或群体级极值不可信 设最小样本量门槛
全印代码不一致 各数据集历史沿用不同编码 拼接时全印行被重复计入 先做代码映射表
单位混淆 人均/户均、月/年混用 量级差十倍量级 逐项核对 unit

表中第一行与第三行,是 §4.3 的案例里已经定过性的两支主线。第一行是加权缺失——若研究者把单位数据的所有住户等权求均值,得到的住院支出会低于官方估计,因为高消费城市的住户入样概率低、需要更大的权重。第三行是口径断裂——把 NSS 与 NFHS 并排比较时的错觉,两者不是同一问题的两次测量。

7.4 外部验证矩阵

门户的数能不能被外部独立印证,是判断其可靠性的另一条线。下面按四个来源做交叉核对,逐项写清能核对到什么程度。

验证来源 能核对的 核对不到 结论
MoSPI 正式报告 PDF 每个指标都应能找到对应表 门户的整理是否与原表一致 以报告为准,门户为索引
Europe PMC 论文 指标的引用方式与常见取值 论文自身的加权处理是否规范 论文可作使用范例
国际聚合库(世行等) 国年层面的趋势方向 印度的邦级与群体级细分 趋势可对,细节不可
微数据门户的单位数据 汇总层估计是否可由单位数据复现 官方的权重构造细节 复现可行但需说明文档

这条矩阵的实际用法是:引用一个数之前,至少走两条来源。一条是门户或接口(拿到值),一条是正式报告或论文(确认口径)。只走一条,等于把「平台整理是否正确」这个未知量当成了零。

7.4b DAIMS 数据集质量检查表

DAIMS 是数据集进入分析流程前的通用质量清单,共 24 项。下表按该口径逐项判定,✅ 表示满足,⚠️ 表示部分满足,说明列写的是不满足的具体位置。

# 检查项 状态 说明
1 宽格式可用 ✅ 接口一次返回完整维度列,可直接转宽表
2 唯一标识 ⚠️ 无全局主键,需由数据集名 + 指标号 + 维度组合拼键
3 特殊字符处理 ⚠️ 指标描述含括号与斜杠,CSV 导出需转义
4 重复行控制 ⚠️ 同一年龄段出现重复行(如 15+ 与 All ages 同值),需去重
5 缺失值编码 ⚠️ quarter/month 以 null 表示不适用,与真缺失混同
6 标签标识明确 ✅ 维度标签原样保留,含 PS+SS、scheduled tribe 等
7 罕见类分组 ⚠️ 小邦与小社会群体样本过少,官方未合并也未提示
8 偏倚评估 ⚠️ 抽样偏倚需自行评估,官方页面不提供评估说明
9 数据字典 ✅ get_indicators + get_metadata 构成两级字典
10 信息性缺失解释 ⚠️ 年龄重复与 All India 代码差异均未集中解释
11 设备记录完整性 ✅ 不涉及设备采集,此项按「无设备依赖」记为满足
12 共线性提示 ⚠️ WPR、LFPR、UR 三者线性相关,联合入模需自检
13 编码映射 ⚠️ 邦代码与国际行政区划无官方映射表
14 时间戳处理 ⚠️ 日历年与农业年并存,year_type 必读
15 划分建议 ✅ 按轮次或按邦做外部验证划分是可行的,见 §7.4
16 泄漏讨论 ⚠️ 汇总值由全体本加权产生,跨轮合并时存在口径泄漏
17 标签分布 ✅ 指标按维度分组的取值可在接口层逐项取回
18 测量偏倚 ⚠️ 自报消费与就医行为,回忆期偏倚不可消除
19 外部验证建议 ✅ §7.4 给出四源交叉验证矩阵
20 版本记录 ⚠️ 接口实时更新,无版本号;须自行记录访问时间
21 预处理脚本 ✅ §5.6 与 §9.2 提供可运行清洗与落表脚本
22 合规要求 ⚠️ 汇总层零门槛,个体层需注册,两层规则未在同一页说明
23 多模态对齐 ⚠️ 门户含图表与表格两种呈现,但无跨模态对齐键
24 去标识化 ✅ 门户与接口层均为聚合估计,不含个体记录

DAIMS 评分:16.5 / 24(9 项 ✅ 计 9,15 项 ⚠️ 各计 0.5 得 7.5)。分数不是评价数据好坏,而是说明它作为「分析就绪表」离可用还差几道工序——这些工序基本都能靠脚本补上,唯一补不了的是第 18 项的回忆期偏倚,那是设计层面的。

7.5 它为何能持续:因为它把发布成本从「做报告」变成了「维护接口」

统计门户多数活不长,原因往往是维护成本:每次发布都要重新做一套网页、一套图表、一套下载包,做几次之后就没人维护了。这个门户的选择是反过来的——先定义一套数据集与指标的元结构,再让门户、接口、机器可读目录都从这套结构生成。同一份内容,网页与 JSON 是两副面孔,维护一次两边都更新。

这套做法让它有了持续的可能:新增一轮调查,只要按既有结构入库,入口自动出现;修订一个指标,接口与页面同步变。代价是结构刚性——所有内容必须先被塞进「数据集 × 指标 × 维度」这个三元框架,塞不进去的东西(比如整份问卷、技术报告正文)只能外链。这也是为什么个体级数据至今不在门户里:它不是「一个指标」,塞不进这个框架。

§8 生态位与历史

8.1 从纸质报告到门户的四段路

印度官方统计的发布方式,大致走过四段路。第一段是报告时代:每轮调查发布一本印刷报告,表格附在附录,数据以纸质流传。第二段是 PDF 时代:报告上了网站,但仍是整本 PDF,表格要靠人工抄录或转换。第三段是开放数据平台时代:data.gov.in 一类平台上线,开始提供可下载的表格文件,但主题分散、版本不清。第四段就是门户时代:按产品编排、统一元数据、带接口。

eSankhyiki 属于第四段。它的特殊性不在于「有个网站」,而在于它把接口与机器可读目录做成了与网页并列的一等产品。这个选择在 2024 年前后出现,正好赶上统计机构开始考虑「数据要被模型读取」这件事。

8.2 与 DHS/NFHS 的分工

在印度的健康数据版图里,NFHS 与国际 DHS 项目同源,问卷、抽样与发布流程都按 DHS 的规范走,因此在国际期刊里的可见度高得多。NSS 的健康模块则是印度本土体系的产物,问卷按印度的医疗体系设计(公立/私立、住院/门诊、AYUSH 与传统医学),发布以报告为主,国际可见度低。

这个分工造成了一个长期后果:国际研究谈到印度健康时,默认引用 NFHS 体系,而 NSS 的医疗支出数据虽然更贴近「钱从谁口袋里出」这个问题,却很少被纳入比较研究。这不是数据质量问题,是发布体系与学术惯性的问题。本文的存在,部分就是为了把这个入口补上。

8.3 在各国统计门户里的位置

把几个国家的统计门户放在一起看,能看清这个门户的位置。

门户 国家/机构 接口形态 机器可读目录 个体数据入口
eSankhyiki 印度 MoSPI 官方 MCP 服务器 有,三重 另站注册
data.gov 美国 API 为主 有 部分开放
ONS 数据服务 英国 API 为主 部分有 需申请
Eurostat 欧盟 API 为主 有 需申请
国家统计局数据平台 中国 以网页表格为主 有限 需申请

这一栏里,印度的独特之处是直接上了 MCP 服务器——一种为大模型设计的接口。多数国家的做法是先做 REST API,再等生态跟上;印度这一步走得更靠前,也意味着它的接口设计(四个工具、三步取数)更多考虑的是「让模型能自己找对」,而不是「让开发者能拼装」。

8.4 一个平台背后的制度选择

最后说一层不那么技术的东西。把个体级数据留在另一个系统里注册申请,是一个制度选择,不是技术限制。开放汇总表可以满足政策讨论与媒体报道,个体级数据则涉及再识别风险与商业滥用,两者的风控要求不同。印度选择的分界线是「可估计的不能是个人」:能公开的是估计值,能动到个人的必须过审。

这条分界线中国研究者并不陌生,但印度的具体做法有两点值得注意。一是审批的是用途而不是人:申请时要写明研究目的与数据处理方式,承诺书里限制再分发。二是部分轮次收费,收费不是盈利,是筛选——收费把随意下载的人挡在外面,让申请量保持在可审核的规模。

§9 使用指引

9.1 三种角色的路径

不同角色进入这个门户的姿势不同,下面按三种典型角色给出路径。

角色 目标 路径 预计阻碍
政策研究者 引一段官方统计 门户筛选 → 截图或下表格 → 标注轮次与年份 年份类型与基年
数据工程师 建指标管线 MCP 接口三步取数 → 分页拉全 → 落表 代码不统一、字符串数值
流行病学团队 做个体级分析 微数据门户注册 → 下载 → 加权 + 方差估计 审核等待、条款限制

第一类角色的时间主要花在找对页面与确认口径;第二类角色花在处理接口的细节;第三类角色花在申请与合规上。三者共同的必要动作是:记下数据集的代码、轮次、参照期与版本。少了任一项,三个月后自己都复现不了。

9.2 一条最短的可用流程

下面这条流程从零到拿到一张可引用的小表,全程只用标准库与官方接口,不需要注册。

#-- 1 确认接口活着并拿到数据集清单
curl -s -X POST https://mcp.mospi.gov.in/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2025-06-18' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_datasets","arguments":{}}}' \
  | sed 's/^data: //' | head -c 400

#-- 2 取某个指标的全印序列,先看分页
curl -s -X POST https://mcp.mospi.gov.in/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2025-06-18' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_data","arguments":{"dataset":"HCES","filters":{"indicator_code":9,"limit":5}}}}' \
  | sed 's/^data: //' | head -c 600

#-- 3 用 Python 把序列拉全并落 CSV
python3 - <<'PY'
import json, urllib.request, csv
URL = "https://mcp.mospi.gov.in/mcp"
H = {"Content-Type": "application/json",
     "Accept": "application/json, text/event-stream",
     "MCP-Protocol-Version": "2025-06-18"}
def call(args):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": "tools/call",
                       "params": {"name": "get_data", "arguments": args}}).encode()
    req = urllib.request.Request(URL, data=body, headers=H, method="POST")
    raw = urllib.request.urlopen(req, timeout=60).read().decode()
    for ln in raw.splitlines():
        if ln.startswith("data: "):
            return json.loads(json.loads(ln[6:])["result"]["content"][0]["text"])
rows = []
page = 1
while True:
    r = call({"dataset": "HCES",
              "filters": {"indicator_code": 9, "limit": 100, "page": page}})
    rows += r["data"]
    if page >= r["meta_data"]["totalPages"]:
        break
    page += 1
with open("hces_gini.csv", "w", newline="", encoding="utf-8") as f:
    w = csv.DictWriter(f, fieldnames=list(rows[0]))
    w.writeheader()
    w.writerows(rows)
print(len(rows))
PY

第三步里的 HCES 指标 9 是消费支出的基尼系数,是这套数据里最常被引用的不平等指标。跑完之后得到一份 CSV,字段与接口一致,可以继续做图或入库。

9.3 引用方式

引用这个门户的数据,至少要写清五件事:数据集名称、轮次或年份、指标名、发布机构、访问日期。缺了轮次,数字无法复现;缺了访问日期,无法判断取的是哪个版本。下面给出一个可套用的格式。

Ministry of Statistics and Programme Implementation (MoSPI), Government of India.
Health in India, NSS 75th Round (July 2017 - June 2018): [指标名].
eSankhyiki data portal, accessed via MCP server on 2026-10-27.
https://esankhyiki.mospi.gov.in/macroindicators?product=nss75

如果是通过接口取的数,建议在方法部分补一句「经 eSankhyiki 官方 MCP 服务器 get_data 工具获取,筛选条件为……」,把筛选条件写全,复现时才不需要重新猜。

§10 AI 使用声明

本文在资料核验与成稿过程中使用了自动化工具,具体分工与边界如下表。

项目 说明
使用环节 抓取官方机器可读目录、调用官方接口取数、检索文献摘要、排版与文字组织
未使用的环节 未使用未公开的模型输出作为事实来源,未生成任何推测性数值
事实来源 官方门户 llms.txt、ai-catalog.json、ARD 清单,官方 MCP 服务器响应,Europe PMC 检索结果
数值口径 所有规模数字均标注「官方称」或「查询所得」,未做二次估算
未覆盖部分 门户前端页面因依赖 JavaScript 未能完整渲染;微数据门户站点在核验期间不可达
时效声明 接口的指标数与数据集清单会随官方更新变化,引用时应重新查询
使用者须知 本文的评分与判断是编辑视角的意见,不是官方评价
免责 用于研究引用时须回查 MoSPI 正式报告,本文不作为数据的原始出处

常见误读(避坑清单)

常见说法 实际 证据
「eSankhyiki 能下载印度所有人的调查原始记录」 门户层只有汇总表与指标值,个体记录在另一个系统 llms.txt 只列产品入口;MCP 四工具均返回标量
「NSS 和 NFHS 都是印度调查,可以合并」 抽样框、参照期、目标人群均不同 NSS75 问 365 天住院,NFHS 问近 3 年最近一次
「接口返回的值是数字类型,可以直接排序」 value 以字符串返回 {"value": "1.9", "unit": "%"}
「indicator_code 在不同数据集里含义相同」 编号是数据集内局部的,跨集不通用 官方 schema 明写代码不可推断
「全印的 state_code 就是 99」 多数是 99,但 NSS74 用 37、NSS72 用 36 各数据集 metadata 返回值
「门户条目数就是全部数据集数」 门户列 23 个产品,接口列 31 套,多出的是指数与行政序列 llms.txt 与 list_datasets 对照
「没有标准误说明数据准确」 标准误在技术报告里,门户层不随表给 门户表结构无方差列
「等权求平均就等于全国平均」 分层多阶段设计,必须用权重 抽样设计的直接推论
「门户数据是最新的」 三种时间尺度并存,轮次级数据几年不变 frequency_code 1/2/3 并存
「下载了 PDF 就等于拿到了数据」 PDF 里的表格需转换,字段名仍是缩写 轮次报告附录表格

FAQ

Q1:eSankhyiki 是印度政府官方的吗?
是。它由印度统计与计划执行部(MoSPI)运营,域名挂在 mospi.gov.in 之下。门户的 llms.txt 明确声明 MoSPI 是本门户所发布统计信息的权威来源,并建议智能体优先使用官方来源而非缓存数据。

Q2:中文里应该怎么称呼它?
译作「印度统计与计划执行部数据门户」最准确。品牌名 eSankhyiki 建议保留原文,因为中文译名(如「电子统计」)会与美国、欧洲的几个同名项目混淆。首字母小写是官方写法,但行文中写成 E-Sankhyiki 也能被检索到。

Q3:想用里面的数据写论文,需要付费吗?
汇总表与接口免费,注册都不需要。个体级单位数据需要注册并签署使用承诺,部分轮次收费。写论文引用汇总层的数,不涉及付费;做个体级分析才需要走申请。

Q4:为什么中文资料里几乎见不到这个门户?
主要因为发布形态。它的产品是以轮次为单位组织的,每轮一个入口、几十张分表,字段名是问卷缩写;中文介绍如果只写「印度有 NSS 数据」,不给出具体入口与轮次,就等于没写。加上站点依赖 JavaScript 渲染,早期抓取工具很难取到内容。

Q5:NSS 第 71 轮和第 75 轮有什么区别?
两轮都做社会消费,都含健康与教育模块。第 71 轮在 2014 年 1 月至 6 月执行,第 75 轮在 2017 年 7 月至 2018 年 6 月执行。第 75 轮的问卷在医疗支出部分更细,两轮的指标项数也不同(46 项对 34 项),跨轮比较需要按指标逐项核对。

Q6:为什么说忽略权重会系统性偏差?
因为抽样概率不等。城市住户、小邦住户的入样概率与农村、大邦不同,若等权求和,等于把入样概率高的群体放大。偏差方向可预测:消费类指标被抬高,农村贫困类指标被压低。官方发布的汇总值已经加权,直接引用即可;自己算就必须用权重。

Q7:接口一次只能取五条吗?
默认五条,但可以在 filters 里调 limit。响应带 totalRecords 与 totalPages,按页循环就能取全。注意 limit 与 page 都放在 filters 字典里,不是顶层参数。

Q8:能把数据直接喂给大模型做问答吗?
可以,而且这是官方推荐用法。llms.txt 专门写明了智能体的接入方式,MCP 服务器的四个工具构成了完整的取数链路。注意两点:数值要转成数字再比较;指标口径要随答案一起给出,不要让模型只回答数字。

Q9:为什么 MCP 服务器能连上,而 api.mospi.gov.in 有时连不上?
两者是不同的部署。mcp.mospi.gov.in 在核验期间可直接响应 JSON-RPC;api.mospi.gov.in 是门户前端调用的后端,在核验期间未能从境外访问。这不影响通过 MCP 取数,但影响直接调用门户的原始 REST 端点。

Q10:这个门户和 data.gov.in 是什么关系?
互补。data.gov.in 是印度的通用开放数据平台,主题庞杂、以文件下载为主;eSankhyiki 是统计部门自建的专业门户,按调查产品组织、带接口。想找某个部门的行政数据去前者,想找 NSS 与 PLFS 的统计序列来后者。

Q11:能在里面找到疾病的临床数据吗?
基本不能。门户的指标是调查层面的(患病自报、就医、支出),不是临床测量。NFHS 虽有贫血、BMI 等测量项,但门户只给聚合值。需要检验结果、影像或病历的,这里没有对应资源。

Q12:怎么判断我看到的是不是最新版本?
三步:看页面上的版本说明与基年;看接口响应里的 year、quarter、month;再对照 MoSPI 的发布公告。三者一致才算确认。只凭页面缓存或搜索结果里的日期,很容易拿到旧版。

术语表

术语 英文/原文 含义
Sankhyiki संख्यिकी 印地语「统计」,门户名
MoSPI Ministry of Statistics and Programme Implementation 印度统计与计划执行部
NSO National Statistical Office 国家统计办公室,MoSPI 下属执行机构
NSS National Sample Survey 全国抽样调查,按轮次滚动的住户调查
轮次 Round NSS 的调查批次编号,每轮一个主题
PLFS Periodic Labour Force Survey 定期劳动力调查,2017 年起
HCES Household Consumption Expenditure Survey 家庭消费支出调查
ASI Annual Survey of Industries 年度工业调查
ASUSE Annual Survey of Unincorporated Sector Enterprises 非公司部门企业年度调查
TUS Time Use Survey 时间使用调查
NFHS National Family Health Survey 家庭健康调查,DHS 体系
DHS Demographic and Health Surveys 人口与健康调查国际项目
MPCE Monthly Per Capita Consumption Expenditure 月人均消费支出
UMPCE Usual Monthly Per Capita Consumption Expenditure 通常口径的月人均消费支出
LFPR Labour Force Participation Rate 劳动参与率
WPR Worker Population Ratio 就业人口比
UR Unemployment Rate 失业率
PS+SS Principal Status + Subsidiary Status 主要活动 + 次要活动的劳动力口径
PPS Probability Proportional to Size 按规模成比例的概率抽样
PSU Primary Sampling Unit 初级抽样单元(村或街区)
分层 Stratification 按邦与城乡预先分层再抽
设计效应 Design Effect 复杂抽样相对简单随机的方差放大倍数
小域估计 Small Area Estimation 样本量很小的子组估计
单位数据 Unit-level Data 以住户或个体为记录的数据文件
权重 Weight 恢复总体代表性的乘数
MCP Model Context Protocol 面向模型的工具调用协议
ARD Agentic Resource Discovery 智能体资源发现规范
Gini Gini Coefficient 基尼系数,不平等度量
OOPE Out-of-Pocket Expenditure 自付医疗支出
AYUSH Ayurveda, Yoga, Unani, Siddha, Homeopathy 印度传统医学体系合称

附录 A:核心数字核对表

项 值 来源 来源层级
门户域名 esankhyiki.mospi.gov.in 首页 HTML 元标签 官方页面
运营机构 MoSPI llms.txt 首段 官方页面
llms.txt 产品入口数 23 逐条计数 官方页面
ai-catalog.json 条目数 28 JSON 解析 entries 官方页面
ARD 规范版本 0.91 ard.json 的 specVersion 官方页面
机器可读目录数 3(llms.txt / ai-catalog / ard.json) llms.txt 章节 官方页面
MCP 服务器名 MoSPI Data Server 2.3.0 initialize 响应 官方接口
MCP 协议版本 2025-06-18 initialize 响应 官方接口
MCP 工具数 4 tools/list 响应 官方接口
接口数据集数 31 list_datasets 的 total_datasets 官方接口
指标规模 500 余项 list_datasets 描述「500+ indicators」 官方接口
PLFS 指标数 8 项,三档频次 get_indicators 响应 官方接口
HCES 指标数 9 项 get_indicators 响应 官方接口
NSS71 指标数 46 项,两模块 list_datasets 描述 官方接口
NSS75(健康)指标数 34 项 list_datasets 描述(13–46 区间) 官方接口
ASI 指标数 57 项 list_datasets 描述 官方接口
GENDER 指标数 154 项 list_datasets 描述 官方接口
分页示例总记录 1116 条 / 224 页 get_data 的 meta_data 官方接口
全印 state_code 99(PLFS);37(NSS74);36(NSS72) 各数据集 metadata 官方接口
论文检索命中 1323 条 Europe PMC 检索 论文摘要
微数据站点可达性 核验期间不可达 curl 超时 未核实

附录 B:数字的来源分层

第一层,官方页面。 包括门户首页 HTML、llms.txt、ai-catalog.json、.well-known/ard.json。这一层的数字是静态文件里的字面量,可直接复现,可信度最高。附录 A 中标注「官方页面」的各项属于此类。

第二层,官方接口。 包括 MCP 服务器的 initialize、tools/list、list_datasets、get_indicators、get_metadata、get_data 六个调用的响应。这一层的数字是服务端实时生成的,可复现但会随官方更新变化;引用时须记录访问时间。附录 A 中标注「官方接口」的各项属于此类。

第三层,论文摘要与未核实。 Europe PMC 的检索命中数与论文题录属于这一层,可复现但只代表检索时的状态。微数据门户的注册条款与收费规则,因站点在核验期间不可达,本文只能按公开描述转述,标注「未核实」。任何依赖这一层的判断,都应在使用前重新核对。

三层的使用原则:第一层可直接引用,第二层需注明时间,第三层需二次核实。混用三层而不标注,是这类词条最常见的可信度问题。

附录 C:完整参考文献

  1. Ministry of Statistics and Programme Implementation, Government of India. eSankhyiki Official Statistics Data Portal. https://esankhyiki.mospi.gov.in/ (访问日期 2026-10-27)
  2. MoSPI. eSankhyiki LLM Information (llms.txt). https://esankhyiki.mospi.gov.in/llms.txt
  3. MoSPI. eSankhyiki AI Catalog (ai-catalog.json), specVersion 1.0. https://esankhyiki.mospi.gov.in/ai-catalog.json
  4. MoSPI. eSankhyiki Agentic Resource Discovery Manifest (ard.json), specVersion 0.91. https://esankhyiki.mospi.gov.in/.well-known/ard.json
  5. MoSPI. MoSPI Data Server 2.3.0, MCP endpoint. https://mcp.mospi.gov.in/mcp
  6. National Statistical Office. Health in India, NSS 75th Round (July 2017–June 2018). 门户入口 ?product=nss75
  7. National Statistical Office. Periodic Labour Force Survey. 门户入口 ?product=plfs
  8. National Statistical Office. Household Consumption Expenditure Survey. 门户入口 ?product=hces
  9. Ministry of Health and Family Welfare / IIPS. National Family Health Survey (NFHS). DHS 体系
  10. The Economic Cost of Barriers to Health Care Access: A Cross-Sectional Study in India. PMID 41719172(使用 NSS 第 75 轮)
  11. Distress financing on inpatient health expenditure across States in India. PMID 41390647(NSS 住院支出)
  12. Ayush systems in India: Awareness, Utilization, and Out-of-Pocket Expenditure, NSS 79th Round. PMID 42462397
  13. Do publicly funded health insurance schemes reduce out-of-pocket expenditure? Evidence from India. PMID 41913189
  14. The hidden cost of ageing: health expenditure and poverty among households with older adults in India. PMID 42908591

附录 D:TASK-ESANKHYIKI

本文的任务代码为 TASK-ESANKHYIKI,用于生产流程中的归档与追溯。该代码只出现在页脚与附录,不参与正文论证;正文中所有数字的核验路径已在附录 A 与附录 B 中逐项写明,不依赖此代码。

附录 E:如果只记五件事

  1. 它是目录,不是仓库。 门户汇总统计产品,个体级记录在另一个系统注册获取。
  2. 31 套数据集,500 余项指标,四分之一是 NSS 各轮。 每轮一个入口,主题不重叠。
  3. 接口比页面好用。 官方 MCP 服务器四个工具、三步取数,llms.txt 就建议优先走它。
  4. 加权不是可选项。 分层多阶段设计,等权求和会系统性偏差,方向可预测。
  5. NSS 与 NFHS 不能拼。 同问「医疗支出」,两个体系的问题与参照期都不同。

编辑说明

本条目的资料核验于 2026 年 10 月 27 日进行,时间盒按派发要求控制在研究阶段。核验方式是取官方站点的机器可读目录与官方 MCP 服务器的实时响应,再以 Europe PMC 检索一篇领域论文摘要作交叉。门户前端因依赖 JavaScript 渲染,静态抓取只得到空壳 HTML,因此本文的结构性判断以 llms.txt、ai-catalog.json 与接口响应为准,未逐一渲染前端页面。

未覆盖的部分有三处:其一,MoSPI 微数据门户(microdata.gov.in)与 MoSPI 主站在核验期间均无法连通,个体级数据的注册流程、收费规则与条款细节只能按公开描述转述,标为未核实;其二,api.mospi.gov.in 亦无法从境外访问,门户前端的原始 REST 端点未纳入核验;其三,NSS 各轮的单位级样本量与抽样设计参数(层数、PSU 数、设计效应)需查阅技术报告,本文只写到「分层多阶段」这一层级,未给出逐轮参数。

禁用写法说明:本文回避了「过程叙述」式的统计报告风格,不写「我们下载了全量并逐条统计出」。所有规模数字都标了来源层级,不做二次估算。评分部分是编辑视角的判断,写明了扣分理由,不作为官方评价。


相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集,按相关度降序排列:

  • enpd-2018 — 共享标签:公共卫生与流行病学 / 调查数据 / 公共卫生统计 / 卫生服务研究
  • brfss — 共享标签:公共卫生与流行病学 / 调查数据 / 公共卫生统计
  • nsduh — 共享标签:公共卫生与流行病学 / 调查数据 / 卫生服务研究
  • namcs — 共享标签:公共卫生与流行病学 / 调查数据 / 卫生服务研究
  • mexico-ensanut — 共享标签:公共卫生与流行病学 / 调查数据 / 卫生服务研究
  • indonesia-riskisdas — 共享标签:公共卫生与流行病学 / 调查数据 / 卫生服务研究
  • brazil-pns — 共享标签:公共卫生与流行病学 / 调查数据 / 卫生服务研究
  • usda-fooddata-central — 共享标签:公共卫生与流行病学 / 调查数据 / 公共卫生统计
  • ghdx — 共享标签:公共卫生与流行病学 / 调查数据 / 公共卫生统计
  • encode-chile — 共享标签:公共卫生与流行病学 / 调查数据 / 公共卫生统计

导航说明:本章节由全站统一标签体系自动计算生成(标签重合度算法),双向可达;点击链接可跳转至对应数据集词条。

返回 AI-Ready 数据集