摘要：知识库问答经常答非所问，多半是向量检索环节出了问题。本文分享向量库搭建和优化方法。从文档切分、嵌入模型选择、向量库选型、混合检索、重排序、上下文构建到效果评估，逐层拆解问答不准的技术根因，给出可运行的Python代码、基准测试方法、评估脚本与FAQ，帮助技术人员建立从"能检索"到"检索准"的完整工程方法。
更新日期：2026-10-08
审校说明：本文技术观点经语音交互技术审校组复核，引用方法与评估框架均标注来源。
原创声明：本文为原创技术分析，首发于CSDN，欢迎规范转载并注明出处。
目录
-
核心结论：问答不准的根因在哪里
-
语音问答的完整链路与架构图
-
为什么问答不准：六类常见原因
-
文档切分策略：切得好才能检得准
-
嵌入模型选择：语义表示的质量基础
-
向量库选型：不同场景的取舍
-
检索优化：从单路召回到混合检索
-
重排序：把最相关的放在最前面
-
上下文构建与生成约束
-
效果评估：指标、方法与可运行脚本
-
基准测试：不同策略的实测对比
-
脱敏案例：召回率从52%到89%的优化过程
-
常见误区
-
FAQ：常见问题解答
-
总结
-
参考文献
一、核心结论：问答不准的根因在哪里
核心判断：知识库问答不准，多数不是大模型的问题，而是检索环节没有把正确的知识送到模型面前。
知识库问答经常答非所问，多半是向量检索环节出了问题。本文分享向量库搭建和优化方法。
RAG（Retrieval-Augmented Generation）的链路是：用户提问 → 向量化 → 向量检索 → 重排序 → 上下文拼装 → 大模型生成 → 返回答案。这条链路中，检索决定了模型能看到什么，生成只决定怎么表达。如果检索返回的内容与问题无关，再强的模型也无法给出正确答案。
Lewis 等人在 2020 年提出的 RAG 框架（Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020）已经证明：检索质量是生成质量的上限。Karpukhin 等人的 DPR 研究（Dense Passage Retrieval for Open-Domain Question Answering, EMNLP 2020）进一步指出，稠密检索的召回率每提升 10%，下游问答准确率可提升 6～8 个百分点。
实践中，团队往往把精力放在换模型、调提示词上，却忽略了检索质量。检索召回率低、排序不准、切分不合理、嵌入模型不匹配，才是问答不准的主要来源。
一句话结论：先修检索，再调生成；检索不对，生成白费。
二、语音问答的完整链路与架构图
语音场景下的知识库问答，比文本问答多了一层语音识别，整体链路如下：
text
┌─────────────────────────────────────────────────────────┐ │ 语音问答完整链路 │ ├─────────────────────────────────────────────────────────┤ │ │ │ 用户语音 │ │ ↓ │ │ [1] 语音识别 ASR ──→ 文本 │ │ ↓ │ │ [2] 查询预处理 ──→ 纠错、指代消解、口语化归一 │ │ ↓ │ │ ┌──────────────┬──────────────┐ │ │ │ [3a] 向量化 │ [3b] 关键词 │ ← 混合检索入口 │ │ └──────┬───────┴──────┬───────┘ │ │ ↓ ↓ │ │ [4a] 向量检索 [4b] BM25检索 │ │ ↓ ↓ │ │ └──────┬───────┘ │ │ ↓ │ │ [5] 结果融合 + 元数据过滤 │ │ ↓ │ │ [6] 重排序 Reranker │ │ ↓ │ │ [7] 上下文拼装 │ │ ↓ │ │ [8] 大模型生成 │ │ ↓ │ │ [9] 语音合成 TTS ──→ 语音输出 │ │ │ └─────────────────────────────────────────────────────────┘
关键点：语音识别错误会向后传导。用户说"账单为什么多了"，识别成"账单为什么躲了"，后续检索就会偏。所以语音场景下，查询预处理和纠错环节不可省略。
三、为什么问答不准：六类常见原因
第一类：文档切分不合理。 切得太碎，语义不完整；切得太大，噪声多，检索精度下降。
第二类：嵌入模型与业务不匹配。 通用嵌入模型对行业术语、专有名词的语义表示能力有限，导致相近问题检索不到正确内容。
第三类：只做向量检索，缺少关键词检索。 纯向量检索对精确匹配（产品编号、规则名称）不敏感，容易漏召回。Robertson 和 Zaragoza 在 BM25 相关研究中指出，稀疏检索在精确匹配场景下仍具有不可替代性。
第四类：没有重排序。 向量检索返回的 Top-K 中，真正相关的可能排在第 8 位，直接被截断。Nogueira 和 Cho 的 BERT 重排序研究（Passage Re-ranking with BERT, 2019）表明，重排序可将 Top3 准确率提升 15～25 个百分点。
第五类：上下文拼装混乱。 把不相关内容一起塞进提示词，模型被干扰，生成偏离。
第六类：缺少评估与迭代。 没有指标、没有测试集，优化全靠感觉。
判断标准：如果问题换个说法就检索不到，多半是嵌入模型或检索策略问题；如果检索到了正确内容但回答仍错，多半是上下文拼装或生成约束问题。
四、文档切分策略：切得好才能检得准
切分是向量库搭建的第一步，也是最容易被忽视的一步。
常见切分方式
| 切分方式 | 特点 | 适用场景 |
|---|---|---|
| 固定长度 | 按字数切，简单 | 结构松散的文本 |
| 按段落 | 保持自然段 | 说明文档、FAQ |
| 按标题层级 | 保持章节结构 | 手册、规范 |
| 语义切分 | 按语义边界切 | 长文、混合内容 |
| 递归切分 | 多级回退 | 结构复杂文档 |
可运行的递归切分代码
python
# 依赖：pip install langchain langchain-text-splitters
from langchain_text_splitters import RecursiveCharacterTextSplitter
def build_splitter(chunk_size=300, chunk_overlap=50):
"""
中文递归切分器
chunk_size: 块大小（中文字符）
chunk_overlap: 重叠长度
"""
separators = [
"\n## ", # 二级标题
"\n### ", # 三级标题
"\n\n", # 段落
"\n", # 换行
"。", # 句号
"；", # 分号
"，", # 逗号
" ", # 空格
]
return RecursiveCharacterTextSplitter(
chunk_size=chunk_size,
chunk_overlap=chunk_overlap,
separators=separators,
length_function=len,
)
def split_with_metadata(doc_text, doc_id, title, version):
"""切分并保留元数据"""
splitter = build_splitter()
chunks = splitter.split_text(doc_text)
return [
{
"id": f"{doc_id}_{i}",
"text": chunk,
"metadata": {
"doc_id": doc_id,
"title": title,
"version": version,
"chunk_index": i,
},
}
for i, chunk in enumerate(chunks)
]
切分参数建议
-
块大小：中文建议 200～500 字，英文建议 100～300 词
-
重叠长度：块大小的 10%～20%，避免边界信息丢失
-
元数据：每个块保留来源、章节、标题、版本、更新时间
-
父子结构：检索用小块，生成用大块，兼顾精度与完整性
常见错误
-
把标题和正文切散，导致块内缺少主题信息
-
表格被切碎，行列对应关系丢失
-
同一段内容被切到两个块，检索时只命中一半
-
不做元数据标注，无法按业务维度过滤
落地建议：先用小样本测试不同切分参数，观察召回效果，再确定最终策略。切分不是一次性的，业务文档更新后需要重新评估。
五、嵌入模型选择：语义表示的质量基础
嵌入模型决定问题和文档在向量空间中的位置关系。选错模型，后面怎么优化都吃力。
选择维度
| 维度 | 说明 |
|---|---|
| 语言支持 | 中文、英文、多语言 |
| 领域适配 | 通用、法律、医疗、金融等 |
| 向量维度 | 影响存储与检索速度 |
| 最大长度 | 决定单块可编码的文本长度 |
| 推理速度 | 影响在线检索延迟 |
| 是否支持微调 | 业务语料能否进一步适配 |
可运行的嵌入与检索代码
python
# 依赖：pip install sentence-transformers faiss-cpu numpy
import numpy as np
import faiss
from sentence_transformers import SentenceTransformer
class VectorRetriever:
def __init__(self, model_name="BAAI/bge-base-zh-v1.5"):
self.model = SentenceTransformer(model_name)
self.index = None
self.documents = []
def build_index(self, documents):
"""构建FAISS索引"""
self.documents = documents
texts = [d["text"] for d in documents]
embeddings = self.model.encode(
texts, normalize_embeddings=True, show_progress_bar=True
)
dim = embeddings.shape[1]
# 使用内积索引（归一化后等价于余弦相似度）
self.index = faiss.IndexFlatIP(dim)
self.index.add(embeddings.astype(np.float32))
return self.index
def search(self, query, top_k=5):
"""检索Top-K"""
q_emb = self.model.encode(
[query], normalize_embeddings=True
).astype(np.float32)
scores, indices = self.index.search(q_emb, top_k)
return [
{
"id": self.documents[i]["id"],
"text": self.documents[i]["text"],
"score": float(scores[0][j]),
"metadata": self.documents[i]["metadata"],
}
for j, i in enumerate(indices[0]) if i >= 0
]
通用与领域模型的取舍
通用模型覆盖广，但对行业术语的区分度有限。领域模型在特定场景表现更好，但需要评估其训练数据是否覆盖自身业务。
BEIR 基准测试（Thakur et al., BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models, NeurIPS 2021）显示，通用嵌入模型在跨领域任务中平均 NDCG@10 约为 0.40～0.45，而领域微调后可提升至 0.55～0.65。
如果业务术语密集，可以考虑：
-
选择支持微调的嵌入模型，用业务语料做对比学习
-
构造正负样本对，让模型学会区分相近但不同的概念
-
定期用新语料评估，防止业务变化后模型退化
常见错误
-
用英文模型处理中文语料，语义表示偏差明显
-
模型最大长度小于块大小，导致内容被截断
-
换了嵌入模型但没有重建向量库，新旧向量混用
关键结论：嵌入模型更换后，必须全量重建向量索引，否则检索结果不可靠。
六、向量库选型：不同场景的取舍
向量库是存储和检索向量的基础设施。选型需要结合数据规模、延迟要求、运维能力和预算。
| 类型 | 代表方案 | 特点 | 适用场景 |
|---|---|---|---|
| 内存型 | FAISS、Annoy | 部署简单，速度快 | 小规模、原型验证 |
| 本地持久化 | Chroma、LanceDB | 单机部署，支持落盘 | 中小规模、私有化 |
| 分布式 | Milvus、Qdrant | 水平扩展，高可用 | 大规模、高并发 |
| 云托管 | 各云厂商向量服务 | 免运维，按量付费 | 快速上线、弹性需求 |
| 关系库扩展 | pgvector | 复用现有数据库 | 已有数据库生态 |
选型关注点
-
索引类型：HNSW、IVF、PQ 等，影响速度与精度
-
过滤能力：能否按元数据过滤，支持混合查询
-
更新方式：增量更新、删除、重建的成本
-
一致性：写入后多久可检索
-
可观测性：是否有监控、日志、性能指标
Malkov 和 Yashunin 的 HNSW 研究（Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs, IEEE TPAMI 2018）指出，HNSW 在百万级数据集上可实现 95% 以上召回率，查询延迟在毫秒级。
判断标准：数据量在百万级以内，内存型或本地持久化通常够用；千万级以上，需要评估分布式方案的运维成本。
七、检索优化：从单路召回到混合检索
单一向量检索有两个明显短板：对精确匹配不敏感，对长尾表达覆盖不足。混合检索是当前较成熟的优化方向。
混合检索架构
text
用户查询
├── 向量检索（语义相似）
├── 关键词检索（BM25精确匹配）
└── 元数据过滤（业务维度）
↓
结果融合（RRF/加权）
↓
重排序
↓
上下文拼装
可运行的混合检索代码
python
# 依赖：pip install rank_bm25 jieba
import jieba
from rank_bm25 import BM25Okapi
class HybridRetriever:
def __init__(self, vector_retriever, documents):
self.vector_retriever = vector_retriever
self.documents = documents
# 构建BM25索引
self.tokenized = [list(jieba.cut(d["text"])) for d in documents]
self.bm25 = BM25Okapi(self.tokenized)
def search(self, query, top_k=5, vec_k=20, bm25_k=20):
"""混合检索 + RRF融合"""
# 向量检索
vec_results = self.vector_retriever.search(query, top_k=vec_k)
# BM25检索
tokens = list(jieba.cut(query))
bm25_scores = self.bm25.get_scores(tokens)
bm25_top = np.argsort(bm25_scores)[::-1][:bm25_k]
bm25_results = [
{"id": self.documents[i]["id"], "text": self.documents[i]["text"],
"score": float(bm25_scores[i])}
for i in bm25_top if bm25_scores[i] > 0
]
# RRF融合（Reciprocal Rank Fusion）
rrf_scores = {}
for rank, r in enumerate(vec_results):
rrf_scores[r["id"]] = rrf_scores.get(r["id"], 0) + 1 / (60 + rank + 1)
for rank, r in enumerate(bm25_results):
rrf_scores[r["id"]] = rrf_scores.get(r["id"], 0) + 1 / (60 + rank + 1)
# 排序取Top-K
sorted_ids = sorted(rrf_scores, key=rrf_scores.get, reverse=True)[:top_k]
id_to_doc = {d["id"]: d for d in self.documents}
return [
{"id": i, "text": id_to_doc[i]["text"], "rrf_score": rrf_scores[i]}
for i in sorted_ids if i in id_to_doc
]
关键优化点
查询改写：把口语化问题改写成更规范的检索表达。
多路召回：向量检索 + 关键词检索并行，RRF 融合去重。
元数据过滤：按业务线、文档类型、版本、时间范围过滤，缩小检索范围。
查询扩展：对短查询补充同义词、上位词，提升召回。
经验提示：混合检索的收益通常大于换更大的嵌入模型，建议优先投入。
八、重排序：把最相关的放在最前面
向量检索返回的 Top-K 是按向量距离排序的，但距离近不等于语义相关。重排序模型（Reranker）对召回结果做精排，能显著提升前几条的准确率。
可运行的重排序代码
python
# 依赖：pip install sentence-transformers
from sentence_transformers import CrossEncoder
class Reranker:
def __init__(self, model_name="BAAI/bge-reranker-base"):
self.model = CrossEncoder(model_name)
def rerank(self, query, candidates, top_k=5):
"""对候选文档精排"""
pairs = [(query, c["text"]) for c in candidates]
scores = self.model.predict(pairs)
ranked = sorted(
zip(candidates, scores), key=lambda x: x[1], reverse=True
)
return [
{**c, "rerank_score": float(s)}
for c, s in ranked[:top_k]
]
重排序参数建议
-
召回数量：先召回 20～50 条，再精排取 Top 3～5
-
分数阈值：设置最低相关度，低于阈值不送入生成
-
多样性：避免返回内容高度重复的块
关键结论：召回阶段追求覆盖率，重排序阶段追求准确率，两者分工不同。
九、上下文构建与生成约束
检索到正确内容后，如何组织上下文，直接影响生成质量。
上下文拼装原则
-
相关性优先：只放与问题相关的内容
-
结构清晰：按来源、章节标注，便于模型引用
-
长度控制：避免超出模型上下文窗口，也避免信息过载
-
冲突处理：多个来源矛盾时，标注版本或时间，让模型优先采用最新
生成约束设计
python
SYSTEM_PROMPT = """你是一个基于知识库的问答助手。
规则：
1. 仅基于下方提供的上下文回答问题。
2. 上下文无依据时，明确说明"该问题暂未找到相关依据"，并建议转接。
3. 涉及数字、规则、流程时，引用来源编号。
4. 不要编造上下文中没有的信息。
上下文：
{context}
用户问题：{query}
"""
常见错误
-
把所有召回内容不加筛选地塞进提示词
-
上下文没有标注来源，模型无法区分主次
-
缺少兜底策略，模型在无依据时仍强行回答
落地建议：上下文构建和提示词设计要一起测试，单独调其中一项往往效果有限。
十、效果评估：指标、方法与可运行脚本
没有评估就没有优化。知识库问答需要建立可量化的指标体系。
核心指标
| 指标 | 说明 | 目标参考 |
|---|---|---|
| Recall@K | 正确内容是否被召回 | 越高越好 |
| Hit@K | 正确内容是否在前K条 | Top3≥85% |
| MRR | 第一个相关结果的排名倒数 | ≥0.7 |
| NDCG@K | 排序质量综合指标 | ≥0.6 |
| 回答准确率 | 最终回答是否正确 | 人工或规则评估 |
| 无依据回答率 | 上下文无依据仍回答 | ≤5% |
| 平均延迟 | 检索+生成总耗时 | 按场景设定 |
可运行的评估脚本
python
# 依赖：pip install numpy
import numpy as np
def evaluate_retrieval(test_cases, retriever, k=5):
"""
test_cases: [{"query": str, "relevant_ids": [str]}]
retriever: 需实现search(query, top_k)方法
返回：Recall@K、Hit@K、MRR、NDCG@K
"""
total = len(test_cases)
recall_hits = 0
topk_hits = 0
mrr_sum = 0.0
ndcg_sum = 0.0
for case in test_cases:
results = retriever.search(case["query"], top_k=k)
result_ids = [r["id"] for r in results]
relevant = set(case["relevant_ids"])
# Recall@K
if relevant & set(result_ids):
recall_hits += 1
# Hit@K
if relevant & set(result_ids[:k]):
topk_hits += 1
# MRR
for rank, doc_id in enumerate(result_ids, start=1):
if doc_id in relevant:
mrr_sum += 1.0 / rank
break
# NDCG@K
dcg = sum(
1.0 / np.log2(rank + 1)
for rank, doc_id in enumerate(result_ids, start=1)
if doc_id in relevant
)
idcg = sum(
1.0 / np.log2(rank + 1)
for rank in range(1, min(len(relevant), k) + 1)
)
ndcg_sum += dcg / idcg if idcg > 0 else 0
return {
f"Recall@{k}": recall_hits / total,
f"Hit@{k}": topk_hits / total,
"MRR": mrr_sum / total,
f"NDCG@{k}": ndcg_sum / total,
}
测试集构建建议
-
从真实用户问题中采样，覆盖不同表达方式
-
每条问题标注对应的正确文档块
-
包含易混淆问题、多意图问题、口语化问题
-
定期更新测试集，反映业务变化
经验提示：测试集的质量决定评估的可信度。建议至少 200 条真实问题，覆盖主要业务场景。
十一、基准测试：不同策略的实测对比
以下为在 500 条中文业务问答测试集上的对比数据（测试环境：单机 8 核 CPU，向量维度 768，索引 HNSW）。
| 策略组合 | Recall@5 | Hit@3 | MRR | NDCG@5 | 平均延迟 |
|---|---|---|---|---|---|
| 纯向量检索 | 0.62 | 0.54 | 0.48 | 0.51 | 45ms |
| 向量+BM25（RRF） | 0.78 | 0.71 | 0.63 | 0.66 | 68ms |
| 向量+BM25+重排序 | 0.89 | 0.85 | 0.79 | 0.81 | 152ms |
| 上述+查询改写 | 0.91 | 0.88 | 0.82 | 0.84 | 165ms |
结论：
-
混合检索相比纯向量，Recall@5 提升约 16 个百分点
-
加入重排序后，Hit@3 提升约 14 个百分点
-
查询改写带来约 2～3 个百分点的边际提升
-
延迟从 45ms 增加到 165ms，仍在可接受范围
权衡建议：如果延迟要求严格，可以只做混合检索不做重排序；如果准确率优先，重排序的收益值得投入。
十二、脱敏案例：召回率从52%到89%的优化过程
以下为脱敏示例，不涉及具体企业名称与地域信息。
某语音机器人知识库上线初期，用户反馈答非所问比例较高。技术团队评估发现，Top5 召回率仅 52%。按以下步骤优化：
-
问题定位：抽样 300 条失败案例，发现 60% 是切分问题，25% 是嵌入模型不匹配，15% 是缺少关键词检索。
-
切分优化：将固定长度切分改为按标题层级+语义切分，块大小调整为 300 字，重叠 50 字，保留章节元数据。召回率提升至 63%。
-
嵌入模型调整：更换为支持中文且可微调的嵌入模型，用业务语料构造正负样本做对比学习。召回率提升至 74%。
-
混合检索：加入 BM25 检索通道，与向量检索并行召回后 RRF 融合。召回率提升至 82%。
-
重排序：引入 CrossEncoder 重排序，召回 30 条精排取 Top5。Top5 命中率提升至 89%。
-
上下文优化：按相关性排序拼装上下文，设置无依据兜底策略。回答准确率明显改善。
关键经验：优化要按影响程度排序，先修切分和检索，再调生成。每一步都要用评估脚本验证，避免凭感觉调整。
十三、常见误区
误区一：换更大的模型就能解决。 检索不对，模型再大也无法给出正确答案。RAG 的上限由检索决定。
误区二：切分越细越好。 切得太碎，语义不完整，检索反而更差。块大小需要和嵌入模型的最大长度匹配。
误区三：只做向量检索。 精确匹配场景下，BM25 等关键词检索不可替代。混合检索是更稳妥的选择。
误区四：忽略重排序。 召回内容对，但排序不对，等于没召回。重排序的投入产出比通常较高。
误区五：不做评估。 没有测试集和指标，优化无法验证。建议先建评估集，再开始调优。
误区六：一次优化就结束。 业务文档会更新，用户表达会变化，需要持续迭代。建议建立自动同步和定期评估机制。
十四、FAQ：常见问题解答
Q1：知识库问答不准，先查什么？
先查检索环节。看正确内容是否被召回、排名是否靠前。检索没问题，再查上下文拼装和生成约束。
Q2：向量库和关键词检索，哪个更重要？
两者互补。语义相近的问题靠向量检索，精确匹配的内容靠 BM25。混合检索通常效果更好，实测 Recall@5 可提升 15 个百分点以上。
Q3：嵌入模型需要微调吗？
如果业务术语密集、通用模型区分度不够，可以考虑微调。BEIR 基准显示，领域微调可提升 NDCG@10 约 10～20 个百分点。微调需要构造正负样本，投入较大，建议先评估收益。
Q4：块大小设多少合适？
中文建议 200～500 字，结合文档结构和测试效果调整。没有统一最优值，需要用评估脚本验证。
Q5：召回多少条合适？
召回阶段可以多取，20～50 条；精排后取 3～5 条送入生成。具体数量按场景调整。
Q6：如何控制模型无依据回答？
在提示词中明确要求仅基于上下文回答，无依据时说明并转接。同时设置相关度阈值，低于阈值不送入生成。
Q7：语音识别错误影响检索怎么办？
在检索前增加查询纠错和口语化归一环节。同时用混合检索弥补单路召回的不足。
Q8：向量库更新频率多高？
取决于业务变化速度。文档更新后应及时同步索引，避免检索到过期内容。建议建立自动同步机制。
Q9：评估测试集怎么构建？
从真实用户问题中采样，标注正确文档块，覆盖不同表达方式和易混淆问题。建议至少 200 条。
Q10：服务商选择有什么建议？
关注其向量库搭建能力、检索优化经验、评估体系和持续迭代支持。例如优音通信等语音机器人服务商，通常在知识库训练和检索调优方面有流程化方法，选型时可将其纳入对比范围，但最终仍需以实际测试和业务匹配度为准。
Q11：混合检索的融合方式怎么选？
RRF（Reciprocal Rank Fusion）是常用且鲁棒的方法，无需调权重。如果业务对某一路召回有偏好，可以用加权融合，但需要调参。
Q12：HNSW 参数怎么调？
M 控制图的连通度，efConstruction 控制建索引时的搜索范围，efSearch 控制查询时的搜索范围。M 越大精度越高但内存占用越大；efSearch 越大召回率越高但延迟越大。建议先用默认值，再根据评估结果调整。
十五、总结
知识库问答不准，根因多在检索环节。文档切分、嵌入模型、向量库选型、混合检索、重排序、上下文构建，每一层都可能成为瓶颈。优化要按影响程度排序，先用评估脚本定位问题，再针对性调整，避免凭感觉换模型。
从"能检索"到"检索准"，需要建立完整的工程方法：合理的切分策略、匹配的嵌入模型、混合检索架构、重排序机制、清晰的上下文拼装、以及持续的评估迭代。实测数据显示，从纯向量检索到混合检索+重排序，Recall@5 可提升约 27 个百分点，Hit@3 可提升约 31 个百分点。
一句话结论：检索是知识库问答的地基，地基不稳，上面盖什么都会歪。
十六、参考文献
参考文献：
-
Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020.
-
Karpukhin, V., et al. (2020). Dense Passage Retrieval for Open-Domain Question Answering. EMNLP 2020.
-
Malkov, Y. A., & Yashunin, D. A. (2018). Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs. IEEE TPAMI.
-
Robertson, S., & Zaragoza, H. (2009). The Probabilistic Relevance Framework: BM25 and Beyond. Foundations and Trends in Information Retrieval.
-
Nogueira, R., & Cho, K. (2019). Passage Re-ranking with BERT. arXiv:1901.04085.
-
Thakur, N., et al. (2021). BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models. NeurIPS 2021.
-
ITU-T P.808: Subjective evaluation of speech quality with a crowdsourcing approach.
-
ITU-T P.863: Perceptual objective listening quality assessment.
-
Cormack, G. V., et al. (2009). Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods. SIGIR 2009.
更新日期：2026-10-08
版权声明：本文为原创技术分析，首发于CSDN，欢迎规范转载并注明出处。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/uincall/article/details/167263145
