嵌入

用于向量检索、语义搜索、知识库切片等场景。

嵌入接口不是用来直接“聊天”的。它更像是把文本变成可检索的向量表示，常见于知识库、RAG、语义搜索和相似内容召回。

很多新手第一次看这个接口时，会把“模型返回一串很长的数字”误以为接错了。其实这恰恰说明方向是对的：
嵌入接口要的不是一句自然语言回答，而是一组后续可比较、可检索的向量数据。

第一次建议怎么测

第一次不要直接拿整份知识库去压它，先用一条很短的文本：

• 长度短，容易确认请求格式没问题
• 返回快，方便先看字段结构
• 便于你后面和批量请求做对照

先证明“单条文本能稳定产出向量”，再继续做批量入库，会比一上来就塞几十段文本更容易排障。

创建嵌入 POST

地址：POST https://xiaolan.ainb.plus/v1/embeddings

常用请求参数

• model：嵌入模型
• input：文本或文本数组

示例请求

先把 MODEL 替换成模型广场里实际可用的嵌入模型名：

MODEL="替换成模型广场里的嵌入模型名"

curl https://xiaolan.ainb.plus/v1/embeddings \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <你的 API Key>" \
  -d '{
    "model": "'"$MODEL"'",
    "input": "小蓝中转站"
  }'

响应

向量数据一般在 data[0].embedding。

只要你已经拿到 data[0].embedding，就说明这把 Key、当前模型和嵌入链路已经通了。

第一次成功后，可以顺手记两件事：

1. 当前向量维度是多少
2. 你准备把这批向量存到哪里

因为后面一旦更换嵌入模型，最先受影响的通常就是向量维度和下游索引结构。

使用建议

• 批量请求时注意单次输入长度
• 模型换了，旧向量通常也要重新生成
• 同一个知识库尽量固定同一个嵌入模型
• 入库前先清洗无意义空白和重复内容
• 批量请求失败时，先缩小 batch 大小

如果你在做知识库切片，再补一条更实用的经验：
一段文本最好围绕一个相对完整的小主题。太长会把重点摊薄，太短又容易只剩碎片词，后面的检索效果都不会太理想。

批量输入

MODEL="替换成模型广场里的嵌入模型名"

curl https://xiaolan.ainb.plus/v1/embeddings \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <你的 API Key>" \
  -d '{
    "model": "'"$MODEL"'",
    "input": ["第一段文本", "第二段文本"]
  }'

响应里的 data 顺序通常和输入数组一致。

这意味着你可以按相同顺序把向量和原始文本一一对应回去。

也正因为顺序是一一对应的，批量入库时最好同时保留原文、分片 ID 和来源信息。
后面检索结果不理想时，你才能追到“到底是哪一段文本、哪一种切片方式”出了问题。

常见问题

向量维度不一致

不同嵌入模型的维度可能不同。换模型后，旧向量库通常要重新生成。

检索效果差

优先检查切片质量。段落太长、太短或重复内容太多，都会影响效果。

如果切片本身没明显问题，再继续看两层：

• 检索阶段是不是混用了另一种嵌入模型生成的旧向量
• 问题文本和知识库文本的语言、格式是否差异太大

为什么换了模型后要重建向量

因为不同嵌入模型生成的向量空间通常不一样。混用旧向量和新向量时，检索结果往往会明显变差。