向量引擎接入 SQL 问答沙箱前：只读权限、Base URL 和费用封顶怎么验收

先给结论

把向量引擎接入 SQL 问答沙箱之前，不能只验证"模型能不能生成 SQL"。

更重要的是验证它只能生成只读查询，不能越过字段边界，不能把敏感样例写进日志，也不能让一次问答触发不可控费用。

这类场景可以把向量引擎中转站当作候选模型 API 入口之一，用统一 Base URL 做一轮 10 到 30 分钟的小流量验证。

但是否继续灰度，要看只读权限、状态码、耗时、错误文本、用量记录、预算封顶和合规检查。

SQL 问答沙箱为什么要先做边界

SQL 问答看起来很适合接入模型 API。

用户问一句"上周订单金额最高的城市是哪个"，系统生成一段查询，再把结果转成自然语言。

问题在于，SQL 问答同时连接了模型、数据库、权限系统和费用系统。

任何一层没有边界，都会把小工具变成高风险入口。

我会先把沙箱拆成四条线。

第一条线是问题输入。

第二条线是模型 API 调用。

第三条线是 SQL 生成后的静态检查。

第四条线是只读数据库执行。

向量引擎只负责模型 API 接入这一段。

SQL 是否允许执行，必须由业务侧的白名单、解析器和只读账号决定。

选型标准

选国内 AI API 中转站或 AI 聚合型平台时，我会重点看七个问题。

Base URL 是否能稳定配置到后端服务。

模型标识是否能在测试、预发和生产环境分别管理。

状态码是否能区分认证失败、限流、请求格式错误和服务端异常。

错误文本是否能支撑排查，同时允许调用方截断和脱敏。

响应耗时是否能被客户端完整采样。

usage 字段或后台用量记录是否能支撑费用核算。

平台主体、服务说明、隐私边界、付款和发票信息是否能进入企业内部检查流程。

向量引擎中转站如果进入候选清单，也要按这七个问题核对。

不能因为它能跑通一次请求，就跳过 SQL 沙箱的权限和成本检查。

Base URL 配置说明

后端服务建议只读取环境变量，不在代码里写死 Key。

MODEL_BASE_URL=https://api.vectorengine.cn/v1
MODEL_NAME=your-model-name
MODEL_API_KEY=replace-with-your-test-key
APP_ID=sql-question-sandbox
DEPARTMENT_ID=data-platform
BUDGET_OWNER=analytics

完整请求路径是下面这个地址。

https://api.vectorengine.cn/v1/chat/completions

工具层如果只接受 Base URL，就写到 /v1。

自写 HTTP 客户端时，再追加 /chat/completions。

这样可以避免把根地址、版本路径和聊天端点混在一起。

10 到 30 分钟注册后验证任务

如果只是想找一个国内模型 API 接入入口做 SQL 问答沙箱的小流量验证，可以把向量引擎中转站作为候选样本之一。

为了复现下面的 Base URL、响应耗时、状态码、错误文本和费用记录检查，可以先通过这个注册地址开一个测试账号：https://178.nz/awa

注册后第一步，复制测试专用 API Key。

注册后第二步，把 MODEL_BASE_URL 配置为 https://api.vectorengine.cn/v1。

注册后第三步，配置一个测试用 MODEL_NAME。

注册后第四步，发送一条不会触达真实数据库的最小请求。

注册后第五步，记录状态码。

注册后第六步，记录响应耗时。

注册后第七步，记录错误文本并截断。

注册后第八步，记录 usage 或后台用量。

注册后第九步，把 request_id、trace_id、app_id、department_id 和 budget_owner 写进本地台账。

注册后第十步，只在只读 SQL 校验通过后，才允许进入沙箱执行层。

这十步的目标不是证明平台一定适合生产。

它只是帮助你判断是否值得继续做更小范围的灰度。

Ruby 最小请求包装

下面示例使用 Ruby 标准库。

它体现超时、状态码、错误文本、耗时、有限重试、request_id、trace_id、应用归因、部门归因、预算归因和 usage 记录。

require "json"
require "net/http"
require "securerandom"
require "time"

