Dense Passage Retriever（DPR）实战指南：从原理到千万级知识库部署

1. 项目概述：这不是在堆数据，而是在教模型“精准抓取”

“Finding the Needle in the Haystack”——这个标题不是修辞，是真实困境。我在做企业级知识库问答系统时，每天面对的不是几万条文档，而是动辄上千万段落的内部技术手册、客户工单、会议纪要和产品日志。用户问一句“上个月华东区服务器延迟突增的原因”，系统得从海量非结构化文本里， 在毫秒级内锁定那3–5个真正相关的段落 ，而不是返回一堆语义模糊、关键词碰巧匹配的干扰项。这正是Dense Passage Retriever（DPR）要解决的核心问题：它不靠关键词倒排索引硬匹配，而是把问题和段落都映射到同一个高维语义空间，让“相似问题”和“真正答案段落”在向量空间里物理距离极近——就像用磁铁吸针，而不是用筛子过草。

核心关键词“Dense Passage Retriever”直指技术本质： 稠密（Dense） ，意味着每个段落被压缩成一个固定长度的稠密向量（如768维），而非稀疏的词袋或TF-IDF； Passage ，强调处理粒度是“段落”而非整篇文档，这是精度跃升的关键； Retriever ，明确其角色是检索器，是端到端问答系统的第一道闸门。它不生成答案，但决定了后续阅读理解模块能否看到正确信息。适合谁？不是只写论文的研究者，而是正在搭建RAG（检索增强生成）系统的工程师、需要快速构建私有知识库的产品经理、或是想把客服响应时间从分钟级压到秒级的运维负责人。我试过直接用BM25做初筛，再喂给BERT做精排，结果首召回率（Top-1命中正确段落）只有38%；换成DPR微调后，同一数据集上直接拉到72%——这不是参数调优的边际提升，是范式切换带来的质变。

2. 整体设计与思路拆解：为什么放弃传统检索，选择端到端稠密编码？

2.1 传统检索的“天花板”在哪？

先说清楚我们为什么要推翻重来。以Elasticsearch为代表的BM25类算法，本质是统计学匹配：算query词在doc中的频率、逆文档频率、字段长度惩罚。它快、稳定、可解释，但致命缺陷是 词汇鸿沟（Lexical Gap） 。比如用户搜“苹果手机充不进电”，BM25可能漏掉文档里写的“iPhone 14 Pro电池无响应”，因为“苹果”没出现，“充不进电”和“无响应”是不同词。更麻烦的是 语义歧义 ：搜“Java”，返回的可能是编程语言教程，也可能是印尼旅游攻略——BM25只认字面，不辨语义。我在金融风控场景实测过，用BM25查“客户信用额度调整”，结果混入大量“信用卡年费减免”文档，人工标注发现相关段落召回率不足45%。

2.2 DPR的破局逻辑：用对比学习教会模型“什么是相关”

DPR的架构看似简单：两个独立的BERT编码器，一个专攻问题（Query Encoder），一个专攻段落（Passage Encoder）。但它的灵魂在于训练方式—— 负采样对比学习（Negative Sampling Contrastive Learning） 。不是让模型学“什么是对的”，而是让它学“什么是最不对的”。具体操作：对每个正样本（question, positive_passage）对，随机采样n个负样本段落（negative passages），这些负样本来自同一batch内其他问题的正确答案段落，或者从整个语料库中随机抽取。模型的目标是：让正样本的query向量与positive passage向量的余弦相似度尽可能高，同时与所有negative passage向量的相似度尽可能低。公式上就是最大化：

log[ exp(sim(q, p⁺) / τ) / (exp(sim(q, p⁺) / τ) + Σᵢ exp(sim(q, p⁻ᵢ) / τ)) ]

其中τ是温度系数（通常设0.05），控制分布平滑度。这个设计的精妙在于：它强制模型在向量空间里拉开“真相关”和“假相关”的距离，而不是泛泛地学“相似”。我做过消融实验，去掉负采样只用正样本训练，模型在NQ数据集上的准确率直接跌了22个百分点——说明DPR的威力不在编码器本身，而在这种“揪着耳朵教”的训练范式。

2.3 为什么必须是“双塔”结构？单编码器不行吗？

