信息速览
印度是全球最大的健康与人口数据生产国之一:每过一两年就有一轮覆盖数十万户的全国抽样调查,跑完就发布厚厚一套报告。但这些数据在国际文献里的出现频率,与它的体量严重不匹配——谈印度健康,英文论文大多引家庭健康调查(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:完整参考文献
- Ministry of Statistics and Programme Implementation, Government of India. eSankhyiki Official Statistics Data Portal. https://esankhyiki.mospi.gov.in/ (访问日期 2026-10-27)
- MoSPI. eSankhyiki LLM Information (llms.txt). https://esankhyiki.mospi.gov.in/llms.txt
- MoSPI. eSankhyiki AI Catalog (ai-catalog.json), specVersion 1.0. https://esankhyiki.mospi.gov.in/ai-catalog.json
- MoSPI. eSankhyiki Agentic Resource Discovery Manifest (ard.json), specVersion 0.91. https://esankhyiki.mospi.gov.in/.well-known/ard.json
- MoSPI. MoSPI Data Server 2.3.0, MCP endpoint. https://mcp.mospi.gov.in/mcp
- National Statistical Office. Health in India, NSS 75th Round (July 2017–June 2018). 门户入口
?product=nss75 - National Statistical Office. Periodic Labour Force Survey. 门户入口
?product=plfs - National Statistical Office. Household Consumption Expenditure Survey. 门户入口
?product=hces - Ministry of Health and Family Welfare / IIPS. National Family Health Survey (NFHS). DHS 体系
- The Economic Cost of Barriers to Health Care Access: A Cross-Sectional Study in India. PMID 41719172(使用 NSS 第 75 轮)
- Distress financing on inpatient health expenditure across States in India. PMID 41390647(NSS 住院支出)
- Ayush systems in India: Awareness, Utilization, and Out-of-Pocket Expenditure, NSS 79th Round. PMID 42462397
- Do publicly funded health insurance schemes reduce out-of-pocket expenditure? Evidence from India. PMID 41913189
- 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:如果只记五件事
- 它是目录,不是仓库。 门户汇总统计产品,个体级记录在另一个系统注册获取。
- 31 套数据集,500 余项指标,四分之一是 NSS 各轮。 每轮一个入口,主题不重叠。
- 接口比页面好用。 官方 MCP 服务器四个工具、三步取数,
llms.txt就建议优先走它。 - 加权不是可选项。 分层多阶段设计,等权求和会系统性偏差,方向可预测。
- 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 — 共享标签:公共卫生与流行病学 / 调查数据 / 公共卫生统计
导航说明:本章节由全站统一标签体系自动计算生成(标签重合度算法),双向可达;点击链接可跳转至对应数据集词条。