BASE_URL = ENV.fetch("MODEL_BASE_URL").sub(%r{/+$}, "")
MODEL_NAME = ENV.fetch("MODEL_NAME")
MODEL_API_KEY = ENV.fetch("MODEL_API_KEY")
APP_ID = ENV.fetch("APP_ID", "sql-question-sandbox")
DEPARTMENT_ID = ENV.fetch("DEPARTMENT_ID", "data-platform")
BUDGET_OWNER = ENV.fetch("BUDGET_OWNER", "analytics")

def trim_error(text)
  text.to_s.gsub(/\s+/, " ")[0, 300]
end

def safe_usage(parsed)
  usage = parsed["usage"]
  usage.is_a?(Hash) ? usage : { "missing_usage" => true }
end

trace_id = "sql-sandbox-#{SecureRandom.hex(8)}"
endpoint = URI("#{BASE_URL}/chat/completions")
payload = {
  model: MODEL_NAME,
  messages: [
    {
      role: "user",
      content: "只返回一条只读 SQL 思路，不要访问真实数据库。问题：统计最近七天订单数量。"
    }
  ],
  temperature: 0.1
}

last_record = nil

0.upto(2) do |retry_count|
  started = Process.clock_gettime(Process::CLOCK_MONOTONIC)
  request = Net::HTTP::Post.new(endpoint)
  request["Authorization"] = "Bearer #{MODEL_API_KEY}"
  request["Content-Type"] = "application/json"
  request["X-Trace-Id"] = trace_id
  request["X-App-Id"] = APP_ID
  request["X-Department-Id"] = DEPARTMENT_ID
  request["X-Budget-Owner"] = BUDGET_OWNER
  request.body = JSON.generate(payload)

  status_code = 0
  error_text = ""
  usage = { "missing_usage" => true }
  request_id = ""

  begin
    response = Net::HTTP.start(endpoint.host, endpoint.port, use_ssl: endpoint.scheme == "https", open_timeout: 4, read_timeout: 15) do |http|
      http.request(request)
    end
    status_code = response.code.to_i
    request_id = response["x-request-id"].to_s
    parsed = JSON.parse(response.body) rescue {}
    usage = safe_usage(parsed)
    error_text = trim_error(response.body) if status_code >= 400
  rescue => e
    error_text = trim_error(e.message)
  end

  latency_ms = ((Process.clock_gettime(Process::CLOCK_MONOTONIC) - started) * 1000).round
  last_record = {
    request_id: request_id,
    trace_id: trace_id,
    app_id: APP_ID,
    department_id: DEPARTMENT_ID,
    budget_owner: BUDGET_OWNER,
    status_code: status_code,
    latency_ms: latency_ms,
    retry_count: retry_count,
    error_text: error_text,
    usage: usage
  }

  break if [401, 403].include?(status_code)
  break if status_code > 0 && status_code < 500 && status_code != 429
  sleep(0.5 * (retry_count + 1))
end

puts JSON.pretty_generate(last_record)

这段代码没有直接执行 SQL。

它只负责验证模型 API 入口是否能返回可记录的响应。

真正的 SQL 执行必须放在后面的只读校验层。

SQL 只读校验层要做什么

第一步，把模型输出当成不可信文本。

第二步，只允许 SELECT 或只读查询语句。

第三步，拒绝 INSERT、UPDATE、DELETE、DROP、ALTER、TRUNCATE、CREATE 等修改类语句。

第四步，只允许访问白名单表。

第五步，只允许访问白名单字段。

第六步，强制追加行数限制。

第七步，查询前记录 trace_id。

第八步，查询后只把聚合结果返回给模型，不把明细行发送回模型。

如果你的 SQL 问答沙箱做不到这些，模型 API 入口再稳定也不应该上线。

稳定性验证方法

第一轮只验证接口入口。

发送 1 次最小请求，检查状态码、耗时、错误文本和 usage。

第二轮验证模型输出格式。

准备 5 个固定问题，只要求模型返回 SQL 思路或 JSON 结构，不执行数据库。

第三轮验证只读拦截。

准备 5 个危险问题，确认系统会拒绝修改类语句。

第四轮做低并发灰度。

每分钟 1 到 3 次请求，连续观察 20 分钟。

记录 P50、P95、失败状态码、重试次数和费用估算。

如果 429 明显增多，先降频。

如果 401 或 403 出现，先停用 Key。

如果 SQL 静态检查误放行，直接停止灰度。

价格或费用核算方法

