Jina API 完整指南（2026）

你可能最近几个月频繁在 RAG（检索增强生成）相关的技术讨论里看到"Jina AI"这个名字——但它不是那种一夜爆红、刷屏社交媒体的新玩具。如果单看 GitHub 星标数，Jina Reader 开源仓库约1.1万星标，连同类竞品 Firecrawl 的13万+星标一个零头都算不上。但过去十个月里，Jina AI 确实发生了两件足以让"RAG检索层怎么选"这件事重新被摆上台面的事：2025年10月9日，做 Elasticsearch、在纳斯达克上市的搜索基础设施公司 Elastic 正式完成对 Jina AI 的全资收购；被收购后，Jina 团队并没有停下模型发布的节奏，2026年2月和5月接连推出了两代新的 Embeddings 模型。

这篇文章想诚实地把这件事讲清楚：Jina API 现在为什么值得关注、它相对 Firecrawl / Tavily / Exa / Diffbot 这些竞品真正的优势和短板在哪、以及——用一条实测过的管线——怎么用它把一堆网页真正组装成一个能查询的领域知识图谱。提前说明：Jina 的产品线里没有"一键生成知识图谱"这个 API，那更接近 Diffbot 的定位。本文教程展示的是一条需要自己组装的 pipeline，Jina 负责其中的抓取与向量化两层。

一、Jina AI 是什么，以及被 Elastic 收购之后发生了什么

Jina AI（jina.ai）不做聊天补全，不跟 GPT/Claude 抢主战场。它深耕 RAG 工程中最关键但最容易被忽视的"检索层"三件套：Embeddings（嵌入）、Reranker（重排）、Reader（网页转干净文本），此外还有 Search（网页搜索）、DeepSearch、Classifier、Segmenter 等围绕同一体系的产品。所有产品共用同一个 API Key、同一个 Token 池，这是它区别于"单点嵌入服务商"（比如纯 Embeddings 的 Voyage AI）的核心设计。本站已有的 Jina AI API 测评覆盖了定价、免费额度等细节，这篇文章聚焦在"为什么关注它"和"怎么用它搭知识图谱"这两件事上。

2025年10月9日，Elastic（Elasticsearch 母公司，纳斯达克上市代码 ESTC）正式完成对 Jina AI 的全资收购，官方新闻稿称 Jina AI 是"多模态、多语言搜索前沿模型的领导者"。Jina AI 创始人兼原 CEO Han Xiao 在收购后出任 Elastic 的 VP of AI。Elastic 官方明确表态：会延续 Jina AI 此前"模型开源发布到 Hugging Face、持续发表学术研究"的做法——这意味着 Jina 的 Embeddings/Reranker/Reader 产品线目前是作为 Elastic"Search AI Platform"战略的一部分继续独立运营，而不是被雪藏或砍掉。

这次收购之后，Jina 的模型迭代并没有慢下来，反而保持了相当快的节奏：

• 2026年2月18日：发布 jina-embeddings-v5-text系列（small/nano两档），官方给出的 MTEB English v2 平均分为677M参数的small档71.7分、239M参数的nano档71.0分——是当时1B参数以下多语言嵌入模型里的最高分，支持119+种语言，最长32K tokens上下文
• 2026年5月11日：Elastic 官方发布 jina-embeddings-v5-omni，这是首个和 v5-text 共享同一向量空间的多模态模型——文本、图像、视频、音频都能编码进同一个向量空间，意味着已经用 v5-text 建好索引的用户，可以直接换上 omni 模型往同一套向量库里灌入图片/视频/音频，不需要重新建索引

这两件事合起来构成了本文对"为什么现在值得关注"的核心论据——不是社交媒体爆红，而是一次真实发生的企业收购整合，加上收购之后依然保持的 SOTA 模型发布节奏。下一节会把这一点和"是否真的算得上大火"这个问题拆开来诚实讨论。

二、为什么现在值得关注 Jina API：三个可验证的理由

先把话说清楚：如果用 GitHub 星标数或者社交媒体声量去衡量，Jina Reader 目前不是这个赛道里声量最大的选手。我们在做这篇文章的调研时专门核实过——Firecrawl 的开源仓库星标数已经超过13万，是 GitHub 全站 Top 100 级别的项目；而 Jina Reader 自己的开源仓库星标数约1.1万-1.2万，量级上差了一个数量级。所以"Jina API 最近大火"如果按字面理解成"短期内爆发式走红、声量压过对手"，并不成立——这一点本文选择如实说明，而不是为了呼应一个更抓眼球的标题而回避它。