有人会问：既然都是BERT，为啥不共用一个编码器，把question+passage拼起来喂进去？这是个好问题。共用编码器（Cross-Encoder）确实在排序任务上SOTA，但它无法预计算段落向量。想象一下：你有1000万段落，每次用户提问，都要把query和全部1000万段落两两拼接，跑1000万次前向传播——这在生产环境是不可接受的。而DPR的“双塔”结构（Dual-Encoder）允许 离线预计算 ：所有段落向量一次性算好，存入FAISS或Annoy等向量数据库；线上只需编码query，一次向量检索（k-NN搜索）即可返回Top-K候选。我部署时用8卡V100，2小时完成千万级段落向量化；线上QPS轻松过500，P99延迟<80ms。这就是工程落地的硬门槛——学术指标再漂亮，扛不住高并发就等于零。

2.4 选型决策背后的成本权衡

DPR不是银弹，它的代价是训练数据和算力。训练一个高质量DPR，至少需要10万组（question, positive_passage）标注对，且负样本质量直接影响效果。我们曾尝试用弱监督自动生成负样本（比如用BM25返回的Top-10里排除正样本），结果模型学到的是BM25的偏见，对长尾问题鲁棒性极差。最终咬牙投入人力，让领域专家标注了12.7万组高质量样本，覆盖故障诊断、配置变更、合规条款等6大类场景。算力上，用Hugging Face的 transformers 库，在4张A100上微调base版BERT，需3天；若用RoBERTa-large，时间翻倍但首召回率仅提升1.3%，性价比极低。所以我的经验是： 优先保证数据质量，其次选合适规模的模型，最后才考虑硬件堆叠 。很多团队一上来就上large模型，结果数据噪声大，反而不如clean data+base模型稳。

3. 核心细节解析与实操要点：从数据准备到向量存储的魔鬼细节

3.1 数据准备：标注不是贴标签，是定义“相关性”的哲学

DPR的数据格式看着简单：JSONL文件，每行一个{"question": "...", "positive_ctxs": [{"title": "...", "text": "..."}], "negative_ctxs": [...]}。但真正的坑在“positive_ctxs”的定义上。我见过太多团队把整篇文档当positive，这是灾难。DPR要求positive必须是 最小语义单元 ——即能独立回答该问题的最短段落。比如问题“K8s Pod处于Pending状态的常见原因”，正确positive是：“Pending：Pod已被Kubernetes系统接受，但有一个或多个容器尚未创建。常见原因包括节点资源不足、镜像拉取失败、PV绑定超时。” 而不是整篇K8s排错指南。我们制定了一条铁律：positive段落长度严格控制在64–256个token，且必须包含问题的主谓宾完整逻辑链。为此专门开发了标注辅助工具：自动切分文档为句子，高亮问题关键词在段落中的位置，标注员只需勾选“是否含完整答案逻辑”，效率提升3倍。

3.2 负样本构造：随机采样是毒药，难负样本才是良方

负样本的质量，直接决定模型的判别力。初期我们用纯随机采样，结果模型在测试集上对“同义词替换”问题（如把“重启服务”换成“reload daemon”）完全失效。后来改用 困难负样本挖掘（Hard Negative Mining） ：先用未微调的DPR初版跑一遍全量数据，对每个问题，取其BM25返回Top-100里，DPR打分排名11–50的段落作为hard negatives。这些段落往往和问题有表面相关性（共享关键词），但语义无关——正是模型最需要被“点醒”的地方。实测显示，加入hard negatives后，模型在对抗测试集（ANTiQUE）上的鲁棒性提升37%。另一个关键是 去重与去偏 ：确保同一个段落不会在同一batch里既当positive又当negative；剔除所有含“参考链接”“详见XX章节”等指向性描述的段落，避免模型学偷懒。

3.3 模型微调：不只是调learning_rate，是重构训练动态

官方DPR代码用PyTorch Lightning，但默认配置在真实业务数据上水土不服。我踩过的最大坑是 梯度累积与batch size的错配 。DPR的loss计算依赖batch内负样本，若用小batch（如16），负样本数太少，对比学习失效；若强行增大batch到128，显存直接爆。解决方案是：用梯度累积（gradient accumulation steps=4），物理batch保持32，逻辑batch等效128。但这里有个隐藏陷阱：PyTorch的 nn.DataParallel 在梯度累积时会错误同步梯度，必须换用 DistributedDataParallel （DDP）。此外，learning rate不能照搬论文的1e-5。我们用线性预热（warmup steps=500），峰值lr设为2e-5，因为业务数据领域性强，过大学习率会让模型遗忘预训练知识。验证时发现，lr=1e-5时loss下降慢但稳定；lr=2e-5时前期下降快，但5个epoch后开始震荡——最终选2e-5，配合早停（patience=2），在第7个epoch保存最佳模型。