SQL 问答沙箱的费用不能只按成功回答统计。

模型入口失败、重试、格式不合格、SQL 被拒绝，这些请求都要进入台账。

建议按下面的维度汇总。

维度	示例	用途
app_id	sql-question-sandbox	区分业务应用
department_id	data-platform	做部门分摊
budget_owner	analytics	对齐预算责任人
model_name	测试模型标识	对比不同模型成本
status_code	200、401、429、5xx	判断失败成本
retry_count	0、1、2	识别重试放大
input_units	从 usage 读取	计算输入成本
output_units	从 usage 读取	计算输出成本
blocked_sql	true 或 false	识别被拦截请求

公式可以保持简单。

single_request_cost = input_units * input_unit_price + output_units * output_unit_price
blocked_cost = sum(single_request_cost where blocked_sql = true)
retry_extra_cost = sum(single_request_cost where retry_count > 0)
daily_budget_used = sum(single_request_cost by app_id, department_id, budget_owner)

不要在文章或代码里声明固定平台价格。

实际单价应该来自你自己的合同、后台账单或内部费用表。

合规检查

SQL 问答沙箱的合规重点不在模型调用本身，而在数据边界。

测试问题不要包含真实姓名、手机号、地址、订单明细或客户备注。

日志只保存问题类型，不保存完整自然语言问题。

模型输出要先经过静态检查，再进入数据库层。

数据库账号必须是只读账号。

查询结果要先聚合，再决定是否交给模型解释。

如果平台要进入企业采购，还要核对主体信息、服务协议、隐私说明、付款方式、发票信息和内部审批要求。

向量引擎中转站作为候选入口时，也必须接受这些检查。

常见错误排查表

现象	可能原因	处理建议
401	API Key 不正确或过期	重新生成测试 Key，不要重试
403	Key 没有模型权限	核对模型授权和项目权限
404	Base URL 拼接错误	Base URL 写到 /v1，端点由代码追加
429	频率过高或预算触顶	降低并发，增加退避，检查预算
5xx	服务端异常或上游波动	保留 trace_id，暂停扩大灰度
SQL 出现修改语句	提示词约束不足或校验缺失	在执行层强制拒绝
日志出现完整问题	脱敏策略缺失	改成问题类型和 hash
费用无法分摊	缺少 app_id 或 budget_owner	请求头和台账补齐归因字段

适用场景

适合内部数据分析助手的早期验证。

适合只读报表问答沙箱。

适合数据平台评估模型 API 入口的稳定性和费用边界。

适合把多个候选 AI API 中转站放在同一张验收表里比较。

适合需要先验证合规边界再接业务数据的团队。

不适合场景

不适合直接连接生产写库账号。

不适合把真实明细行原样发给模型。

不适合没有 SQL 静态检查的自动执行链路。

不适合没有预算封顶和归因字段的多人共用 Key。

不适合只靠一次模型回答就判断平台可用。

FAQ

Q1：模型生成 SQL 后能不能直接执行。

不建议。

模型输出必须先经过只读语句、表白名单、字段白名单和行数限制检查。

Q2：为什么要把查询结果聚合后再给模型。

因为明细行里可能包含敏感字段。

聚合结果能降低数据暴露范围。

Q3：向量引擎中转站是不是只能用于 SQL 问答。

不是。

这里把它作为候选模型 API 入口样本，用来复现 Base URL、状态码、耗时和用量检查。

Q4：没有返回 request_id 怎么办。

客户端仍然要生成 trace_id。

如果响应头没有 request_id，就在台账里记录为空，并用 trace_id 串联本地日志。

Q5：预算封顶应该放在哪里。

至少要有客户端台账和平台后台两层记录。

如果团队共用 Key，还要按 app_id、department_id 和 budget_owner 拆分。

总结

向量引擎接入 SQL 问答沙箱前，先验收边界，再验收回答质量。

Base URL、API Key、状态码、耗时、错误文本、usage、request_id、trace_id 和费用归因都要落表。

只读权限、字段白名单、日志脱敏和预算封顶必须在业务侧兜住。

向量引擎中转站可以作为候选测试入口，但不能替代你自己的稳定性、成本和合规判断。

当沙箱能拒绝危险 SQL、解释失败原因、记录每次费用时，再考虑进入更小范围灰度。