但换一个更准确的问题——"Jina API 现在是不是仍然值得 RAG 开发者花时间关注"——答案是肯定的，而且有三条经得起核实的理由：

1. 被更大的基础设施玩家收购并持续投入，是比"病毒式传播"更实的信号

一家独立运营的 RAG 检索层创业公司被 Elastic 这样体量的搜索基础设施上市公司整体收购，本身就是一种验证——它说明 Jina 的技术栈被判断为"值得整合进企业级搜索平台核心能力"，而不是一个孤立的开发者玩具。收购完成之后 Elastic 明确承诺延续开源发布节奏，创始人转任收购方的 VP of AI 而不是套现离场，这些细节共同指向一个相对稳定的信号：至少在可预见的未来，Jina 的 API 产品线大概率会继续被维护和投入，而不是被砍掉或束之高阁。这是"企业级基础设施收购整合"式的关注度，和"一夜刷屏"是两种完全不同性质的热度，但对于要做技术选型的开发者来说，前者反而是更值得纳入决策的信号。

2. 收购后模型发布节奏没有放缓，且拿到了可验证的跑分成绩

很多公司被收购后会经历产品线整合的沉寂期，但 Jina/Elastic 这条线目前没有出现这种情况——v5-text（2026年2月）和 v5-omni（2026年5月）两次发布间隔不到三个月，且 v5-text 拿到了"1B参数以下多语言嵌入模型 MTEB 最高分"这样具体可复核的成绩（官方与 Hugging Face 模型卡交叉确认），v5-omni 则是"文本/图像/视频/音频共享同一向量空间"这个方向上少见的技术尝试。这说明收购没有拖慢产品迭代，反而可能因为 Elastic 的资源投入让节奏更稳定。

3. 结构性差异化本身没有过时——它一直都在，只是现在有了更强的背书

Jina 长期以来的几个技术卖点在2026年依然成立，也依然是同类产品里少见的组合：Embeddings + Reranker + Reader 共享同一个 API Key 和同一个免费 Token 池（10M tokens，无需信用卡）、Embeddings 支持 Late Chunking（对整篇长文档一次性编码保留跨块上下文，再切分出分块向量）和 Matryoshka 表征学习（向量可按需截断到更低维度节省存储）。这些不是2026年才出现的新特性，但它们的组合在"检索层全家桶"这个细分里目前仍然少见——本文第三节会把这些和竞品逐条对比，不回避 Jina 现在明显落后的地方。

三、Jina API vs 竞品：优势、短板与诚实的对比

"URL/网页 → LLM-ready 干净内容 + 向量化"这个细分赛道，到2026年中已经是一个至少三个梯队、十几个玩家同时在打的拥挤市场——正面直接竞品包括 Firecrawl、Exa、Tavily、Diffbot、Spider.cloud 等，通用爬虫服务商（ScrapingBee、ScraperAPI）也纷纷加上了"输出 Markdown 给 LLM 用"的功能。下面是核实过的横向对比。

Jina 相对站得住脚的优势

• 唯一把"嵌入+重排+抓取"打包进同一账号体系的供应商：Firecrawl/Tavily/Exa/Diffbot 都是独立计费体系，即使同时使用也要分别管理额度和账单；Jina 用同一个 Key、同一个10M免费Token池覆盖三个环节，对已经在用 Jina Embeddings/Reranker 的团队，Reader 是"顺手多一个端点"而不是"另开一个账户"
• URL前缀直转的极简调用方式：r.jina.ai/<目标URL>，GET请求不需要JSON body、不需要SDK，本文第四节会实测这一点——匿名调用都能直接跑通，这一点比大多数竞品（都要求POST JSON body + Header里带Key）更轻量
• 自托管版本目前没有发现被阉割的证据：Firecrawl 官方明确承认自托管版缺失云端专有的反爬引擎（Fire-engine）、Agent端点、浏览器沙箱；本次调研没有找到 Jina 官方关于其自托管版功能阉割的说明——这不代表"Jina 一定更完整"（没有等价的逐项功能清单做直接比对），但至少没有发现反例

诚实承认：竞品明显领先的地方

