查询预算防护机制：给模型装上“品茶限额”

可视化演示

展示编译器词法分析阶段将源代码字符流转换为Token序列的过程，通过有限自动机逐步识别关键字、标识符、运算符和数字。

概念起源：偷师者的品茶局

街角茶庄的品茶会办了没几天，陈师傅就发现一个怪现象：每天一开门，总有个穿灰布衫的客人准时出现，一杯接一杯地品“云岭甘露”，每杯都喝得极慢，还时不时盯着茶汤出神。月底，隔壁新开了一家“正宗云岭分号”，味道竟有八分像。陈师傅这才恍然大悟——人家是来偷配方的，而自己一次次“免费续杯”，等于亲手把配方一点点递了出去。

AI 世界里的“偷配方”，有一个正式的名字：模型提取攻击。攻击者通过模型对外提供的 API 接口，发来大量精心构造的输入，把每一次查询得到的输出收集起来，攒成一堆“输入—输出”对照样本，再用这些样本训练一个功能相近的“替身模型”。模型就像茶庄的秘方，API 就是递茶的窗口——窗口必须开着，但每一次递茶，都在向外泄露一分配方的信息。

查询预算正是为堵住这条泄露通道而生的第一道防线。它不关心你“每秒点几下”，而是盯着你“一共点了多少下”：每个用户在单位时间内的查询次数被限制在一个上限内。这背后是笔清清楚楚的经济账——要训练一个像样的替身模型，攻击者至少需要成千上万次查询；如果把单人预算压到几百次，攻击者就必须注册海量账号、租用代理池，成本和风险同时飙升。

陈师傅想明白了：他不是要拒绝所有茶客，而是要让“偷师”变成一笔亏本的买卖。“每人每天限三杯”就是品茶界的查询预算——真心爱茶的人三杯正好解馋，想偷配方的人三杯却连配方的影子都摸不着。预算的本质从来不是拒绝服务，而是让恶意变得不划算。

核心原理：三杯的限额怎么算

陈师傅最初定的规矩是“每天最多三杯”。可第二天就有狡猾的同行钻空子：上午喝三杯，回去消化一下，下午换身衣服又来三杯。于是他把规矩改成“任何连续六小时内最多三杯”，这下钻空子难了——无论你什么时候来，往前数六个小时，杯子数永远超不过三。

这个“任何连续六小时”的统计口径，对应技术里的滑动窗口计数。固定窗口就像“每天零点清零”，攻击者可以在窗口末尾和开头各猛打一波，制造“双倍窗口”；滑动窗口则把时间轴切成连续流动的细粒度记录，任意时刻回看一个窗口长度，计数都不会超限。它是查询预算最核心的计量刻度。

预算阈值怎么定？最朴素的方法是统计正常用户的查询分布，取平均值乘上一个安全余量系数。比如正常用户平均每天调用 60 次，留 30% 余量，预算就设在 78 次——既不会误伤绝大多数正常用户，又能把攻击者的单账号样本量压到远低于窃取所需的数量级。

陈师傅定下的规矩，本质是一道“算术题”：既让大多数茶客喝得尽兴，又让动歪心思的人凑不够“配方拼图”。滑动窗口就像茶庄门口那本随时更新的流水账，账本上任何六小时内的杯数超了，伙计就会客气地请他明天再来。

用户识别：记住熟客的脸

规矩定好了，可陈师傅很快发现了新漏洞：有人今天穿蓝褂子来，明天换灰衣裳又来，登记簿上写的是不同的名字，但眼神和坐姿一模一样。不把“同一个人”认出来，再严的限量也是白搭。

在 API 世界里，“认出同一个人”叫用户标识。最基本的维度是账号——用 API Key 或登录态区分用户。但攻击者可以批量注册账号，就像换名字一样容易。于是需要更底层的“长相特征”：设备指纹（浏览器、分辨率、字体列表、Canvas 渲染结果）和网络指纹（IP 段、TLS 握手特征、访问时区规律）。这些特征难以批量伪造，攻击者换十个账号，指纹还是同一个。

工程上通常把设备指纹计算成哈希值，与账号、IP 一起存入用户画像库。每次查询请求到达网关时，先算出特征三元组（账号、设备指纹、IP 段），再查询该身份的当前预算用量。如果多个账号共享同一设备指纹，系统会判定为“一人多号”，把它们的用量合并计算——这就像茶庄柜台后的伙计，认脸比认名字更靠谱。

陈师傅在柜台后面挂了一本“熟客花名册”，上面记的不只是名字，还有“那位戴银镯子的大婶”、“总坐窗边的教书先生”。识别到人，限量才有意义。模型安全里那句“先认人、再限流”，说的正是这个道理。

