边缘侧 LLM 扩展指南：从提示词蒸馏到向量嵌入的优化之路

在生产环境中部署大语言模型（LLM）绝不仅仅是调用一个 API 端口那么简单。当我们开发 Wu Wei Planner（一款为实体引导卡片设计的 AI 助手）时，面临的核心挑战并非 AI 的智力水平，而是经济成本与响应延迟的残酷现实。由于我们设定了每位用户 2 美元的终身预算上限，每一个 Token 的消耗都必须精打细算。

为了实现这一目标，我们利用了 n1n.ai 这一领先的 LLM API 聚合平台，快速接入了 GPT-4o-mini 和 Claude 3.5 Sonnet 等高性能模型。本文将详细记录我们如何将 17,000 Token 的臃肿提示词，优化为基于向量嵌入（Embeddings）和 Cloudflare Workers 的高效架构。

边缘侧的基础架构选择

该项目完全运行在 Cloudflare Workers 上。对于追求“零冷启动”性能的开发者来说，边缘计算（Edge Computing）是唯一的逻辑选择。通过在全球 200 多个节点部署逻辑，我们确保了提示词组装和 API 调用代码在物理距离上尽可能靠近用户。

Cloudflare Workers 的一个独特优势是其原生支持流式传输（Streaming）。当我们通过 n1n.ai 调用 DeepSeek-V3 或 OpenAI o3 时，Worker 可以将流式响应直接导向客户端。即使在处理复杂查询时，也能显著降低用户的感知延迟。

第一阶段：暴力注入与 Token 陷阱

起初，我们尝试将所有资料一股脑塞给 AI：50 张卡片的详细描述、15 种职业背景以及心理干预指南，总计约 17,000 Token。虽然像 GPT-4o 这样的现代模型可以轻松处理长上下文，但在对话界面中，这种做法是致命的。

在有状态的对话中，历史记录会不断累积。如果基础上下文是 17k，第 1 条消息是 17k，第 10 条就是 20k，到第 20 条可能高达 25k。按照标准计费，一个 20 轮的对话可能耗费 0.08 美元。在 2 美元的总预算下，用户仅能进行 25 次对话。我们必须寻找一种不牺牲质量的扩展方案。

第二阶段：提示词蒸馏（AI 对 AI 的沟通）

人类需要华丽的辞藻，而 LLM 只需要语义核心。我们意识到，原本为人类阅读编写的 300 字卡片描述包含大量冗余。于是我们采用了“提示词蒸馏”（Prompt Distillation）技术，剔除所有“废话”。

原始上下文（约 300 Token）： “火代表了激情与毁灭。它既可以是破坏性的力量，也可以是温暖社区的元素。引导者应当为这种双重性留出空间……”

蒸馏后上下文（约 100 Token）： CARD:Fire | kw:passion,intensity,chaos,transformation | !caution:trauma | core:Duality (gen/dest) | prompts:这段火让你联想到了什么？

通过对整个知识库进行蒸馏，系统提示词从 17k 降至 12k。虽然节省了 30%，但仍未达到我们的成本目标。

第三阶段：路由器的失败尝试

随后我们尝试了“LLM 路由器”方案。思路是先用一个廉价且快速的模型（如通过 n1n.ai 调用的 Gemini 1.5 Flash）分析用户意图，决定注入知识库的哪一部分。

然而，我们遇到了两个瓶颈：

1. JSON 格式错误：即使是顶级模型，偶尔也会漏掉括号或转义符，导致 20% 的请求在编排层报错。
2. 串行延迟：路由器调用耗时 4-5 秒，主模型再耗时 1-2 秒。在首字弹出前等待 6 秒，这在现代 UX 设计中是不可接受的。

第四阶段：向量嵌入（RAG）的终极方案

这引出了我们最终的稳定架构：利用本地向量相似度实现的检索增强生成（RAG）。我们不再让 LLM 去“选择”上下文，而是使用 text-embedding-3-small 将用户查询转化为 1536 维的向量。

我们将 50 张卡片和 15 种职业的向量预先计算好，存储在一个 300kb 的静态 JSON 文件中。当用户发送消息时：

1. 为查询生成嵌入向量（< 20ms）。
2. 针对本地 300kb 文件运行余弦相似度（Cosine Similarity）计算（< 5ms）。
3. 仅将匹配度最高的前 3 张卡片和 1 个职业背景注入提示词。

余弦相似度核心逻辑：

function cosineSimilarity(a, b) {
  let dot = 0, normA = 0, normB = 0;
  for (let i = 0; i < a.length; i++) {
    dot += a[i] * b[i];
    normA += a[i] ** 2;
    normB += b[i] ** 2;
  }
  return dot / (Math.sqrt(normA) * Math.sqrt(normB));
}

通过这种架构，Token 的额外开销从 12,000 降到了仅 150（查询向量的开销）。这让我们在同样的 2 美元预算下，能为用户提供数百次高质量对话。

使用 LLM-as-a-Judge 进行质量控制

在解决了速度和成本问题后，我们开始关注质量。利用 promptfoo 和 llm-rubric 评估标准，我们对响应进行了分级。我们不再仅仅检查关键词，而是使用一个“裁判 LLM”来评估响应是否符合“无为（Wu Wei）”哲学（非指令性、隐喻性、温暖感）。

如果裁判认为回复过于机械，我们会调整系统提示词。得益于 n1n.ai 提供的多样化模型选择，我们可以不断微调 Wu Wei Planner 的性格，直到它听起来像一个真正的引导者。

边缘侧 LLM 扩展专业建议

1. 阈值校准：不要盲目相信默认的 0.7 相似度阈值。对于隐喻性内容，0.3 或 0.4 通常是更合适的甜点位。
2. 一个模型优于两个：尽可能避免串行调用。使用向量嵌入进行检索，配合一个强大的推理模型（如 GPT-4o-mini）即可。
3. 预计算一切：如果你的数据集小于 1MB，不需要向量数据库。Cloudflare Worker 中的静态 JSON 文件更快且更省钱。

在 n1n.ai 获取免费 API 密钥。