假设你经营一家“云上婚介所”，客户把简历寄到总部，由一套精装修的画像系统给每个人生成“性格画像”——几十个维度，如幽默感、责任心、旅行偏好……画像相近的人被推荐在一起。这套系统又快又准，但有个痛处：客户资料必须全部寄到总部，路途遥远、隐私堪忧，高峰期还得排队等结果。 现在，你决定把这位“画像师”请到客户家里。他随身只带一个轻便工具箱，进门后现场画像、现场匹配、当场出结果——资料根本不用出门。这就是“浏览器端Embedding生成”：在用户浏览器里，用轻量模型把文本直接转成向量（性格画像），随后在本地完成语义搜索与聚类，既保护隐私又响应飞快。 这趟旅程中，你会认识：给文本画“性格画像”的Embedding模型；挑选一位“轻装上阵的画师”（模型选型）；把画师的手稿转成标准格式（ONNX转换）；在浏览器里请他开画（Transformers.js推理）；把画像归档进家庭档案馆（IndexedDB存储）；最后完成新客户与旧画像的速配（语义搜索）。读完这篇，你就能为自己的前端应用装上这套纯本地的“画像室”。

岗位关联

掌握浏览器端Embedding生成，意味着你可以在纯前端场景实现隐私安全的语义搜索与聚类，为RAG、知识库等应用提供不依赖服务器的向量能力，这是前端AI工程师的核心加分项。

目录
  1. 可视化演示
  2. 语义坐标本质
  3. 轻量模型选型
  4. ONNX格式转换
  5. 浏览器端推理
  6. 向量存储方案
  7. 语义搜索应用
  8. 工程落地实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

演示在浏览器端加载Embedding模型，将文本映射为语义向量，支撑本地语义搜索与聚类。

本节配有交互动效（进入视口后自动加载，约 3KB）。

文本映射 输入 模型 Txt→Vec 语义相近文本映射到相近向量

语义坐标本质

相亲画像师从不拍照片，他给你一张打分表：幽默感8分、责任心9分、旅行偏好7分……每个维度一个数字，把这些数字排成一行，就是你的“性格坐标”。两个人的坐标越接近，性格就越合拍。

文本的Embedding也是这样一张“不打照片的画像”：模型把一段文字编码成一串定长的数字，比如384个浮点数。这串数字叫“文本向量”，它所在的空间叫“语义空间”。有趣的是，“猫”和“橘猫”的向量会挨在一起，而“猫”和“空调”则相距甚远——因为模型学会的是“意思的距离”，不是字面的距离。这个空间里的远近，就是相亲系统里的“速配指数”。

技术上，Embedding是一个从文本到向量的映射：

手里有了“性格坐标”这套理论，接下来就该思考：派哪一位画师上门？影楼大师虽然画得精细，但行头太重——这正是模型选型的难题。

v=fθ(text),v∈Rd\displaystyle \mathbf{v} = f_{\theta}(\text{text}), \quad \mathbf{v} \in \mathbb{R}^{d}
公式解读：一段文本经过带参数 θ 的模型 f 编码，得到一个 d 维实数向量 v。
  1. 文本输入text 就是要编码的一句话，例如“今天天气真好”。
    text="今天天气真好"\displaystyle \text{text} = \text{"今天天气真好"}
  2. 模型编码f_θ 是神经网络编码器，θ 是训练好的权重，像一位阅人无数的老画师。
    fθ:text↦v\displaystyle f_{\theta} : \text{text} \mapsto \mathbf{v}
  3. 输出向量v 是 d 维向量，浏览器场景常用 d=384，对应画像有384个性格维度。
    v∈R384\displaystyle \mathbf{v} \in \mathbb{R}^{384}

轻量模型选型

总部那位画像师是影楼大师，画一张像要三小时，器材装满两个行李箱。你要请人上门，就得选一位“轻装上阵的画师”：工具箱塞得进背包，画得像又快，还不挑场地。浏览器端Embedding模型选型的逻辑如出一辙。

候选画师们各有专长：all-MiniLM-L6-v2 只有约2200万参数，输出384维向量，体积约90MB，是国际选手；中文场景更偏爱 bge-small-zh-v1.5，512维，对中文长句的理解更细腻；paraphrase-multilingual-MiniLM 则能同时服务多种语言。选画师不能只看名气，还要看：参数量是否会让用户的手机发烫、输出维度是否够用、是否支持ONNX导出（能否走进浏览器）。

