1. 项目概述为什么Embedding模型值得你花时间研究如果你正在构建一个智能客服、一个文档问答系统或者任何需要让机器“理解”文本并从中检索信息的应用那么“文本Embedding”这个词你一定不陌生。简单来说Embedding就是把一段文字无论是一个词、一句话还是一整篇文章转换成一个固定长度的数字向量。这个向量就像是这段文字在数学世界里的“身份证”和“坐标”机器通过比较这些向量之间的距离就能判断两段文字在语义上是否相似。过去几年这个看似基础的技术其背后的模型架构却经历了一场静默但深刻的革命——从专精于此道的Encoder-only模型到如今借助大语言模型LLM强大能力的LLM-based范式。这场变革不仅仅是技术路线的切换它直接关系到我们构建的应用效果上限、开发成本以及未来演进的想象力。我最初接触Embedding时用的是像BERT这样的Encoder-only模型它们效果稳定部署简单是很多项目的起点。但随着业务对语义理解深度、跨语言能力、指令跟随灵活性的要求越来越高传统的模型开始显得力不从心。直到我开始尝试基于LLM生成Embedding的新方法才发现效果提升可以如此显著同时开发范式也完全变了。这篇文章我就结合自己的踩坑和实践经验为你彻底拆解从Encoder-only到LLM-based的Embedding模型演进之路。无论你是正在选型的技术负责人还是好奇前沿动态的开发者相信都能从中看到清晰的技术脉络和实用的落地指南。2. 核心思路与范式迁移两种模型架构的本质差异要理解这场变革我们得先回到问题的起点我们到底需要什么样的Embedding一个好的Embedding模型其产出的向量应该能让语义相似的文本在向量空间里“靠近”语义不同的文本“远离”。早期的模型和现在的模型都在解决这个问题但解题思路和手中的“工具”已经天差地别。2.1 Encoder-only时代专才的匠心与局限在Transformer架构普及之后Encoder-only模型如BERT、RoBERTa及其变种迅速成为文本Embedding的事实标准。这类模型的结构特点是它们只使用Transformer的编码器部分。在预训练阶段通过掩码语言模型MLM等任务让模型学会根据上下文来预测被掩盖的词从而获得对语言深层次的理解。它的工作流程非常直观输入一段文本经过模型内部的层层编码最终通常取[CLS]标记位置的输出向量或者对所有词元的输出向量进行平均/池化作为整段文本的Embedding。以经典的sentence-transformers库和BGEBAAI General Embedding系列模型为例它们都是在BERT等架构基础上通过对比学习等有监督方法在大量文本对数据上微调而来从而优化了向量对于语义相似度的表征能力。为什么它曾如此成功目标纯粹模型架构就是为“编码”和“理解”而生的没有生成任务的干扰所有参数都专注于学习如何更好地将文本映射为向量。效率与确定性前向传播一次必定得到一个固定长度的向量计算过程确定延迟低非常适合高并发、低延迟的在线检索场景。生态成熟有Sentence-BERT这样优秀的框架和BGE-v1.5、GTE等一批经过充分验证的优质开源模型开箱即用社区支持好。然而其局限性在实践中也日益凸显任务僵化一个训练好的Encoder-only Embedding模型其向量空间是固定的。它最擅长解决它训练时所针对的任务如语义相似度。如果你想让它适应一个新的、定义不同的相似性概念例如根据写作风格聚类而非主题就需要重新收集数据、重新微调模型成本很高。“静态”的理解它的理解能力在训练完成后就基本冻结了。面对复杂、多义或需要深层推理的文本有时会力不从心。指令不敏感你无法通过自然语言指令来动态调整Embedding的侧重点。例如你无法告诉模型“请从‘情感极性’的角度为这段话生成向量”或者“请忽略语法错误关注核心论点”。2.2 LLM-based范式通才的涌现与赋能LLM-based Embedding顾名思义是利用大语言模型来生成文本向量的方法。这并不是指直接用LLM的某个中间层输出虽然早期有人尝试而是指让LLM本身根据你的要求“生成”一段描述或一个标签然后再用一个轻量的适配器将这个“生成结果”编码成向量或者更前沿地直接引导LLM的内部表征服务于特定相似性任务。其核心思想是“解耦”与“引导”解耦理解与表征让LLM这个“通才”负责复杂、深度的语义理解。LLM在千亿token的预训练中已经内化了丰富的世界知识、逻辑推理和指令跟随能力。引导生成目标通过精心设计的提示词Prompt引导LLM针对当前的具体任务如“判断这两段话是否在讨论同一个事件”生成一个任务相关的、富含语义信号的文本例如一个判断理由或一个分类标签。适配编码使用一个相对轻量的Encoder可以是一个小型的BERT将这个LLM生成的文本编码成最终的Embedding向量。这个Encoder只需要学习如何将“富含任务语义的文本”映射到好的向量空间其学习难度远低于从头理解原始文本。这种范式带来了根本性的优势动态任务适配通过改变提示词你可以让同一个LLM基础模型瞬间适配“主题相似性”、“情感相似性”、“事实一致性”等不同任务无需重新训练Embedding模型。这解决了Encoder-only模型最大的痛点。深度语义利用LLM的强大推理能力可以处理比喻、反讽、多跳推理等复杂语言现象生成的语义信号质量更高。指令交互能力你可以用自然语言精细控制Embedding的生成例如“请生成一个侧重于技术细节的向量忽略营销用语”。当然新的范式也带来了新的挑战计算成本需要调用LLM进行生成即使是最小的7B模型其成本也远高于直接推理一个BERT模型。延迟生成文本需要时间使得整体pipeline的延迟增加。流程复杂从“输入文本”到“最终向量”需要经过“LLM生成”和“适配器编码”两个步骤系统设计更复杂。实操心得不要简单地将LLM-based Embedding视为“升级版”。它更像是一种“架构范式”的升维。对于 latency-sensitive延迟敏感且任务固定的成熟场景如标准语义搜索成熟的Encoder-only模型如BGE可能仍是性价比最高的选择。而当你的业务面临多变的相似性定义、需要处理极其复杂的文本、或者希望一套系统灵活支持多种检索模式时LLM-based范式才真正展现出其颠覆性价值。我的经验是从“固定任务”到“灵活任务”的需求转变是推动这次技术迁移的核心动力。3. 核心技术解析LLM-based Embedding是如何工作的理解了范式差异我们深入到技术细节。LLM-based Embedding不是魔法其背后有几条清晰的技术路径。我结合论文和实验为你梳理出主流的三种实现方式。3.1 提示词工程与文本表征法这是最直观的方法。核心思路是让LLM根据原始文本和任务指令生成一段高质量的“文本描述”然后用一个传统的、轻量的Encoder模型对这个描述文本进行编码得到向量。具体步骤设计提示词模板创建一个Prompt将你的原始文本和任务指令嵌入其中。例如“请从‘技术原理’的角度用一段话总结以下文本的核心内容总结应清晰且包含关键术语[原始文本]”。调用LLM生成将组装好的Prompt发送给LLM如GPT-4、Claude或开源的Llama 3获得生成的总结文本。编码生成文本使用一个高性能的轻量级Encoder模型如BGE-M3或蒸馏过的MiniLM对LLM生成的总结文本进行编码得到最终Embedding。为什么这样做有效LLM生成的总结文本已经过滤了原始文本的噪声突出了任务相关的核心语义。用一个轻量Encoder对这个“精炼版”文本编码相当于让Encoder在一个更干净、信号更强的数据上工作自然能产生质量更高的向量。这个方法将LLM的“理解与提炼”能力和轻量Encoder的“高效编码”能力完美结合。参数与计算示例假设原始文本长度为500 token经过LLM生成一段150 token的总结。轻量Encoder处理150 token的计算量远小于直接处理500 token的原始文本虽然多了LLM生成的开销。在批量处理时可以先为一批文本生成总结再批量编码能部分分摊LLM调用的开销。3.2 基于LLM内部表征的适配微调这种方法更深入一层。它认为LLM在生成下一个词的过程中其内部隐藏状态Hidden States已经包含了丰富的、与当前任务相关的语义信息。我们的目标是学习一个简单的“适配器”Adapter将LLM的某个或某几个中间层激活值映射成一个高质量的Embedding向量。技术流程选取表征层通常不取最后一层过于偏向下一个词的预测而是取中间层如第16层或第20层对于32层的模型的输出。有时也会将多层表征进行加权组合。构建适配器网络这是一个小型神经网络可能只有一两层线性变换或一个简单的MLP。它的输入是选定的LLM内部表征一个高维向量输出是我们需要的低维Embedding向量如768维。有监督微调收集一个包含文本A文本B相似度标签的数据集。固定LLM的主干参数只训练这个适配器网络。训练目标是让文本A和B经过上述流程得到的Embedding向量之间的余弦相似度与人工标注的相似度标签尽可能一致。这种方法的好处是效率相对较高LLM本身是冻结的只需要前向传播获取中间层特征无需生成文本节省了生成步骤的时间。表征质量高直接利用LLM深度理解文本时产生的内部特征信息损失少。开源友好可以在Hugging Face上找到许多开源的LLM如Llama、Mistral固定其权重后在上面微调自己的适配器完全可控。注意事项这种方法的关键在于适配器网络的设计和训练数据的质量。适配器不能太复杂否则容易过拟合训练数据需要精准反映你业务中“相似性”的定义。我曾在某个项目中使用这种方法发现如果训练数据中的“相似”定义与LLM预训练时的语义理解有偏差需要较多的数据才能让适配器“纠正”过来。3.3 指令微调与表征对齐这是目前学术界和工业界最前沿的探索方向代表工作是微软的E5系列和后续的LLM2Vec等。其思想是直接对LLM进行指令微调使其能够根据自然语言指令输出一个“适配于该指令”的向量表征。实现方式通常分为两步指令感知的对比学习预训练收集或构建大量的指令文本对。例如指令可以是“为这个句子生成一个用于语义检索的向量”文本是对应的句子。通过对比学习训练模型学会根据不同的指令将同一段文本映射到向量空间的不同位置。这一步通常使用自监督或弱监督数据规模很大。有监督指令微调在第一步的基础上使用高质量的、人工标注的指令文本A文本B相似度分数数据对模型进行微调进一步校准其向量空间使其与人类判断对齐。经过这种训练后模型的使用方式非常优雅输入指令: 为以下句子生成用于问答检索的向量。 句子: [你的文本]输出直接就是文本的Embedding向量通常是模型最后一个词元的隐藏状态或经过一个投影头。这种方法的优势是“一体化”和“零样本能力强”一个模型搞定所有无需额外的适配器或生成步骤并且对于训练数据中未出现过的指令类型也往往有不错的泛化能力。BGE最新的模型也在向这个方向靠拢支持在推理时通过instruction参数传入指令。技术选型对比表特性提示词工程文本表征法LLM内部表征适配器指令微调LLM核心原理LLM生成文本轻量Encoder编码利用LLM中间层特征训练适配器映射直接微调LLM使其输出指令感知向量计算开销高需LLM生成中需LLM前向计算训练适配器训练极高推理中与纯LLM推理相当延迟高中中灵活性极高通过Prompt控制中依赖训练数据定义的任务高通过自然语言指令控制效果上限取决于LLM生成质量和Encoder能力取决于LLM表征质量和适配器能力理论上限最高依赖训练数据量和质量开源生态组件丰富可自行组装需自行训练适配器有参考实现有E5、BGE等成品模型但顶尖模型多闭源适用场景探索性、多任务、对延迟不敏感固定任务、希望平衡效果与效率追求SOTA效果、需要强大零样本能力4. 实战指南从零构建一个LLM-based Embedding服务理论说得再多不如动手一试。下面我以一个“多维度文档检索系统”为例带你走一遍LLM-based Embedding的实战流程。我们的目标是用户输入一个问题系统可以按照“主题”、“技术细节”、“情感倾向”等多个维度分别从文档库中检索最相关的内容。4.1 环境准备与模型选型首先我们需要选择基础模型。考虑到效果和成本的平衡我推荐以下组合LLM选择Llama 3 8B Instruct或Qwen 2.5 7B Instruct。这两个是当前开源领域的佼佼者指令跟随能力强且拥有优秀的量化版本可以在消费级显卡如RTX 4090甚至CPU上以可接受的速度运行。轻量Encoder选择BGE-M3或gte-Qwen2-7B-instruct。前者是专门为多语言、多任务设计的强大Encoder后者是基于Qwen2微调的Embedding模型与我们的LLM同源可能表征更一致。向量数据库Milvus或Qdrant。它们专为海量向量检索设计性能远超传统数据库的向量插件。安装核心库# 模型加载与推理 pip install transformers accelerate bitsandbytes # 向量数据库客户端 (以Qdrant为例) pip install qdrant-client # 可选用于优化Prompt和调用LLM的框架 pip install openai litellm4.2 构建多维度Embedding生成管道我们采用“提示词工程文本表征法”因为它最灵活最能体现LLM-based范式的优势。第一步设计多维度提示词模板我们需要为每个检索维度设计一个独特的Prompt引导LLM生成不同侧重点的摘要。dimension_prompts { theme: 请用一句话概括以下文本的核心主题或讨论的中心事件。要求概括精准、简洁。文本{text}, technical_detail: 请提取以下文本中涉及的技术术语、方法、流程或参数等具体技术细节用逗号分隔的列表形式输出。文本{text}, sentiment: 请判断以下文本整体的情感倾向是积极、消极还是中性并简要说明主要依据不超过20字。文本{text}, action_item: 如果以下文本是一份会议纪要或工作汇报请提取其中明确的行动计划、待办事项或决策结论。文本{text} }第二步实现LLM生成与编码函数这里我们使用Hugging Face的transformers库本地加载量化后的LLM并使用SentenceTransformer加载轻量Encoder。import torch from transformers import AutoTokenizer, AutoModelForCausalLM, pipeline from sentence_transformers import SentenceTransformer import asyncio from typing import Dict, List class MultiDimensionEmbedder: def __init__(self, llm_model_path: str, encoder_model_name: str BAAI/bge-m3): # 加载量化后的LLM self.llm_tokenizer AutoTokenizer.from_pretrained(llm_model_path) self.llm_model AutoModelForCausalLM.from_pretrained( llm_model_path, torch_dtypetorch.float16, device_mapauto, load_in_4bitTrue # 使用4位量化节省显存 ) self.llm_pipeline pipeline( text-generation, modelself.llm_model, tokenizerself.llm_tokenizer, max_new_tokens150, temperature0.1, # 低温度保证输出稳定 do_sampleTrue ) # 加载轻量Encoder self.encoder SentenceTransformer(encoder_model_name, devicecuda) # 定义维度提示词 self.dimension_prompts {...} # 如上文定义 def generate_summary(self, text: str, dimension: str) - str: 根据维度和文本调用LLM生成摘要 prompt self.dimension_prompts[dimension].format(texttext) messages [{role: user, content: prompt}] formatted_prompt self.llm_tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) outputs self.llm_pipeline(formatted_prompt) generated_text outputs[0][generated_text] # 剥离Prompt部分只取模型生成的内容 summary generated_text[len(formatted_prompt):].strip() return summary def encode_text(self, text: str) - List[float]: 使用Encoder将文本编码为向量 # SentenceTransformer的encode方法返回numpy数组 embedding self.encoder.encode(text, normalize_embeddingsTrue) # 归一化便于余弦相似度计算 return embedding.tolist() async def get_multi_dim_embeddings(self, text: str) - Dict[str, List[float]]: 获取文本在所有定义维度下的Embedding embeddings {} tasks [] # 为每个维度并行生成摘要 for dim in self.dimension_prompts.keys(): summary self.generate_summary(text, dim) # 编码摘要得到该维度的向量 dim_embedding self.encode_text(summary) embeddings[dim] dim_embedding return embeddings第三步构建与查询向量数据库我们需要为每个维度在向量数据库中创建一个独立的集合Collection并建立索引。from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PointStruct class VectorDBManager: def __init__(self, hostlocalhost, port6333): self.client QdrantClient(hosthost, portport) self.embedder MultiDimensionEmbedder(...) # 初始化上面的Embedder def create_collections(self): 为每个维度创建集合 vector_size 1024 # 假设BGE-M3的向量维度是1024 for dim in self.embedder.dimension_prompts.keys(): self.client.recreate_collection( collection_namefdocs_{dim}, vectors_configVectorParams(sizevector_size, distanceDistance.COSINE) ) def index_document(self, doc_id: str, text: str, metadata: dict): 将一篇文档索引到所有维度集合中 dim_embeddings asyncio.run(self.embedder.get_multi_dim_embeddings(text)) for dim, embedding in dim_embeddings.items(): point PointStruct( iddoc_id, # 同一文档在不同集合中用相同ID便于关联 vectorembedding, payload{text: text, **metadata, dimension: dim} ) self.client.upsert(collection_namefdocs_{dim}, points[point]) def search(self, query_text: str, dimension: str, top_k: int 5): 在指定维度下进行检索 # 首先将查询文本转换成该维度的向量 query_summary self.embedder.generate_summary(query_text, dimension) query_vector self.embedder.encode_text(query_summary) # 在对应集合中搜索 search_result self.client.search( collection_namefdocs_{dimension}, query_vectorquery_vector, limittop_k ) return search_result4.3 系统部署与性能优化将上述模块组装成一个服务这里使用FastAPI构建一个简单的HTTP API。from fastapi import FastAPI, HTTPException from pydantic import BaseModel import uvicorn app FastAPI() db_manager VectorDBManager() class IndexRequest(BaseModel): doc_id: str text: str metadata: dict {} class SearchRequest(BaseModel): query: str dimension: str top_k: int 5 app.post(/index) async def index_document(req: IndexRequest): try: db_manager.index_document(req.doc_id, req.text, req.metadata) return {status: success, message: fDocument {req.doc_id} indexed.} except Exception as e: raise HTTPException(status_code500, detailstr(e)) app.post(/search) async def search_documents(req: SearchRequest): try: results db_manager.search(req.query, req.dimension, req.top_k) # 格式化返回结果 formatted_results [] for hit in results: formatted_results.append({ doc_id: hit.id, score: hit.score, text: hit.payload.get(text), metadata: {k: v for k, v in hit.payload.items() if k not in [text, dimension]} }) return {dimension: req.dimension, results: formatted_results} except KeyError: raise HTTPException(status_code400, detailfUnsupported dimension: {req.dimension}) except Exception as e: raise HTTPException(status_code500, detailstr(e)) if __name__ __main__: uvicorn.run(app, host0.0.0.0, port8000)性能优化关键点LLM调用批处理在索引大量文档时不要逐条调用LLM。可以将多条文本的Prompt组装成一个批次发送给LLM能极大提高吞吐量。vLLM或TGI等推理服务器支持高效的批处理。向量编码批处理SentenceTransformer的encode方法本身支持传入字符串列表进行批量编码比循环单条编码快得多。缓存层对于高频查询或不变的文档可以将生成的摘要甚至最终向量缓存起来如使用Redis避免重复计算。异步处理如上例所示不同维度的Embedding生成是相互独立的非常适合用异步并发asyncio.gather来加速。量化与硬件利用使用bitsandbytes进行4位或8位量化能让大模型在有限显存下运行。确保Encoder模型也加载在GPU上。5. 效果评估与问题排查如何判断你的Embedding是否“健康”构建好系统只是第一步更重要的是评估其效果并持续优化。Embedding模型的评估不像分类任务有明确的准确率它更依赖于下游任务的表现。这里分享一套我常用的评估与排查方法。5.1 构建领域相关的评估基准不要只依赖公开的通用数据集如MTEB它们与你的业务数据分布可能差异很大。构建一个你自己的“黄金标准”测试集是至关重要的。收集样本对从你的真实业务数据中人工标注100-200对文本。每对文本都应有一个相似度分数如0到5分或者至少分为“相关”、“不相关”、“部分相关”三类。标注时应明确遵循你定义的每个“维度”标准。设计评估指标召回率K这是检索系统最核心的指标。对于测试集中的每个查询看排名前K的结果中有多少个是真正相关的。通常绘制RecallK (K1, 5, 10, 20)的曲线来综合判断。平均精度均值衡量系统在不同召回率水平下的精度综合性强。相关性分数与余弦相似度的相关性计算模型输出的向量余弦相似度与人工标注的相似度分数之间的斯皮尔曼等级相关系数。这个指标直接反映了Embedding模型的质量。5.2 常见问题与诊断清单当你发现检索效果不佳时可以按照以下清单进行排查问题一检索结果完全不相关似乎随机返回。诊断这通常意味着Embedding本身失效了向量空间是混乱的。排查步骤检查向量归一化确保在存入向量数据库和查询时都使用了相同的归一化方法通常是L2归一化。余弦相似度计算要求向量是归一化的。这是最容易被忽略却导致灾难性结果的错误。检查Embedding维度确认你生成的向量维度与向量数据库中集合定义的维度完全一致。检查模型输出打印几组已知相似/不相似的文本的Embedding向量手动计算它们的余弦相似度看是否符合预期。同时检查LLM生成的摘要文本是否合理如果摘要已经是乱码那后续编码自然无效。问题二效果不如之前的Encoder-only模型。诊断LLM-based范式的优势没有发挥出来或者引入了新的噪声。排查步骤分析Prompt你的Prompt是否清晰、无歧义地传达了任务让LLM生成摘要然后人工评估这些摘要是否突出了你关心的维度。尝试不同的Prompt表述效果可能天差地别。检查“摘要-向量”的信息损失LLM生成的摘要可能丢失了关键信息。尝试增加生成的长度或者在Prompt中明确要求“保留关键实体和关系”。对比基线在同一个测试集上用纯Encoder-only模型如BGE跑一遍作为基线。如果LLM-based方法连基线都打不过那很可能当前的任务并不需要LLM的复杂理解能力或者你的实现方式有问题。审视任务本身你的“相似性”定义是否非常直接、字面对于简单的字面匹配经过海量数据训练的Encoder-only模型可能已经足够好LLM的“过度理解”反而可能引入偏差。问题三系统延迟太高无法满足线上要求。诊断LLM生成步骤是瓶颈。优化方向使用更小的LLM尝试Phi-3、Qwen2.5-Coder-1.5B等更小的指令模型它们在某些任务上表现依然出色。采用“内部表征适配器”方案如果任务相对固定可以训练一个适配器省去耗时的文本生成步骤。实现异步流水线与缓存将LLM调用设计为异步任务对查询结果进行缓存。对于文档索引采用离线批处理。升级硬件与使用推理服务器使用vLLM部署LLM它通过PagedAttention等技术极大地提高了吞吐量。5.3 一个真实的调试案例技术文档检索我曾负责一个技术社区的内容检索系统。最初使用BGE模型效果尚可但用户反馈无法区分“概念原理介绍”和“具体代码实现”这两种虽然主题相关但类型不同的文档。我们切换到了LLM-based方案设计了两个维度“concept_explanation”和“code_implementation”。最初的Prompt很简单“请总结以下文本”。结果发现对于一篇混合了原理和代码的博客LLM生成的摘要也是混合的导致两个维度的向量区分度不高。解决方案是设计更具引导性的Prompt对于concept_explanation“忽略所有代码片段和具体API只总结本文阐述的技术概念、原理、优缺点和适用场景。用抽象的语言描述。”对于code_implementation“提取本文中所有代码示例要实现的功能、使用的关键库/函数、以及核心逻辑步骤。用‘该代码演示了...’的句式开头。”调整后两个维度生成的摘要差异显著编码后的向量空间也很好地分开了。在“查找实现方案”的查询中code_implementation维度的检索结果中代码教程的排名大幅提升。这个案例让我深刻体会到在LLM-based范式中Prompt设计是模型效果的上限其重要性不亚于模型本身。6. 未来展望与进阶思考技术演进不会停止。LLM-based Embedding目前仍处于早期有几个方向值得持续关注方向一完全端到端的指令嵌入模型像E5和BGE新版本所做的将指令理解与向量生成完全融合在一个模型内。这需要巨量的、高质量的指令-文本对数据进行训练。未来可能会出现更强大的开源“全能型”Embedding模型通过一个模型参数动态适应无数种相似性定义。方向二更高效的适配器与蒸馏技术训练一个大型LLM来服务Embedding成本高昂。未来的趋势可能是用最强的LLM如GPT-4作为“教师”通过大量API调用生成高质量的指令文本向量三元组数据然后用这些数据去蒸馏训练一个中小型的、专门用于生成Embedding的“学生”模型。这样既能保留LLM的理解能力又能获得Encoder-only模型的效率。方向三多模态与结构化信息嵌入未来的Embedding不会局限于纯文本。LLM-based的框架可以自然地扩展到多模态领域让LLM理解一张图片、一个表格或一段音频然后生成跨模态的统一语义向量。例如用LLM描述图表内容再对描述文本编码从而实现“用文本搜索图表”。从我自己的实践来看从Encoder-only到LLM-based的转变不仅仅是换一个模型更是整个技术栈和设计思维的升级。它要求我们从“静态的、预定义的相似性”思维转向“动态的、可指令定义的相似性”思维。初期在Prompt工程和流程编排上会花费更多精力但一旦跑通其带来的灵活性和效果上限的提升将为你的应用打开全新的可能性。最关键的是开始实践选择一个具体的、有痛点的场景用上述方法搭建一个最小可行系统亲自感受这场技术变革带来的力量。