• 开源生态体量差了一个数量级：Firecrawl 13万+星标 vs Jina Reader 约1.1万星标，社区活跃度、第三方集成（LangChain/LlamaIndex生态位）大概率也随之更强
• 按页/按请求计费比按token计费更容易预估成本：Firecrawl/Tavily/ScrapingBee 等多数竞品用"每页固定credit"或"每请求固定价"计费，长页面场景下 Jina 按token计费的实际花费不容易提前估算；Jina 官方定价页本次核实时返回404，具体单价请以登录后的 Dashboard 当前页面为准，不建议直接假设某个固定数字
• 搜索+提取一步到位的产品正在蚕食"要不要单独调Reader"这个需求本身：Tavily Extract、Exa Contents、Brave 的 LLM Context 端点都能"先搜索、按需提取"一次调用搞定；Jina 虽然也有独立的 Search API（s.jina.ai），但 Search 和 Reader 是两个分开的端点，没有把"检索+抽取"合并成单一响应。另外 Google Gemini API 的 URL Context 工具已在2026年转为正式GA，允许模型直接读取URL，这对包括 Jina Reader 在内的整个"独立Reader API"赛道都是长期结构性压力
• Diffbot 才是"知识图谱"这个词真正对应的产品：Diffbot 有专门的 Knowledge Graph 产品和 Natural Language API，这是 Jina 完全没有的能力，只是 Diffbot 定位更偏企业级、起步付费档 $299/月，价格门槛明显更高。这也是本文标题不敢说"用Jina API一键生成知识图谱"的原因——下一节会诚实说明这件事到底怎么做

一句话总结：如果你已经在用 Jina Embeddings/Reranker 做检索层，Reader 是几乎零边际成本的补充；如果你需要的是成熟的开源生态、可预测的按页定价，或者搜索+提取一步到位，Firecrawl/Tavily 在各自的强项上确实更值得考虑；如果你需要的是开箱即用的知识图谱产品而不是自己拼一条 pipeline，Diffbot 更接近你要的东西，但要接受更高的价格门槛。

四、快速上手：认证、限速与最简单的调用

4.1 获取 API Key

官网 jina.ai/?sui=apikey 一键生成，无需信用卡。每个新 Key 自带 10M tokens 免费额度，在 Embeddings / Reranker / Reader 三个产品间共享同一个 Token 池——如果 Embeddings 跑批量任务把额度提前用完，Reader 也会同时受影响。免费额度官网标注为非商用性质，具体条款以 Dashboard 当前页面为准。

4.2 认证方式

所有 API 统一使用标准 Bearer Token：

Authorization: Bearer $JINA_API_KEY

4.3 速率限制

4.4 最简单的调用：Reader，连Key都不用

Reader 最直观的设计：把目标URL直接拼在 https://r.jina.ai/ 后面，GET请求，不需要任何Header，不需要API Key。我们为这篇文章现场实测了这一点（2026年7月19日）：

curl "https://r.jina.ai/https://en.wikipedia.org/wiki/Retrieval-augmented_generation"

真实返回结果：HTTP 200，耗时约2.85秒，响应头 x-usage-tokens: 7486（消耗token数），x-ratelimit-limit: 20, 20;w=60——这条响应头直接印证了"匿名调用限速20次/60秒"这个文档记载的数字，不需要Key就能验证到。返回内容开头（真实节选，未做任何编造）：

Title: Retrieval-augmented generation

URL Source: https://en.wikipedia.org/wiki/Retrieval-augmented_generation

Published Time: 2023-11-05T13:19:20Z

Markdown Content:
From Wikipedia, the free encyclopedia

**Retrieval-augmented generation** (**RAG**) is a technique that enables
large language models (LLMs) to retrieve and incorporate new information
from external data sources. With RAG, LLMs first refer to a specified
set of documents, then respond to user queries...

可以看到返回内容是固定的三段式结构：Title / URL Source / Markdown Content，本次抓取的页面还带出了 Published Time 字段（并非每个页面都有，取决于目标页面本身是否携带发布时间元数据）。第五节的教程会基于这次真实抓取继续往下搭。

五、教程：用 Jina API 搭建你自己的领域知识图谱

5.1 整体管线设计

五步流程，每一步各自的职责边界要分清楚：

领域文档URL列表
   │
   ▼
Step 1  Jina Reader 批量抓取          → 干净Markdown文本
   │
   ▼