如何判断一位画师“画得像不像”？在Embedding的世界里，质量用语义距离来度量，最常用的尺子是余弦相似度：

选定了画师，还得把他的手稿转成浏览器能看懂的标准画纸。画师的独家笔迹外人可看不懂，这一步就是ONNX转换。

cos⁡(A,B)=∑i=1dAiBi∑i=1dAi2⋅∑i=1dBi2\displaystyle \cos(A,B) = \frac{\sum_{i=1}^{d} A_i B_i}{\sqrt{\sum_{i=1}^{d} A_i^2} \cdot \sqrt{\sum_{i=1}^{d} B_i^2}}
公式解读：两个向量的夹角余弦值，值越接近1，语义越相近；越接近0或负值，语义越无关。
  1. 分子点积把两个向量的每个维度相乘后求和，得到方向的“重合度”。
    A⋅B=∑i=1dAiBi\displaystyle A \cdot B = \sum_{i=1}^{d} A_i B_i
  2. 分母模长分别求出两个向量的长度再相乘，消除文本长短带来的影响。
    ∣A∣=∑i=1dAi2,∣B∣=∑i=1dBi2\displaystyle |A| = \sqrt{\sum_{i=1}^{d} A_i^2}, \quad |B| = \sqrt{\sum_{i=1}^{d} B_i^2}
  3. 取比值重合度除以长度乘积，结果落在 -1 到 1 之间。
    cos⁡(A,B)=A⋅B∣A∣⋅∣B∣∈[−1,1]\displaystyle \cos(A,B) = \frac{A \cdot B}{|A| \cdot |B|} \in [-1, 1]

ONNX格式转换

画师脑子里有完整的画面，但他的手稿只有自己团队能看懂。要让浏览器里的程序认识这张画，必须把它誊到“标准画纸”上——ONNX，一个开放的模型交换格式。转完之后，无论原模型是PyTorch还是TensorFlow训练出来的，浏览器都能照着这张画纸作画。

转换流程并不复杂：用 torch.onnx.export 导出计算图，指定输入输出名；接着配置“动态轴”，让模型能接受不同长度的文本和不同大小的批次；然后做量化压缩，把32位浮点权重压成8位整数，模型体积直接缩到约1/4；最后必须做一致性验证——拿同一段文本对比转换前后的输出向量，误差超过阈值就要调整方案。

为什么转换时特别在意“输入长度”？因为Transformer结构有个著名的脾气：计算量随序列长度平方增长：

画纸准备好了，画师人也到了家门口。接下来需要一位经纪人来安排作画流程、协调画室资源——这就是浏览器里的推理运行时。

O(L2)\displaystyle O(L^2)
公式解读：L 是输入文本的token数。模型需要让每个token与所有其他token两两交互，所以计算量是 L 的平方。
  1. 序列长度 LL 是切分后的token数量，如128或512。
    L=token 数量\displaystyle L = \text{token 数量}
  2. 两两交互每个token都要与其他所有token计算相关性，共 L×L 对。
    L×L=L2\displaystyle L \times L = L^2
  3. 量级增长L 翻倍时计算量变为4倍，所以浏览器里要截断超长文本。
    (2L)2=4⋅O(L2)\displaystyle (2L)^2 = 4 \cdot O(L^2)

浏览器端推理

画师进了客户家，总不能自己找桌子、自己调颜料，他需要一位经纪人：Transformers.js 就是这位经纪人，它负责加载模型、调度画室（onnxruntime-web）、把文字递到画师手里。你只需一行代码就能请它开工：

画师作画时有个效率窍门：与其一张张地画，不如一次摆开八张画纸批量画。深度学习模型本质是矩阵运算，GPU最擅长的就是一排排地算。批量推理把多条文本拼成一个批次送进模型，输出的是一个矩阵，每一行就是一条文本的向量：

启用WebGPU后端后，GPU直接参与矩阵计算，推理速度能再上一个台阶。画像画完，一张张总不能飘在空气里，得有个地方妥善收好——接下来把它们归档进“家庭档案馆”。