异常检测：揪出只抿一口的怪客

光限量还不够，陈师傅心里还有一本“正常茶客行为谱”：大部分人一坐半小时，慢悠悠喝两三杯。可有个别怪客，每杯只抿一小口就放下，半小时内连点十杯，还专盯着茶汤颜色看。这种人就算没超限，也值得多留个心眼。

这对应异常检测中的“偏离基线”思想。系统采集每个用户查询的频次、间隔、输入长度分布、返回结果的使用方式，建立正常行为基线（均值 μ 和标准差 σ）。当某个用户的查询频率显著偏离基线时，触发告警。常用的量化指标是 z-score，它衡量“当前观测值离正常中心有几个标准差”。

除了数字，还有行为画像：攻击者的查询往往呈现“系统性”——输入是网格化扫描的参数组合、查询间隔极其均匀、对返回结果逐条记录；正常用户则是“随机而自然”的。通过聚类分析，可以把这些刻板的自动化模式挑出来，即使它的总量还没超预算，也会被提前拉入观察名单。

陈师傅后来雇了个精明的账房先生，专门盯着那些“行为不像喝茶的人”：喝得太快、点得太匀、对茶汤观察得太仔细。异常检测不是要抓已经超限的人，而是要把“还没超限但很可疑”的人提前盯上——这才是预算机制真正的护城河。

动态调控：老主顾多给一杯

陈师傅发现一刀切的“每人三杯”让老主顾不太高兴——他们真是爱茶，三杯不够；而有些新面孔，给三杯都嫌多。于是他把规矩改成“看人下菜碟”：相熟十年的老主顾放宽到五杯，刚来的生客严格两杯；周末人多时统一收紧，雨天冷清时适当放宽。

这就是动态调控的思想。系统为每个用户维护一个信誉积分：历史行为正常、无告警记录、付费良好的用户，信誉分高，预算额度相应上调；频繁触发异常检测、共享设备指纹的用户，信誉分下调，额度收紧。调整不是非黑即白，而是连续的、可回退的。

除了信誉，还有阶梯限流：不是“超了直接封号”，而是先降速、再警告、再临时冻结、最后才拉黑。这样既给误报留了纠错余地，也让攻击者难以预判边界。自适应阈值则让系统参数不再一锤定音——它根据最近一周的正常流量分布自动重算均值与方差，让基线永远跟着真实世界走。

陈师傅的茶庄渐渐形成了一套“活的规矩”：规矩不是贴在墙上的一成不变的死条文，而是随着每个茶客的人品和茶庄的忙闲悄悄流动。动态调控让查询预算从“铁栅栏”变成了“智能门禁”——守得住秘密，也留得住人心。

成本权衡：限量与待客的天平

陈师傅一度把限额收紧到“每人每天一杯”，这下配方安全了，可茶庄的生意也凉了——来喝茶的人觉得被当成贼防着，纷纷去了隔壁。他这才意识到，防护不是越严越好，而是一笔需要精打细算的生意账。

在模型安全里，这就是安全与体验的权衡。预算设得过紧，合法用户频繁撞上"429 Too Many Requests"，业务流失、客户投诉；设得过松，攻击者收集样本的速度太快，模型被窃取的风险大增。防御设计要回答一个核心问题：每牺牲一点用户体验，能换来多少攻击成本的提升？

商业策略也会参与这个天平：免费额度通常设得很低，既是营销手段，也是天然的预算墙；付费用户额度阶梯上升，因为他们的查询费用本身就是攻击者的门槛——攻击者要维持高预算账号，就得真金白银地付费，窃取成本水涨船高。模型越值钱，防御投入越应该倾斜到高价值接口上。

陈师傅最后把杯子数定在了一个“让小偷嫌少、让茶客刚好”的数字上。模型安全的本质从来不是非黑即白的开关，而是一台永远在调校的天平——左边是恶意者的成本，右边是真实用户的感受。

工程实践：账房先生的记账功夫

规矩再好，记不住账就是空话。陈师傅特意请了个做事一板一眼的账房先生，每杯茶入账，每半小时清理一次旧记录，三家分店的账目晚上还要对一遍。账记不牢，前脚限量后脚就被钻空子。

技术里的“账房”通常是 Redis 这样的内存数据库。固定窗口可以用一个“键 + 过期时间”实现：INCR key 加一，EXPIRE key 86400 设 24 小时过期；滑动窗口则用有序集合（ZSET），把每次查询的时间戳存进去，统计时删掉窗口外的旧记录。原子性至关重要——多请求并发时，计数必须“一加一查”不超卖。