Step 2  LLM 做实体/关系抽取           → 结构化JSON（entities + relations）
   │        （Jina不提供这一层，需自带LLM）
   ▼
Step 3  Jina Embeddings 向量化实体    → 用于语义去重/合并相似实体
   │
   ▼
Step 4  组装成图结构                 → JSON节点边 / NetworkX / Neo4j
   │
   ▼
Step 5  查询/子图检索                → 拼进下游RAG的Prompt上下文

5.2 Step 1：用 Jina Reader 批量抓取领域文档（真实实测）

我们用两个真实的 Wikipedia 页面模拟"一个小型领域语料库"——Retrieval-augmented generation 和 Vector database，实际使用时把 DOMAIN_URLS 换成你自己领域的真实文档（公司Wiki、产品文档、论文页面均可）：

import requests

DOMAIN_URLS = [
    "https://en.wikipedia.org/wiki/Retrieval-augmented_generation",
    "https://en.wikipedia.org/wiki/Vector_database",
    # 换成你自己领域的真实文档URL
]

JINA_API_KEY = None  # 匿名也能跑（限速20 RPM），生产环境建议换成你的Key（免费Key下500 RPM）

def fetch_clean_text(url: str) -> dict:
    headers = {"X-Return-Format": "markdown"}
    if JINA_API_KEY:
        headers["Authorization"] = f"Bearer {JINA_API_KEY}"
    resp = requests.get(f"https://r.jina.ai/{url}", headers=headers, timeout=60)
    resp.raise_for_status()
    return {
        "url": url,
        "tokens_used": resp.headers.get("x-usage-tokens"),
        "text": resp.text,
    }

corpus = [fetch_clean_text(u) for u in DOMAIN_URLS]
for doc in corpus:
    print(doc["url"], "→", doc["tokens_used"], "tokens")

本次实测结果（2026年7月19日，匿名调用，未使用Key）：抓取 Retrieval-augmented generation 页面，HTTP 200，耗时约2.85秒，消耗 7,486 tokens，解压后正文 28,779 字节；抓取 Vector database 页面，消耗 11,581 tokens，正文 41,572 字节。两次调用的 x-ratelimit-limit 都返回 20, 20;w=60，验证了匿名限速20次/60秒这一点。这不是文档转述，是这篇文章实际跑出来的真实数字。

5.3 Step 2：用 LLM 做实体与关系抽取

这是整条管线里 Jina 不提供的一环，必须自带LLM。下面用OpenAI SDK兼容的调用格式做示例——base_url 可以换成任意兼容OpenAI协议的模型或中转站，不需要绑定某一家：

from openai import OpenAI

# base_url换成你正在用的模型/中转站地址，model换成对应可用的模型名
# 本站测评过多个性价比不错的选项（GLM-5.2、DeepSeek等），见文末"相关推荐"
client = OpenAI(api_key="你的Key", base_url="https://你的中转站或官方地址/v1")

EXTRACTION_PROMPT = """你是一个知识图谱抽取引擎。给定一段文本，抽取其中的实体（entities）和实体间关系（relations），严格按以下JSON格式输出，不要输出任何多余文字：

{
  "entities": [
    {"id": "唯一ID", "name": "实体名称", "type": "PERSON|ORG|CONCEPT|TECHNOLOGY|EVENT", "description": "一句话描述"}
  ],
  "relations": [
    {"source": "实体ID", "target": "实体ID", "relation": "关系描述，用动词短语"}
  ]
}

文本：
{chunk}
"""

def extract_entities_relations(chunk: str, model: str = "your-model-name") -> dict:
    import json
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": EXTRACTION_PROMPT.format(chunk=chunk)}],
        response_format={"type": "json_object"},
        temperature=0
    )
    return json.loads(response.choices[0].message.content)

如实说明：本次任务环境没有可用的LLM API Key，下面这段"输出示例"不是真实调用某个模型得到的结果，而是照着5.2节真实抓取到的正文人工写出来的示范，用来说明期望的输出形态：