3.4 向量存储与检索：FAISS不是装上就完事，是场性能精调

段落向量存哪里？很多人直接上Redis Vector，但千万级向量下，Redis内存占用爆炸且查询慢。我们选FAISS，但默认IVF（Inverted File）索引不够用。关键参数调优如下：

• nlist（聚类中心数） ：设为 sqrt(段落数) 。1000万段落，nlist=3162。太小则聚类粗糙，召回率低；太大则索引体积大，查询慢。
• nprobe（搜索聚类数） ：初始设16，但线上压测发现P99延迟超标。通过二分法测试，发现nprobe=8时，召回率仅降0.2%，延迟降40%，最终选定。
• 量化方式 ：用PQ（Product Quantization）而非SQ（Scalar Quantization）。PQ把768维向量分块量化，1000万向量内存从120GB压到18GB，且精度损失<0.5%。实测用 faiss.IndexIVFPQ ， m=64 （每块维度）， nbits=8 （每块量化位数）。
• 多线程安全 ：FAISS默认非线程安全。我们用 faiss.omp_set_num_threads(1) 禁用OpenMP，改用Python多进程+共享内存，QPS从320提升到580。

提示：FAISS索引必须定期重建。我们设定规则：当新增段落超总量5%或距上次重建超72小时，触发增量重建。重建期间用双索引切换，零停机。

4. 实操过程与核心环节实现：从零到上线的完整流水线

4.1 环境准备与依赖安装：避开CUDA版本的深坑

生产环境用Ubuntu 20.04 + CUDA 11.3 + PyTorch 1.10。这里有个致命细节：FAISS官方pip包默认编译为CPU版，必须手动编译GPU版。步骤如下：

# 先卸载pip版faiss
pip uninstall faiss-cpu faiss-gpu -y

# 安装conda（避免apt源版本混乱）
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
bash Miniconda3-latest-Linux-x86_64.sh -b -p $HOME/miniconda3

# 创建专用环境
$HOME/miniconda3/bin/conda create -n dpr_env python=3.8
$HOME/miniconda3/bin/conda activate dpr_env

# 安装GPU版FAISS（指定CUDA版本）
$HOME/miniconda3/bin/conda install -c pytorch faiss-gpu cudatoolkit=11.3 -y

# 安装其他依赖（注意transformers版本）
pip install transformers==4.15.0 datasets==1.18.3 sentence-transformers==2.2.2

为什么强调CUDA 11.3？因为PyTorch 1.10只兼容CUDA 11.3，而FAISS 1.7.3的GPU版编译脚本硬编码了此版本。我曾试过CUDA 11.6，编译成功但运行时报 CUBLAS_STATUS_NOT_INITIALIZED ——这是底层驱动不匹配的典型症状。

4.2 数据预处理：清洗比建模更重要

原始数据是PDF和Word，第一步不是分词，是 结构化解析 。我们弃用通用PDF解析库（如pdfplumber），因为它们对表格、页眉页脚识别不准。改用 unstructured 库的 PartitionStrategy.FAST 模式，配合自定义规则：

• 过滤所有页眉页脚（正则匹配 ^\d+\s+.*\s+\d+$ ）
• 合并被分页截断的段落（检测末尾标点，若为逗号、顿号、连接号，则与下页首句合并）
• 标题层级还原（用字体大小+加粗特征，将“1.1.2 配置步骤”转为 <h3>配置步骤</h3> ）

然后才是段落切分。不用固定长度，用 语义切分 ：用spaCy加载 en_core_web_sm ，按句子分割，再按语义连贯性合并。规则是：若连续句子共享主语（如“K8s调度器...它会...”），且总长度<256 token，则合并为一段。最终产出段落平均长度187 token，标准差仅22，远优于固定切分的300±150。

4.3 模型训练：分布式训练的实操脚本

我们用Hugging Face Trainer API，但重写了 compute_loss 以支持自定义负采样。核心训练脚本 train_dpr.py 关键片段：