Y∈RB×d\displaystyle Y \in \mathbb{R}^{B \times d}
公式解读：一次推理处理 B 条文本，每条得到 d 维向量，整个批次塞进一个 B×d 的矩阵。
  1. 批量大小 BB 是一次喂给模型的文本条数，比如8条笔记一起编码。
    B=8\displaystyle B = 8
  2. 维度 d每条文本的画像有 d 个维度，浏览器常用384。
    d=384\displaystyle d = 384
  3. 矩阵含义Y 的第 i 行就是第 i 条文本的向量画像。
    Y=[v1v2⋮vB]\displaystyle Y = \begin{bmatrix} \mathbf{v}_1 \\ \mathbf{v}_2 \\ \vdots \\ \mathbf{v}_B \end{bmatrix}
js1 行
const extractor = await pipeline('feature-extraction', 'Xenova/all-MiniLM-L6-v2');

向量存储方案

画像画好了，客户家总得有个像样的档案柜。浏览器里的档案柜就是 IndexedDB，一个内置的键值数据库，能存下大量向量数据，页面关掉再打开也不会丢。每条向量配一个唯一ID，连同原文、时间戳一起存进“一张卡片”。

归档也有讲究。首先是批量写入：几千条向量逐条写入会卡顿，正确做法是放在一个事务里批量提交，像一摞画一起塞进柜子。其次是版本管理：模型一旦升级，向量维度可能从384变成512，旧画像全部作废，所以Schema里要记录模型版本，下次打开若版本不匹配就触发“索引重建”。

归档前最好先给向量做个“标准化”——把每张画像的长度都缩放到1，方便日后比较：

档案馆收拾利索了，客户也上门了。新客户往门口一站，画师现场画一张新画像，然后在满柜的旧画像里找出最合拍的几位——这就是语义搜索。

v^=v∥v∥\displaystyle \hat{\mathbf{v}} = \frac{\mathbf{v}}{\|\mathbf{v}\|}
公式解读：向量除以自身长度，得到单位向量。归一化后，点积直接等价于余弦相似度，省去每次计算模长的开销。
  1. 向量长度先算出向量的模长，即所有维度平方和再开根号。
    ∥v∥=∑i=1dvi2\displaystyle \|\mathbf{v}\| = \sqrt{\sum_{i=1}^{d} v_i^2}
  2. 逐分量缩放每个分量除以长度，向量总长度变成1。
    v^i=vi∥v∥\displaystyle \hat{v}_i = \frac{v_i}{\|\mathbf{v}\|}
  3. 归一化收益两个单位向量的点积就是余弦值，排序时少算一次除法。
    v^⋅u^=cos⁡(v,u)\displaystyle \hat{\mathbf{v}} \cdot \hat{\mathbf{u}} = \cos(\mathbf{v}, \mathbf{u})

语义搜索应用

婚介所迎来一位新客户，接待流程很简单：画师现场画一张新画像，然后在档案柜里翻出所有旧画像，按相似度从高到低排个序，把最合拍的三位请出来见面。浏览器端的语义搜索就是这套流程。

第一步，查询文本编码：用同一个Embedding模型把用户输入变成查询向量。第二步，相似度排序：把查询向量和所有文档向量做点积（因为都归一化过），得到一排分数。第三步，TopK截断：只取分数最高的K个结果返回。如果你想给整个知识库分个组，还可以做文档聚类——把互相靠近的向量归到同一个桶里，形成话题簇。

逐条打分时，本质是在算查询画像和每张旧画像的“速配指数”：

匹配做完，婚介所也从单间变成了小工作室。要长期运营，还得管好画纸库存、复用旧画、盯紧仪表盘——这就是工程落地。

scorei=q^⋅v^i\displaystyle \text{score}_i = \hat{\mathbf{q}} \cdot \hat{\mathbf{v}}_i
公式解读：第 i 篇文档的得分，等于归一化查询向量和归一化文档向量的点积，分数越高越匹配。
  1. 查询画像q̂ 是用户查询文本归一化后的向量，代表“想找什么样的人”。
    q^=q∥q∥\displaystyle \hat{\mathbf{q}} = \frac{\mathbf{q}}{\|\mathbf{q}\|}
  2. 文档画像v̂_i 是第 i 篇文档的归一化向量，档案里早已备好。
    v^i=vi∥vi∥\displaystyle \hat{\mathbf{v}}_i = \frac{\mathbf{v}_i}{\|\mathbf{v}_i\|}
  3. 点积得分两个单位向量点积越接近1，说明画像越合拍。
    scorei=∑j=1dq^j⋅v^i,j\displaystyle \text{score}_i = \sum_{j=1}^{d} \hat{q}_j \cdot \hat{v}_{i,j}

工程落地实践

