企业官网建设流程全解析

• 人工智能
• AI 应用
• 大模型
• 后端

pg-jev 是一款 PostgreSQL 扩展，让你用一句自然语言（jev(people, 'the name is European')）就能过滤、排序和分类表中的每一行，背后由 TypeSafe 的 Jev 模型驱动。但默认情况下，行数据要发到云端 API 才能被"读懂"——如果这些数据你根本不允许出内网怎么办？本文带你完整走一遍 pg-jev 的数据隐私方案：接入本地 Jev 兼容服务器（stuntd 或 laya-server），让表数据全程留在内网，同时告别按行计费的账单。

为什么 pg-jev 需要一套数据隐私方案

先用一张图理解默认的数据流向：

┌──────────────┐ HTTPS (公网) ┌─────────────────────┐ │ PostgreSQL │ ────────────────▶ │ TypeSafe 云端 API │ │ (你的表数据) │ ◀──────────────── │ (第三方服务) │ └──────────────┘ 判断结果 └─────────────────────┘

默认配置下，jev()会把行内容打包发往https://api.typesafe.ai/v1/systemone，由 Jev 模型逐行给出 0~1 的概率判断。这带来两个对内部部署很敏感的问题：

• 数据会离开自己的网络：项目作者在 README.md 的 Caveats 一节中明确提醒——行内容会被发送到第三方 API，"不要用在你不被允许分享的数据上"。
• 按行计费：每次判断都消耗 token，云端服务按量计费，查询量一大账单就上去了。

而 pg-jev 0.2.1 版本专门补齐了这一点：只要jev.api_url不是*.typesafe.ai域名，就不再强制要求 API key，请求不带认证头直接发出（详见 CHANGELOG.md）。这让"整条链路都在内网里跑"成为官方支持的一等公民用法。

原理：pg-jev 如何让数据不出内网 📡

整个隐私方案的原理非常简洁，只依赖一个设置项jev.api_url：

jev.api_url可以指向任何实现了相同POST /v1/systemone请求契约的服务器——于是行数据永远不会离开你的网络，也没有按行计费（原文见 README.md 的 "Local Jev-compatible servers" 一节）。

切换后的数据流向变成：

┌──────────────┐ HTTP (仅内网) ┌─────────────────────────┐ │ PostgreSQL │ ──────────────▶ │ 本地 Jev 兼容服务器 │ │ (你的表数据) │ ◀────────────── │ stuntd / laya-server │ └──────────────┘ 判断结果 └─────────────────────────┘

官方点名了两个兼容服务器：

对 pg-jev 来说，"谁在算"并不重要——它只关心对方说的是不是同一种"语言"（同一套/v1/systemone请求格式）。判断逻辑、批量流式读取、会话缓存这些机制在本地模式下完全一样，性能表现也不变。

接入步骤：3 步把 pg-jev 切到内网端点 ⚡

前提：已完成 pg-jev 安装（PostgreSQL 14–17 +plpython3u，jev.control 中有声明），扩展已创建。

第 1 步：在内网部署一台 Jev 兼容服务器

部署 stuntd（或 laya-server）到内网机器上，确认它监听/v1/systemone路径。stuntd 默认就是http://127.0.0.1:8787/v1/systemone。

第 2 步：把jev.api_url指向本地端点

这是一个普通 GUC，可以按会话、角色或库设置，也可以写进postgresql.conf：

SET jev.api_url = 'http://127.0.0.1:8787/v1/systemone'; -- stuntd 默认地址

第 3 步：不用配 API key，直接查

0.2.1 起，对非*.typesafe.ai端点，jev.api_key是可选的——没设置就不带Authorization头，请求照常发出：

SELECT * FROM people WHERE jev(people, 'the name is European');

如果本地服务自己也要求鉴权，把 key 设上即可，pg-jev 会照旧以Bearer <key>带上。注意一个细节：只要主机名是*.typesafe.ai，key 就是强制的，且会在发请求前就报错——所以内网端点要确保域名不是 typesafe.ai 的托管域名。

最快验证方式：用仓库自带的 mock 服务器零成本试水 🧪

不想先部署 stuntd？仓库里自带一个确定性的 mock API，正是用来跑回归测试的：

python3 test/mock_api.py # 监听 127.0.0.1:8765

mock_api.py 在/local/路径下接受不带认证头的请求，模拟的正是"本地 Jev 兼容服务器"这种场景。官方回归测试 test/sql/04_local.sql 就演示了完整链路：

SET jev.api_key = ''; SET jev.api_url = 'http://127.0.0.1:8765/local/v1/systemone'; SELECT name FROM local_cities WHERE jev(local_cities, 'the country is Germany') ORDER BY id;

跑通这条 SQL，就等价于验证了"无 key + 本地端点"的完整隐私链路。CI 里用的 test/run.sh 和 test/Dockerfile 也是同一套路：临时数据库 + mock API，全程零外部调用。

切到本地服务器后的三个注意点 ✅

1. jev_stats()里的成本仍是"标价"：token 计数和费用估算一律按 TypeSafe 官方价目表计算，与服务器是谁无关。内网部署下把它当作用量参考即可，真实成本是你的机器的电费。
2. 性能机制完全保留：批量（默认 20 行/请求）、并发、持久连接、LIMIT提前停止读取等优化在本地模式下一样生效，sql/jev--0.2.1.sql 中扩展主体没有区分"云端/本地"两套逻辑。
3. 隐私边界变成了"你信任谁"：数据不再流向第三方，但会流向你自己部署的模型服务器。如果模型侧要记录答案、做训练（例如 stuntd 的本地训练能力），请确认这些行为符合你的数据治理要求。

常见问题 📮

问：接入本地服务器后，查询会变慢吗？答：取决于你的内网延迟。云端场景下首次请求含 TLS 握手和服务器端初始化（实测可达 1~1.9 s），而内网同机房部署通常远低于这个值；批量与并发机制也都在，整体体验往往更好。

问：能云端和本地混着用吗？答：可以。jev.api_url是会话/角色/库级别的设置，不同会话可以各指各的端点——敏感表走本地，公开表走云端，按数据分级灵活安排。

问：本地模型的效果和云端 Jev 一样吗？答：pg-jev 只负责把行打包成标准请求，判断质量由端点背后的模型决定。stuntd 还允许答案数据回流本地训练，长期看同一张表的判断会越来越贴合你的业务。

总结

pg-jev 用一句 SQL 换来自然语言查询能力，而数据隐私方案只多了一句 SQL：SET jev.api_url指向内网的 stuntd 或 laya-server，表数据便永不出内网，计费也归零。对于有合规要求的团队，这是把"用 AI 查库"和"数据不出门"这两件看似冲突的事同时拿到的最短路径。

• 人工智能
• AI 应用
• 大模型
• 后端