class DPRTrainer(Trainer):
    def compute_loss(self, model, inputs, return_outputs=False):
        # inputs: {"question_input_ids", "question_attention_mask", 
        #          "passage_input_ids", "passage_attention_mask"}
        q_emb = model.question_encoder(
            input_ids=inputs["question_input_ids"],
            attention_mask=inputs["question_attention_mask"]
        ).pooler_output  # [B, 768]
        
        p_emb = model.passage_encoder(
            input_ids=inputs["passage_input_ids"],
            attention_mask=inputs["passage_attention_mask"]
        ).pooler_output  # [B, 768]
        
        # 计算相似度矩阵 [B, B]，对角线为正样本
        scores = torch.matmul(q_emb, p_emb.t()) / self.args.temperature
        
        # 构造label：对角线为1，其余为0
        labels = torch.arange(len(scores), device=scores.device)
        
        loss_fct = CrossEntropyLoss()
        loss = loss_fct(scores, labels)
        return (loss, (q_emb, p_emb)) if return_outputs else loss

# 训练参数
training_args = TrainingArguments(
    output_dir="./dpr_model",
    num_train_epochs=10,
    per_device_train_batch_size=32,
    gradient_accumulation_steps=4,
    warmup_steps=500,
    learning_rate=2e-5,
    fp16=True,  # 关键！节省显存，加速训练
    logging_steps=100,
    save_steps=500,
    evaluation_strategy="steps",
    eval_steps=500,
    load_best_model_at_end=True,
    metric_for_best_model="eval_accuracy",
    greater_is_better=True,
    report_to="none"
)

trainer = DPRTrainer(
    model=model,
    args=training_args,
    train_dataset=train_dataset,
    eval_dataset=eval_dataset,
    compute_metrics=compute_metrics  # 自定义评估函数
)
trainer.train()

注意： fp16=True 必须配合 --fp16_full_eval ，否则评估时精度丢失。我们在线上评估发现，关掉fp16，准确率高0.3%，但训练速度慢2.1倍——权衡后保留fp16，因训练是离线任务。

4.4 向量索引构建：千万级段落的高效编码

段落编码不能用单卡暴力跑。我们用 datasets 库的 map 函数，结合 batched=True 和 num_proc=8 （8进程并行）：

def encode_passages(examples):
    # examples: batch of {"title": [...], "text": [...]}
    texts = [f"{t} {x}" for t, x in zip(examples["title"], examples["text"])]
    inputs = tokenizer(
        texts,
        truncation=True,
        padding=True,
        max_length=256,
        return_tensors="pt"
    )
    with torch.no_grad():
        outputs = model.passage_encoder(**inputs)
        embeddings = outputs.pooler_output.cpu().numpy()  # 转CPU避免OOM
    return {"embeddings": embeddings}

# 并行编码
dataset = dataset.map(
    encode_passages,
    batched=True,
    batch_size=256,
    num_proc=8,
    remove_columns=["title", "text"]
)

编码后，用 faiss.write_index 保存索引。关键技巧：先用 faiss.index_cpu_to_all_gpus 把索引加载到GPU，再用 index.add 添加向量，比CPU添加快17倍。1000万段落，单卡A100耗时23分钟。

4.5 线上服务：FastAPI封装与熔断保护

线上服务用FastAPI，但必须加熔断。核心代码：

from fastapi import FastAPI, HTTPException
from slowapi import Limiter, _rate_limit_exceeded_handler
from slowapi.util import get_remote_address
from starlette.middleware.base import BaseHTTPMiddleware

app = FastAPI()
limiter = Limiter(key_func=get_remote_address)
app.state.limiter = limiter
app.add_exception_handler(429, _rate_limit_exceeded_handler)

# 熔断器：连续3次查询超时，暂停服务30秒
circuit_breaker = {
    "failure_count": 0,
    "last_failure_time": 0,
    "timeout": 30
}