工作室开张三个月，客户多了，问题也来了：画师上门要先铺画纸，画纸多了会堆满房间；同一个客户二次上门，明明有旧画像还要重画；偶尔画到一半颜料不够，页面直接卡死。这些正是工程化的三个核心课题。

第一，模型缓存复用：模型文件动辄几十MB，每次刷新都下载会气走用户。用 Cache API 把模型文件缓存进浏览器，第二次访问直接从缓存加载，秒开。第二，量化降载策略：把ONNX模型量化为int8后，内存占用降为原来的约1/4，推理更快，低端机也能跑。第三，性能监控指标：实时记录模型加载耗时、单次推理延迟、内存峰值，用 PerformanceObserver 上报到监控面板；如果WebGPU不可用，自动降级到WebGL后端，保证功能不中断。

内存占用可以提前估算，避免爆掉用户的手机：

从给文本画画像，到选画师、转画纸、开画、归档、速配、开店，整条链路已经完整跑通。这套“家庭画像室”，如今正走进越来越多真实的前端应用。

mem=B×L×d×4 bytes\displaystyle \text{mem} = B \times L \times d \times 4 \text{ bytes}
公式解读：一次批量推理的内存约等于批次大小B、序列长度L、向量维度d三者相乘，再乘以每个浮点数的4字节。
  1. 批次大小 B一次处理的文本条数，比如16。
    B=16\displaystyle B = 16
  2. 序列长度 L每条文本截断后的token数，比如128。
    L=128\displaystyle L = 128
  3. 输出维度 d每条文本的向量维度，例如384。
    d=384\displaystyle d = 384
  4. 字节换算每个32位浮点数占4字节，算出总内存后评估设备是否扛得住。
    16×128×384×4=3,145,728 bytes\displaystyle 16 \times 128 \times 384 \times 4 = 3{,}145{,}728 \text{ bytes}

AI 应用场景

本地笔记知识库语义搜索

阶段：推理与向量检索

解决的问题：传统关键词搜索只能匹配字面，搜“猫咪营养”找不到“橘猫吃什么”，而且笔记全文上传云端存在隐私顾虑。AI方案让笔记在浏览器本地完成Embedding，向量入库后支持语义匹配，全文不出设备。

具体案例：某开源笔记应用在后台用 Transformers.js 对用户笔记分批编码，向量写入IndexedDB。用户搜索时，查询文本实时编码，与本地向量做相似度排序，Top5结果毫秒级返回。离线状态下依然可用。

敏感文档本地聚类

阶段：数据隐私保护与预处理

解决的问题：病历、合同等敏感文档上传服务器有合规风险，人工整理又费时。方案是在浏览器端直接编码并聚类，敏感内容全程留在终端。

具体案例：某医院内网系统加载一个只读页面，选择一批病历描述文本，前端批量生成Embedding后按余弦相似度聚成几类，医生可直接看到“疑似同一病症”的分组结果，全程无网络上传。

客服工单实时标签推荐

阶段：在线推理与排序

解决的问题：客服录入工单时打标签靠经验，慢且不统一。AI方案在页面加载预置标签的向量库，输入描述后实时推荐最相近的标签，无需等待服务器响应。

具体案例：某SaaS客服系统在工单编辑页集成Embedding管道，输入“打印机连不上WiFi”，即时推荐“网络故障”“办公设备”等标签，并显示匹配度，客服一键确认即可提交。

Python 演示

