查询转换Query Transformation查询转换是将用户查询从文本形式转化为检索引擎能处理的格式如 embedding 向量同时做必要的清洗和保护。这是让人类语言适配机器引擎的关键桥梁。一、是什么查询转换是将用户查询从文本形式转化为检索引擎能处理的格式如 embedding 向量同时做必要的清洗和保护。核心输入改写后的检索查询核心输出归一化的 embedding 向量 保护后的查询文本二、为什么重要检索引擎不认识人类语言它只认识向量。转换质量直接影响检索质量图片标记![figure]会干扰 embedding 模型过长的 query 会导致 Rerank 模型截断不同组件需要不同的 Token 计数精度与传统方案的对比优化点传统方案传统方案的问题QAnything 方案优势向量化平均池化mean pooling所有 token 平均重要信息被稀释CLS token 提取[:,0]全局语义更聚焦归一化不归一化余弦相似度计算需要除法长向量主导排序L2 归一化余弦相似度 点积加速计算图片处理原样发送干扰语义发送前过滤图片标记检索向量更纯净Token 计数统一用一个 tokenizertiktoken 计 100 token实际可能 120三级 tokenizer 安全余量各组件精度匹配推理框架PyTorch 直接推理推理慢部署体积大无算子融合ONNX Runtime 全图优化推理速度提升 2-3x分数输出原始 logits无界阈值难设不可解释Sigmoid 线性拉伸0~1 可解释区分度高三、怎么做3.1 Embedding 向量化 L2 归一化问题文本需要转为向量才能在 Milvus 中检索。方案提取 CLS token 作为全局语义表示然后 L2 归一化。# Embedding ONNX 模型推理embeddingoutputs_onnx[0][:,0]# 提取 CLS token全局语义# L2 归一化使所有向量落到单位球面norm_arrnp.linalg.norm(embedding,axis1,keepdimsTrue)embeddings_normalizedembedding/norm_arr归一化的价值归一化后余弦相似度 点积加速后续相似度计算所有向量长度一致避免长向量主导排序的问题为什么用 CLS tokenBERT 类模型的[:, 0]token 经过自注意力聚合代表整句话的全局语义比平均池化更能捕捉句子的核心含义3.2 图片引用过滤问题查询中的会干扰 Embedding 模型的语义理解。方案发送前过滤掉图片和公式标记。# Embedding 客户端发送前过滤def_process_query(query):return\n.join([lineforlineinquery.split(\n)ifnotline.strip().startswith(![figure])andnotline.strip().startswith(![equation])])为什么不在索引阶段过滤索引阶段的图片引用是文档内容的一部分但查询阶段用户不会主动写图片标记这些通常是系统拼接进来的3.3 三级 Tokenizer 精度体系问题不同组件对 token 计数的精度要求不同用错 tokenizer 会导致切分不准或预算超支。Tokenizer使用场景为什么用它tiktoken(GPT)LLM Token 预算计算直接影响 API 成本需要精确embedding_tokenizer文件切分判断必须与 Embedding 模型的 max_length 对齐rerank_tokenizerRerank 资格判断必须与 Rerank 模型的 max_length 对齐# LLM Token 估算额外加安全余量total_tokens*1.1# tiktoken 精度较高加 10%total_tokens*1.2# 如果用 cl100k_base 兜底中文模型偏差大加 20%安全余量的原因tiktoken 是 GPT 专用 tokenizer与国产 LLM如 Qwen有偏差cl100k_base 是通用 tokenizer中文场景偏差更大加余量是为了防止实际 token 超过预算3.4 Rerank 查询长度保护问题Rerank 模型 max_length 512如果 query 太长就没有空间放 doc。方案query 300 token 时跳过 Rerank给 doc 留出 ~200 token 空间。# 三个条件全部满足才执行 Rerankifrerankandlen(source_documents)1andnum_tokens_rerank(query)300:source_documentsawaitself.rerank.arerank_documents(...)为什么是 300 而不是 512Rerank 输入 query doc512 是总长度给 doc 留 200 token 空间防止截断3.5 ONNX Runtime 推理加速问题PyTorch 推理速度慢部署体积大。方案使用 ONNX Runtime 进行模型推理。sess_optionsSessionOptions()sess_options.graph_optimization_levelGraphOptimizationLevel.ORT_ENABLE_ALL# 全图优化# 自动线程调度 GPU/CPU 自适应providers[CUDAExecutionProvider,CPUExecutionProvider]优化项算子融合将多个小算子合并为一个大算子常量折叠编译期计算常量表达式自动线程调度根据 CPU 核心数分配线程设备自适应自动选择 GPU 或 CPU3.6 Rerank Sigmoid 分数校准问题交叉编码器输出 logits无界值需要映射为 0~1 之间的可解释分数。defsigmoid(x):scores1/(1np.exp(-x))# 标准 sigmoid → (0, 1)scoresnp.clip(1.5*(scores-0.5)0.5,0,1)# 线性拉伸 → 增强区分度returnscores线性拉伸的作用标准 sigmoid 输出: 0.48 0.50 0.52 0.55 → 区分度低难以设定阈值 拉伸后: 0.47 0.50 0.53 0.575 → 高分更高低分更低区分度增强四、解决的问题汇总手段解决的问题Embedding 归一化余弦相似度计算效率图片引用过滤无效 token 干扰语义三级 Tokenizer不同组件精度需求不同Rerank 长度保护Rerank 模型输入截断ONNX 加速推理速度慢Sigmoid 校准分数无界不可解释