@app.post("/retrieve")
@limiter.limit("100/minute")  # 限流
async def retrieve(request: Request):
    global circuit_breaker
    
    # 熔断检查
    now = time.time()
    if circuit_breaker["failure_count"] >= 3 and now - circuit_breaker["last_failure_time"] < circuit_breaker["timeout"]:
        raise HTTPException(status_code=503, detail="Service temporarily unavailable")
    
    try:
        data = await request.json()
        query = data["query"]
        
        # 编码query
        inputs = tokenizer(query, return_tensors="pt", truncation=True, padding=True, max_length=64)
        with torch.no_grad():
            q_emb = model.question_encoder(**inputs).pooler_output.cpu().numpy()
        
        # FAISS检索
        D, I = index.search(q_emb, k=100)  # 返回距离和索引
        
        # 构建结果
        results = []
        for i, idx in enumerate(I[0]):
            if idx == -1: continue
            passage = passages[idx]  # passages是预加载的段落列表
            results.append({
                "text": passage["text"][:500],
                "score": float(D[0][i]),
                "title": passage["title"]
            })
        
        return {"results": results}
    
    except Exception as e:
        circuit_breaker["failure_count"] += 1
        circuit_breaker["last_failure_time"] = time.time()
        raise HTTPException(status_code=500, detail=str(e))

压测时发现，单实例QPS超400后，FAISS搜索延迟陡增。解决方案：部署3个实例，前端Nginx加 least_conn 负载均衡，并配置 proxy_next_upstream error timeout http_500 ，自动摘除故障节点。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 问题现象：训练loss不下降，甚至震荡上升

排查路径 ：

1. 检查数据泄露 ：确认 positive_ctxs 和 negative_ctxs 是否来自同一文档。曾有同事把同一篇手册的不同章节互标为正负样本，导致模型学“同一文档内段落都相关”，loss虚低但实际无效。
2. 验证tokenizer一致性 ：Query和Passage编码器必须用 同一tokenizer ，且 truncation 和 padding 策略完全一致。我们曾因passage tokenizer设 max_length=512 ，query设 256 ，导致向量空间错位，loss卡在1.8不动。
3. 梯度检查 ：在 Trainer 的 training_step 里加 torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0) ，并打印 grad.norm() 。若norm持续>10，说明梯度爆炸，需降低lr或增大 gradient_clip_val 。

独家技巧 ：在训练第1个epoch结束时，手动取10个query，用当前模型编码，计算它们与所有positive passage的相似度。若平均相似度<0.1，说明模型根本没学会基础匹配，立即停训检查数据。

5.2 问题现象：线上召回率高但准确率低，返回一堆“看起来相关”的废话

根因分析 ：这是典型的 负样本质量缺陷 。模型学会了“识别问题关键词”，但没学会“判断语义相关性”。比如问题“如何升级PostgreSQL”，模型返回所有含“PostgreSQL”和“升级”字样的段落，包括“PostgreSQL 9.6已停止维护”这种否定性内容。

解决方案 ：

• 引入否定性负样本 ：在 negative_ctxs 中，强制加入10%的“反例段落”，即明确否定问题答案的段落（如“不支持在线升级，必须停机”）。
• 重加权损失函数 ：对hard negative的loss乘以权重1.5，公式改为：

  loss = loss_fct(scores, labels) + 0.5 * loss_fct(hard_scores, hard_labels)
  

• 后处理过滤 ：在FAISS返回Top-100后，用轻量级Cross-Encoder（如DistilBERT）对Top-20重排序，只返回Top-5。实测增加15ms延迟，但准确率提升12%。

5.3 问题现象：FAISS检索结果顺序与预期不符，相同query多次请求返回不同Top-1

技术真相 ：FAISS的IVF-PQ索引在 nprobe 较小时，搜索是 近似最近邻（ANN） ，非精确解。当多个段落向量距离query极近（如余弦相似度0.72 vs 0.719），ANN可能随机返回其中一个。

规避方法 ：

• 提高nprobe ：从8提到16，精度提升但延迟增25%。我们折中用 nprobe=12 。
• 添加确定性排序 ：在FAISS返回索引I后，不直接取I[0][:5]，而是：

  # 重新计算query与Top-50段落的精确余弦相似度
  exact_scores = []
  for idx in I[0][:50]:
      if idx == -1: continue
      exact_sim = np.dot(q_emb[0], passages_emb[idx]) / (np.linalg.norm(q_emb[0]) * np.linalg.norm(passages_emb[idx]))
      exact_scores.append((idx, exact_sim))
  # 按exact_sim降序，取前5
  top5 = sorted(exact_scores, key=lambda x: x[1], reverse=True)[:5]
  

  这步只对Top-50重算，耗时<3ms，却彻底解决随机性。