python51 行
import numpy as npimport zlib  class BrowserEmbeddingDemo:    """模拟浏览器端ONNX模型的批量Embedding推理与语义检索。"""     def __init__(self, dim=384, seed=42):        self.dim = dim        self.rng = np.random.default_rng(seed)        self.doc_vectors = []        self.doc_names = []     def encode_text(self, text):        """将文本编码为归一化向量，模拟ONNX模型的前向推理。"""        vec = np.zeros(self.dim)        grams = list(text)        for i in range(len(text) - 1):            grams.append(text[i:i + 2])        for gram in grams:            h = zlib.crc32(gram.encode("utf-8"))            vec[h % self.dim] += 1            vec[(h // 7 + 11) % self.dim] -= 1        norm = np.linalg.norm(vec)        return vec / norm if norm > 0 else vec     def encode_docs(self, names):        """批量编码文档，模拟批量推理。"""        self.doc_vectors = [self.encode_text(n) for n in names]        self.doc_names = list(names)        return self.doc_vectors     def encode_query(self, text):        """编码查询文本，同样得到归一化向量。"""        return self.encode_text(text)     def top_k(self, query, k=3):        """归一化后点积即余弦相似度，降序取TopK。"""        mat = np.stack(self.doc_vectors) if self.doc_vectors else np.zeros((0, self.dim))        scores = mat @ query        idxs = np.argsort(scores)[::-1][:k]        return [(self.doc_names[i], round(float(scores[i]), 3)) for i in idxs]  if __name__ == "__main__":    demo = BrowserEmbeddingDemo()    docs = ["猫咪饲养手册", "橘猫减肥指南", "夏季空调选购", "新能源汽车测评"]    demo.encode_docs(docs)    q = demo.encode_query("如何照顾一只猫")    for name, score in demo.top_k(q, k=2):        print(f"{name}: {score}")
目的：用纯Python模拟浏览器端Embedding的完整流程——批量编码、归一化、点积排序，验证语义检索思路，真实项目中只需将 encode_text 替换为ONNX模型推理。
  1. grams = list(text)把文本拆成单字，作为最小的语义特征。
  2. h = zlib.crc32(gram.encode("utf-8"))用稳定哈希把字符映射到某个语义维度，模拟模型学到的特征投影。
  3. vec[h % self.dim] += 1特征落袋，对应模型“这个字激活了哪个性格维度”。
  4. norm = np.linalg.norm(vec)求向量长度，为归一化做准备。
  5. return vec / norm if norm > 0 else vec归一化保证点积等价于余弦相似度。
  6. mat = np.stack(self.doc_vectors)把文档向量堆成矩阵，对应批量推理的输出Y。
  7. scores = mat @ query一次矩阵乘法算出所有相似度，GPU加速的原理也在此。
  8. idxs = np.argsort(scores)[::-1][:k]按分数降序取前K个，完成TopK截断。

常见误区

误区浏览器里也是用神经网络生成向量，和服务器上用GPT生成的效果应该差不多，选个顺眼的模型就行。

正解家用画师和影楼大师的功力有天壤之别。浏览器模型受限于体积和速度，参数量通常在几千万以内，对复杂长句、专业术语的理解深度远不及大模型。选型时应放低预期：先跑通Demo，再用相似度抽检验证效果，而不是默认“免费又大碗”。

为何常见：大家熟知的都是大模型API的惊艳表现，容易把小模型想象成“缩小版GPT”，低估了规模对语义理解能力的决定性影响。

误区PyTorch模型转成ONNX只是换个格式，数值应该一模一样，不用额外测试。

正解转换涉及算子映射、动态轴配置和量化压缩，尤其是int8量化会引入可见精度损失。正确做法是准备一组测试文本，对比转换前后输出的余弦相似度，设置阈值（如0.99）做自动回归，防止模型悄悄“变笨”。

为何常见：“格式转换”听起来像复制粘贴文件，让人误以为无损；实际上量化是把精度换成体积和速度的一场交易。

误区模型能处理多长文本就喂多长，整篇文档一次性编码最省事。

正解注意力复杂度是 O(L²)，文本越长计算量爆炸式增长，浏览器会直接卡死。正确做法是把文档切成小段（如每段256个token）分别编码，再对段落向量做平均池化得到文档向量——这也顺便让知识库的检索粒度更细。

为何常见：API调用习惯了无脑传参，忽略了浏览器端要真刀真枪跑本地算力，L²增长是个看不见的陷阱。

误区数据不出浏览器，Embedding又在本地算，隐私绝对安全，可以放心存任何敏感信息。

正解浏览器本地不等于真空环境：模型文件可能从CDN加载、页面里的第三方脚本可能读取IndexedDB、浏览器扩展也能访问页面上下文。更稳妥的做法是自托管模型文件、避免混入敏感字段、必要时对存储本身加密。

为何常见：把“数据不上服务器”和“完全不可被窃取”划等号，忽视了浏览器生态中其他实体同样能接触到数据。

面试题

Q1. 浏览器端生成Embedding相比服务端，最突出的优势是？

单选题 · easy

  • A.模型推理精度更高
  • B.文本不出本地更隐私← 正确答案
  • C.可运行超大参数模型
  • D.完全无需编写代码

答案：B。浏览器端Embedding把文本留在用户设备上，避免上传服务器，隐私保护是核心优势。精度、模型规模和免编码都不成立：小模型精度通常更低，浏览器跑不了超大模型，代码依然要写。

Q2. 以下哪类模型最适合在浏览器端做Embedding？

单选题 · easy

  • A.轻量量化的MiniLM模型← 正确答案
  • B.千亿参数的闭源大模型
  • C.只支持图像的CLIP模型
  • D.需要GPU训练的扩散模型

答案：A。浏览器端受内存和算力限制，需要轻量、支持ONNX导出的小模型，MiniLM正是代表。千亿大模型跑不动，CLIP面向图像，扩散模型是生成任务，都不适合。

Q3. 把模型转换为ONNX格式的主要目的是？

单选题 · easy

  • A.让模型在浏览器端可部署← 正确答案
  • B.提升训练集的数据规模
  • C.替代浏览器里的JavaScript
  • D.将文本直接变成本地文件

答案：A。ONNX是开放模型交换格式，onnxruntime-web能在浏览器里执行它，因此转换是浏览器部署的关键一步。它不改变数据规模，不替代脚本语言，也不负责把文本存成文件。

Q4. 两个向量归一化后，余弦相似度可以简化为？

单选题 · mid

  • A.直接计算两个向量的点积← 正确答案
  • B.计算两个向量的差模长
  • C.求两个向量的逐元素乘积
  • D.取两个向量分量的最大值

答案：A。归一化后向量长度都为1，余弦公式的分母为1，分子点积即相似度。B是欧氏距离思路，C只说相乘没有求和，D与相似度无关。

Q5. Transformers.js在浏览器中执行Embedding推理，底层调用的是？

单选题 · mid

  • A.onnxruntime的Web后端← 正确答案
  • B.浏览器内置的WebSocket
  • C.Python的NumPy数值库
  • D.Node.js的事件循环机制

答案：A。Transformers.js封装了模型加载和预处理，真正的矩阵运算是交给onnxruntime-web完成的。WebSocket是通信协议，NumPy是Python库，事件循环是JS运行机制，都与推理无关。

Q6. 浏览器端Token化文本时，超长文本通常如何处理？

单选题 · mid

  • A.截断到模型最大序列长度← 正确答案
  • B.直接丢弃整篇文本不处理
  • C.随机打乱所有token顺序
  • D.转换文本为图片再识别

答案：A。注意力复杂度随L平方增长，超长文本必须截断，或切块后分段编码再池化。丢弃文本丢失信息，打乱顺序破坏语义，转图片走OCR完全是绕远路。

Q7. 为什么批量推理在浏览器端更高效？选出正确原因

多选题 · mid

  • A.GPU擅长并行处理矩阵运算← 正确答案
  • B.一次推理摊薄了框架调度开销← 正确答案
  • C.批量增大了模型参数量
  • D.批量降低了向量输出维度

答案：AB。批量推理把多条文本拼成矩阵，GPU并行处理效率高，同时减少逐条调用的调度开销。C和D错误：批量不改变模型参数，也不改变向量维度。

Q8. ONNX模型量化到int8后最直接的影响是？

单选题 · hard

  • A.内存占用降为约四分之一且提速← 正确答案
  • B.模型参数量直接减少一半
  • C.向量输出维度自动增大一倍
  • D.浏览器无需再加载任何模型

答案：A。float32转int8每个数从4字节变1字节，内存降为约1/4，整数运算更快。参数量由结构决定不变，输出维度由设计决定不变，模型依然要加载。

Q9. 浏览器端做语义检索，完整流程包含哪些步骤？

多选题 · mid

  • A.文档分块并批量编码成向量← 正确答案
  • B.查询文本编码并做相似度排序← 正确答案
  • C.将相似度结果按TopK截断← 正确答案
  • D.用SQL重写全部原始文档内容

答案：ABC。完整链路是文档批量编码入库、查询编码、相似度排序、TopK截断返回。SQL重写文档既无必要也偏离语义检索，向量检索不依赖改写原文。

Q10. 关于浏览器端Embedding的工程实践，正确的做法有？

多选题 · extreme

  • A.用Cache API缓存模型加载结果← 正确答案
  • B.长文档先切块再逐块编码向量← 正确答案
  • C.使用WebGPU后端加速矩阵计算← 正确答案
  • D.一次性加载全部用户文本不分块

答案：ABC。Cache API复用模型文件减少网络等待，长文档切块规避O(L²)计算爆炸，WebGPU并行加速矩阵运算。D不分块会导致内存暴涨和界面卡死，是不可取的做法。