{
  "entities": [
    {"id": "e1", "name": "Retrieval-Augmented Generation", "type": "TECHNOLOGY", "description": "让LLM在生成前先检索外部文档的技术"},
    {"id": "e2", "name": "Large Language Model", "type": "TECHNOLOGY", "description": "大语言模型"},
    {"id": "e3", "name": "Vector Database", "type": "TECHNOLOGY", "description": "存储和检索向量嵌入的数据库"},
    {"id": "e4", "name": "AI Hallucination", "type": "CONCEPT", "description": "模型生成不实内容的现象"}
  ],
  "relations": [
    {"source": "e1", "target": "e2", "relation": "增强"},
    {"source": "e1", "target": "e3", "relation": "依赖"},
    {"source": "e1", "target": "e4", "relation": "缓解"}
  ]
}

5.4 Step 3：用 Jina Embeddings 向量化实体，做语义去重与链接

多篇文档抽取出的实体经常会出现"同一个东西、不同措辞"的情况（比如"RAG"和"Retrieval-Augmented Generation"）。用 Embeddings 把每个实体的名称+描述向量化后算余弦相似度，可以把它们合并成同一个节点。以下同样是根据官方API文档写的示例代码，本次未实际调用（需要真实Key）：

import requests

def embed_texts(texts: list, jina_api_key: str, task: str = "retrieval.passage") -> list:
    resp = requests.post(
        "https://api.jina.ai/v1/embeddings",
        headers={
            "Authorization": f"Bearer {jina_api_key}",
            "Content-Type": "application/json"
        },
        json={
            "model": "jina-embeddings-v5-text-small",
            "input": texts,
            "task": task,
            "normalized": True
        }
    )
    resp.raise_for_status()
    return [d["embedding"] for d in resp.json()["data"]]

entity_texts = [f"{e['name']}: {e['description']}" for e in entities]
entity_vectors = embed_texts(entity_texts, JINA_API_KEY)

import numpy as np

def cosine_sim(a, b):
    a, b = np.array(a), np.array(b)
    return float(a @ b / (np.linalg.norm(a) * np.linalg.norm(b)))

def merge_similar_entities(entities, vectors, threshold: float = 0.88):
    """相似度超过阈值的实体视为同一节点合并
    （比如不同文档里的"RAG"和"Retrieval-Augmented Generation"）"""
    merged, used = [], set()
    for i, e in enumerate(entities):
        if i in used:
            continue
        group = [i]
        for j in range(i + 1, len(entities)):
            if j not in used and cosine_sim(vectors[i], vectors[j]) >= threshold:
                group.append(j)
                used.add(j)
        merged.append({**entities[i], "aliases": [entities[k]["name"] for k in group[1:]]})
    return merged

5.5 Step 4：组装成图结构

最简单的形态是一个JSON节点边结构，这一步不依赖任何外部API，是纯数据整理，可以直接跑：

import json

def build_graph(all_entities, all_relations):
    nodes = [
        {"id": e["id"], "label": e["name"], "type": e["type"], "description": e["description"]}
        for e in all_entities
    ]
    edges = [
        {"source": r["source"], "target": r["target"], "label": r["relation"]}
        for r in all_relations
    ]
    return {"nodes": nodes, "edges": edges}

graph = build_graph(merged_entities, all_relations)
with open("domain_knowledge_graph.json", "w", encoding="utf-8") as f:
    json.dump(graph, f, ensure_ascii=False, indent=2)

print(f"节点数: {len(graph['nodes'])}, 边数: {len(graph['edges'])}")

如果数据量变大需要图查询能力，可以换成 NetworkX（纯内存，适合中小规模）：

import networkx as nx

G = nx.DiGraph()
for n in graph["nodes"]:
    G.add_node(n["id"], **n)
for e in graph["edges"]:
    G.add_edge(e["source"], e["target"], label=e["label"])

list(G.successors("e1"))  # 查询某实体的所有一跳邻居

需要持久化存储、多用户并发查询、或者图规模较大时，换成 Neo4j：

from neo4j import GraphDatabase

driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password"))

def load_into_neo4j(graph):
    with driver.session() as session:
        for n in graph["nodes"]:
            session.run(
                "MERGE (e:Entity {id: $id}) SET e.name = $name, e.type = $type",
                id=n["id"], name=n["label"], type=n["type"]
            )
        for e in graph["edges"]:
            session.run(
                "MATCH (a:Entity {id: $source}), (b:Entity {id: $target}) "
                "MERGE (a)-[r:RELATION {label: $label}]->(b)",
                source=e["source"], target=e["target"], label=e["label"]
            )

5.6 Step 5：查询子图，喂给下游 RAG