5.4 问题现象：模型在新领域数据上表现骤降，迁移能力差

深层原因 ：DPR的领域适应性比想象中脆弱。预训练BERT在通用语料上学到的语义空间，与特定领域（如医疗、法律）的术语分布存在巨大偏移。我们做医疗问答时，直接微调通用DPR，F1仅51%。

实战迁移方案 ：

• 领域自适应预训练（Domain-Adaptive Pretraining） ：用目标领域1000万无标注文本，继续MLM训练BERT-base 2个epoch。这步让词向量空间“适配”新领域，F1提升至63%。
• 两阶段微调 ：第一阶段用领域通用QA对（如SQuAD）微调，第二阶段用业务数据微调。比单阶段高5.2%。
• Prompt Tuning替代全参数微调 ：在query输入前加可学习prompt：“[CLS] Question about medical diagnosis: [MASK] [SEP]”。只训练prompt embedding，参数量<0.1%，但效果接近全微调。

5.5 问题现象：服务内存持续增长，数小时后OOM

定位过程 ：用 psutil 监控发现， faiss.IndexIVFPQ 对象的 __sizeof__() 稳定，但 process.memory_info().rss 每分钟涨20MB。最终锁定在FastAPI的 BackgroundTasks ：我们为每个请求启用了后台日志记录，但日志对象引用了 q_emb 张量，而PyTorch的 cpu().numpy() 返回的是内存视图，未释放GPU显存。

修复代码 ：

# 错误写法
q_emb = model.question_encoder(**inputs).pooler_output.cpu().numpy()
# ... 检索逻辑 ...
background_tasks.add_task(log_query, query, q_emb)  # q_emb被长期持有

# 正确写法
with torch.no_grad():
    q_emb_tensor = model.question_encoder(**inputs).pooler_output
    q_emb = q_emb_tensor.cpu().numpy()  # 立即转CPU
    q_emb_tensor = None  # 显式删除GPU张量
    torch.cuda.empty_cache()  # 清理缓存

加了这三行，内存泄漏消失，服务稳定运行30天无重启。

6. 效果验证与业务价值：不是看指标，是看用户是否少点一次鼠标

6.1 严谨的评估方法论

别信单一指标。我们采用三级评估：

• 技术层 ：用NQ、TriviaQA等公开数据集测MRR@10、Recall@20，确保基线达标。
• 业务层 ：抽样1000个真实用户query，由3名领域专家盲评Top-5结果，计算“首结果可用率”（用户无需翻页即得答案）。
• 体验层 ：埋点统计“用户点击结果后的停留时长”和“二次搜索率”。若用户点开结果后3秒内关闭，或立刻换词重搜，说明检索失败。

结果：技术指标MRR@10=0.78（SOTA为0.81），但业务指标“首结果可用率”达86%，比旧系统（BM25+BERT）的52%翻倍；用户二次搜索率从31%降至9%。这才是真实的业务价值——用户少点一次鼠标，工程师少接一个投诉电话。

6.2 成本收益分析：算清每一笔账

• 投入 ：3人月开发（含数据标注）、4张A100训练3天（云成本约$1200）、FAISS索引存储18GB（月成本$15）。
• 收益 ：客服响应时间从平均4分12秒降至28秒，按每月5万次咨询计，年节省人力成本$210,000；知识库使用率提升300%，新员工上手周期缩短40%。
• ROI ：6周回本。这还没算进因快速定位故障减少的业务损失——上季度一次支付网关故障，DPR帮运维在17秒内锁定日志段落，比以往平均23分钟快85倍。

6.3 我的个人体会：DPR不是终点，是智能检索的起点

跑通DPR只是拿到了入场券。真正的挑战在后面：如何让模型理解“隐含需求”？用户搜“服务器慢”，可能真正想要的是“最近3小时CPU使用率TOP5的机器IP”。这需要把DPR和时序数据库、指标系统打通。我们正在做的下一步，是训练一个“Query Rewriter”，用GPT-3.5-turbo把自然语言query重写成带时间范围、指标名称、聚合函数的DSL，再喂给DPR。目前原型已实现，复杂query召回率提升至68%。DPR教会了系统“找什么”，而Query Rewriter正在教它“怎么找得更聪明”。技术没有银弹，但每一次扎实的迭代，都在把“大海捞针”变成“磁铁吸针”——而后者，才是工程师该有的手感。