GEO 在印地语中如何运作？

印地语是世界第三大语言——按 Ethnologue 的统计超过 6 亿人——却只是不足 0.1% 网站的内容语言。我们经手的其他语言，没有任何一种的使用者与内容之比接近这种失衡：希伯来语占网络的 0.4%，服务大约九百万人；印地语那一小片，却服务六亿人。当助手撰写印地语答案时，它检索的是网络上最稀薄的商业语料之一。

这种稀薄改变了谁会被引用。助手要么依赖现存那一小撮结构化的印地语来源，要么退回英语页面再即时翻译——于是少数能干净回答问题的母语印地语来源会被反复引用。在拥挤的英语细分里，一个引用位要靠数月佐证才能赢下；在印地语里，一个结构良好的页面几乎可以无人争抢地占据它。

本指南是我们印度市场指南的语言层配套——那一篇讲市场本身：用户数量、都市级提示词、价格敏感模式。这里我们只谈语言：天城文对字节和 token 做了什么，Hinglish 在检索中如何表现，以及为什么印地语实体工作能越过印度国界。

天城文有一笔多数团队从未看见的机械成本。在 UTF-8 中，每个天城文字符占三个字节，因此同样的内容大约是英语等价物的三倍重。抓取预算能感觉到，机器可读的导出能感觉到——在我们自己的站点上，印地语 llms-full 导出迫使我们把体积上限翻了一倍——而任何按字节数截断的东西，都会先截断印地语。

分词会加剧这个问题。主流模型背后的分词器主要以英语和拉丁文字训练，它们会把天城文拆成远更多的 token：关于分词器公平性的研究测得，同一段文本在不同语言之间最多相差 15 倍。实际上，能装进上下文窗口的印地语更少，检索片段更早被切断，冗长页面的关键主张会先被截掉。

对策是结构性的，不是耍聪明：短而自足的段落，在第一句就写出品牌名和主张；用朴素的重复形式，而不是优雅的措辞变化；标题要匹配问题的实际问法。答案优先的写法在每种语言里都重要；在印地语里，token 经济让它没有商量余地。

相当一部分真实的印地语提示词从不触及天城文。用户用拉丁字母敲印地语语法，中间夹着英语商业词汇——品牌名、品类、"best"、"price"。这种语码转换足够结构性，NLP 研究者为此建了一套评测基准（GLUECoS，英语-印地语是它的两个语言对之一），而检索把同一问题的天城文形式、Hinglish 形式和英语形式，当成三种不同措辞，通向三个不同的来源池。

Hinglish 还有另外两种模式没有的麻烦：没有标准拼写。同一个词会罗马化为 "accha"、"acha" 或 "achha"；"kaise" 与 "kese" 竞争；"zyada" 与 "jyada" 竞争。这不是另建一个 Hinglish 站点能解决的——Hinglish 是一种检索模式，不是一个 locale。解决办法是：在段落里用两种文字同时写出品牌和品类，好让混合文字匹配找得到它们；再配上一组按自己曲线单独测量的 Hinglish 提示词。

模型必须学会：品牌的天城文写法与拉丁写法是同一个实体——否则引用会拆到两个半熟悉的名字上，哪一个都积累不起权威。这意味着有意识地声明两种形式：带替代名称的结构化数据、同时拼出两种写法的资料页，以及在天城文旁边印出拉丁品牌名的印地语页面，而不是把对应关系交给运气。印地语来源习惯在句子中间混用文字，这对你有利——前提是你自己的页面先定下规范配对。

印地语实体工作还会走出国界。印地语提示词来自阿联酋、美国和英国的侨民，而不只来自印度——我们的迪拜指南专门跑一条印地语赛道，正是因为印度社群是阿联酋最大的人口群体。一个助手能引用的印地语来源，同一页就能服务勒克瑙的买家和迪拜的买家；语言层是一笔投资，摊到所有印地语使用者提问的市场。

印地语不是一笔未来赌注；这些界面已经上线。Google 于 2024 年 8 月在印度推出 AI Overviews，同时支持英语和印地语，并带上作为印度首发功能的语言切换；ChatGPT、Perplexity 和 Gemini 今天都能回答印地语和 Hinglish 提示词。语料稀薄，多数品牌还没注意到——这两者加在一起，就是全部机会。

印地语是我们九种母语级语言之一，测量方式与其他语言相同：每种语言在第一天就定下一组固定提示词，在 ChatGPT、Perplexity 和 Gemini 上以退出登录的干净会话采样，声量份额与引用率对照第一天的基线跟踪。我们不编造客户结果——方法先用在自己的站点上，并以未经编辑的截图记录在公开案例研究里，印地语被明确列为已核验的能力之一。