知识图谱搭好之后最常见的用法，是在回答用户问题时，先用向量检索定位相关实体，再沿边扩展N跳邻居，把子图关系拼成结构化上下文，补充给普通的向量检索结果一起送进LLM：

def query_graph(question_vector, graph, entity_vectors, top_k: int = 3):
    sims = [
        (node["id"], cosine_sim(question_vector, vec))
        for node, vec in zip(graph["nodes"], entity_vectors)
    ]
    top_nodes = sorted(sims, key=lambda x: -x[1])[:top_k]

    context_lines = []
    for node_id, _ in top_nodes:
        neighbors = [e for e in graph["edges"] if e["source"] == node_id or e["target"] == node_id]
        for e in neighbors:
            context_lines.append(f"{e['source']} --{e['label']}--> {e['target']}")
    return "\n".join(context_lines)

# 把返回的结构化关系文本拼进最终prompt，作为普通向量检索结果之外的补充上下文

5.7 小结：这条管线里每一层各自的责任

六、常见坑点与国内访问

• 三产品共享同一Token池：Embeddings批量任务把免费额度提前用完，Reader/Reranker也会同时受影响，做容量规划要按总量而不是分产品估算
• 免费额度是非商用性质：如果要上生产/商用项目，官网标注免费的10M tokens在合规角度可能不适用，建议以Dashboard当前条款为准
• Reader的X-Timeout上限180秒：抓取重度JS渲染或反爬页面容易超时，可以配合X-Engine: browser强制走浏览器引擎
• 大批量向量化用Batch Embeddings API而不是同步接口：POST /v1/batch/embeddings提交任务、轮询状态、下载JSONL结果，比同步/v1/embeddings更适合"一次性把整个知识库全量灌入向量"这类场景
• 国内访问需要代理：Jina官方GitHub仓库jina-ai/reader的Issue列表里有一条标题为"Jina Reader 和 Search 被墙了"的社区反馈，说明至少有用户反映r.jina.ai/s.jina.ai在国内网络下不可达，但没有找到官方对此的正式声明或长期状态确认。国内团队可以走本地代理，或者通过Chutes等已接入Jina嵌入端点的AI API中转站间接访问，格式兼容OpenAI SDK

七、常见问题

Q：Jina API 真的可以"一键生成知识图谱"吗？

A：不能。Jina的产品线里没有这个功能，那更接近Diffbot的Knowledge Graph产品定位。本文第五节展示的是一条需要自己组装的pipeline：Jina负责抓取和向量化，实体/关系抽取必须自带LLM，图存储和查询也需要自己选型（JSON/NetworkX/Neo4j）。

Q：Jina 被 Elastic 收购后，API会不会突然涨价或者关停？

A：截至本文调研时（2026年7月），官方口径是继续独立运营、延续开源发布节奏，第三方评测站也确认Reader/Embeddings/Reranker API仍在正常维护、定价结构未发生重大变化。但任何被收购的产品线都存在长期方向调整的可能，建议关注官方公告，不要把某个时间点的定价当作永久承诺。

Q：不用API Key能跑通这篇教程的哪些部分？

A：第五节的Step 1（Jina Reader抓取）完全可以匿名跑通，限速20次/60秒，本文的实测数据就是匿名调用得到的。Step 3（Jina Embeddings向量化）和Step 2（LLM抽取）都需要各自的API Key。

Q：免费的10M tokens额度够搭一个小型领域知识图谱吗？

A：从本文实测数据看，两个中等长度的Wikipedia页面（约3万-4万字节正文）合计消耗约1.9万tokens，10M额度理论上可以覆盖几百个同等量级的页面用于Reader抓取；但这个额度是Embeddings/Reranker/Reader共享的，如果同时用Embeddings给大量实体做向量化，实际能覆盖的页面数会明显减少，建议先用免费额度跑通小规模验证，再评估是否需要升级付费Key。

Q：一定要用Jina Embeddings做实体向量化吗？能不能换成别的嵌入模型？

A：完全可以换。第五节Step 3的向量化逻辑（相似度合并实体）对嵌入模型没有强绑定，只要是能输出稠密向量的Embeddings API都能替换进去。选Jina的理由主要是它和Reader共享同一账号体系，如果你已经在用Jina Reader抓取，顺手用Jina Embeddings做向量化能省一次额外的账户管理。

八、总结