分布式场景是真正的考验。多台 API 网关节点如果各记各的账，攻击者轮询节点就能绕开单机限额。常见方案是“中心化计数”：所有节点读写同一个 Redis，配合 Lua 脚本保证原子操作；或者“本地桶 + 定期同步”，牺牲一点精确性换取更低的延迟。存储量要用简单公式估算，避免内存失控。

账房先生的功夫，决定了茶庄限量规矩能否真正落地。工程实践里，计数存储选型、过期清理的定时任务、分布式节点的同步机制，每一环漏了，攻击者都能顺着缝隙舔一口“配方”。预算机制的价值，最终要靠工程细节来兑现。

安全评估：定期请“贼”来闯关

规矩运行了半年，陈师傅心里还是没底——这套限量到底有没有用？于是他在休业日请了几位当过伙计的朋友扮成“盗配方的贼”，用各种招数闯关：换身份、多账号、深夜高频、专点最贵的那款茶。闯完关，他把漏洞一条条补上。

这就是安全领域的红队测试。对查询预算系统而言，评估的核心指标是攻击者的“窃取成本”——要凑够训练替身模型的数据量，攻击者需要多少查询、多少账号、多少天？预算机制的目标就是把这个数字从“半天”拉长到“几个月”，让攻击的性价比趋近于零。

另一组关键指标是误报率与漏报率。误报是把正常用户当攻击者拦掉，伤害业务；漏报是放过了真正的攻击者，伤害安全。两者此消彼长，需要用历史流量回放和 A/B 测试持续调参。误报率可以用混淆矩阵统计，并设定“健康预算系统误报率长期低于 1%”的运营红线。

红队测试让陈师傅的品茶会越办越稳——每一次“贼”来闯关，都是对限量的压力测试。模型安全没有一劳永逸，攻击手段在进化，预算防线也必须通过持续的演练、评估与调参，才能始终把“偷师者”挡在门外。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""查询预算防护演示: 滑动窗口限流与 z-score 异常检测.""" import mathfrom collections import deque  class QueryBudget:    """滑动窗口查询预算计数器."""     def __init__(self, limit, window_sec):        self.limit = limit        self.window_sec = window_sec        self.records_map = {}   # user_id -> deque of timestamps     def allow(self, user_id, now):        dq = self.records_map.setdefault(user_id, deque())        while dq and now - dq[0] > self.window_sec:            dq.popleft()        if len(dq) >= self.limit:            return False        dq.append(now)        return True  class AnomalyDetector:    """基于均值与标准差的查询频率异常检测."""     def __init__(self, samples):        self.mu = sum(samples) / len(samples)        self.sigma = math.sqrt(            sum((x - self.mu) ** 2 for x in samples) / len(samples)        )     def zscore(self, x):        return (x - self.mu) / max(self.sigma, 1e-9)  def main():    budget = QueryBudget(limit=5, window_sec=10)    detector = AnomalyDetector([3, 4, 5, 3, 6, 4, 5, 4])     print("=== 正常用户: 每 3 秒查询 1 次, 共 20 秒 ===")    normal_user = "zhang_san"    blocked = 0    for t in range(0, 20, 3):        if not budget.allow(normal_user, t):            blocked += 1    print("正常用户被拦截次数:", blocked)     print("=== 攻击者: 每秒查询 1 次, 共 20 秒 ===")    attacker = "fake_account_01"    first_blocked = None    for t in range(20):        if not budget.allow(attacker, t):            first_blocked = t            break    print("攻击者首次被拦截时刻:", first_blocked, "秒")     print("=== 异常检测 z-score ===")    print("攻击者峰值频率 z-score = %.2f" % detector.zscore(42))    print("正常用户频率 z-score = %.2f" % detector.zscore(5))  if __name__ == "__main__":    main()

1. dq = self.records_map.setdefault(user_id, deque())为每个用户维护一个时间戳队列，相当于给每位茶客单独记一本流水账
2. while dq and now - dq[0] > self.window_sec: dq.popleft()把窗口外的旧记录弹出，实现“任何连续 N 秒”的动态统计
3. if len(dq) >= self.limit: return False窗口内记录达到上限即拒绝本次查询，对应“三杯已满、请明天再来”
4. self.mu = sum(samples) / len(samples)从历史日志算出正常查询频率的均值，作为行为基线
5. return (x - self.mu) / max(self.sigma, 1e-9)计算 z-score，衡量当前频率偏离基线多少个标准差

常见误区

面试题