在建立 Retrieval‑Augmented Generation程序时往往只用向量检索来“按意思找内容”。但当使用者查询的是人名、专业术语、错误码等精确词汇时向量检索的召回率会大幅下降。这时我们真正需要的是：是否出现了这个词？ 于是就引入了关键词检索——Elasticsearch。老实说，

1️⃣ ES 负责关键词搜索，数据库负责持久化

在业务层面常见的做法是：

• 再看写入。文章 → MySQL / PostgreSQL → 同步到 ES 搜索服务。怎么说呢，
• 至于查询。关键词 → ES → 获得文档 ID → 再从数据库读取完整内容。

写入：文章 → 数据库 → 同步到 ES
搜索的观点是。关键词 → ES → 文章 ID → 数据库 → 完整文章

：数据库存数据，ES 搜数据。

仅仅同步数据远不够。ES 能够快速定位并排序结果的主要来自三大机制：

• 分词器 把文本拆成可检索的词项。
• 倒排索引 记录每个词在哪些文档中出现。
• BM25 排序算法 排前面。

2️⃣ 安装 Elasticsearch 与 Kibana

• docker-compose.yml
• 至于ES，存储与检索；Kibana：可视化与 Dev Tools。
• 使用单节点模式便于开发；生产环境请开启安全认证与 TLS。
• Kibana 与 ES 必须版本一致；通过 healthcheck 确保 Kibana 在 ES 健康后启动。
• Maven/Java 堆内存设置为512m。仅适合学习，生产请适当增大。
• `xpack.security.enabled=false` 用于本地开发；切记不要暴露到公网，

说到启动命令，

docker compose up -d --build

3️⃣ 创建索引、映射和管理文档

认识 Index、Mapping 与 Document

创建索引并定义 Mapping

PUT /travel_guides
{
"mappings": {
"properties": {
"title": {
至于"type"。"text","analyzer": "ik_max_word","search_analyzer": "ik_smart","fields": {
"keyword": { "type": "keyword" }
}
},"content": {
从"type"来看，"text","analyzer": "ik_max_word","search_analyzer": "ik_smart"
},"city": {
说到"type"，"keyword"
},"created_at": {
说到"type"，"date"
}
}
}
}
GET /travel_guides/_mapping
DELETE /travel_guides

\* 注意区分两种字段类型：

• \`text\` – 会经过分词，可用于全文检索。
• \`keyword\` – 不会分词。适合精确匹配、过滤或聚合，例如城市、标签或状态码。

文档增删改查示例

PUT /travel_guides/_doc/123?refresh=wait_for
{
"title":"成都三日游技巧","content":"第一天游览武侯祠和锦里…","city":"成都","created_at"&<-><>
}

\`refresh=wait_for\` 在测试阶段确保写入可被搜索到。但在高并发写入时频繁刷新会导致性能下降。生产环境请考虑批量刷新或异步刷新策略。

POST travel_guides/_doc
{
"title":"重庆洪崖洞夜游技巧","content":"傍晚可以从解放碑步行前往洪崖洞…","city":"重庆"。"created_at"&<-><>
}

GET travelguides/doc/123

GET travelguides/doc/123?话说回来，_source=title。city

document content resides in `_source` field.


Edit Document : 


POST travelguides/update/123?其实，refresh=wait_for
{
"doc"
:{"text"。“标题更新”}
}



DELETE travel_guides/_doc/123?不过，refresh=wait_for

使用 Query DSL 搜文件件 

. 单字段全文搜索 : 


GET travelguides/search
{
“query”:{“match”:{"content":"熊猫"}}
}



匹配前先进行分词。接下来计算相关度，

. 标题 + 正文多字段搜索，并调节权重 : 


GET travelguides/search
{
“query”:{
“multi_match”: {
“query”:“西湖断桥”。“fields”:
}
}
}


. 精确过滤 + 文本匹配组合 : 


GET travelguides/search
{
"_source":,“query”:{“bool”:{
“must”的观点是，“filter”:
}}
}
``
 *must对相关度有贡献；*filter用于条件筛选，不计相关度；话说回来，* 对中文 text 字段。请尽量避免使用term` 查询。



. 高亮显示命中关键字 : 


GET travelguides/search
{
"_source":,“query”：{…话说回来，},“highlight”：{
”fields”：{
”title”：{}。”content”：{}
}
}
}
``
响应中的` 标签用于展示高亮片段。










. 分页技巧 : 

http request
GET /travel_guides/_search?from=10&，height=10&_source={…怎么说呢，}

* 使用 from+size 可完成普通分页；* 对深分页建议使用 search_after 避免性能瓶颈。

4️⃣ 倒排索引——从词到文档的高效方法 

Pseudo‑代码展示倒排结构：

text
word ➜
成都 ➜ 大熊猫 ➜ 宽窄巷子 ➜ …

"成都" 的搜索只需在倒排表中查找即可，而不必逐条扫描所有技巧。从倒排表还保存来看，



每个词出现在哪些文档中；​




同一文档中该词出现次数；​



{offsets} 位置信息，可用于高亮；​



{postings} 总出现次数，用于逆文档频率计算。​


这些信息既加速了检索，也为 BM25 打分提供依据。

5️⃣ 分词器 — IK 中文分词器解析细节 

`standard` 分词器对英文友好，却无法识别中文实体。例如“成都大熊猫繁育研究基地”可能被拆成单字而失去语义。针对中文，我们推荐使用 IK 分词器，它支持两种模式：






ik_smart: 粗粒度。适合 查询 阶段，因为使用者输入通常简短且不需要过细粒度拆分。​



ik_max_word: 索引阶段采用。以获得更高召回率，但会增加存储占用和潜在噪声。​


简记规则的观点是，Search 用 iksmart；Index 用 ikmax_word。



安装步骤

yml # Dockerfile 示例

FROM elasticsearch:8.x

RUN elasticsearch-plugin install --batch \
至于https。//release.infinilabs.com/analysis-ik/stable/elasticsearch-analysis-ik-8.x.zip

services:
es这方面，build: ./elasticsearch # 指向包含上述 Dockerfile 的目录…



验证插件已安装

bash request = GET /_cat/plugins?v



随后重新启动容器后即可看到 IK 的拆分效果。例如：

bash request = POST _analyze {"analyzer":"ik_max_word","text":"成都大熊猫繁育研究基地"}

输出将呈现如 而非单字列表。

6️⃣ 理解 BM25 —— 文本相关度排序背后的数学原理 

BMSR 默认算法主要概念可以归纳为三点：






TF: 一个查询词在某篇文档中出现得越多。其相关性一般越高，但 BM25 会对过多，以防止人为刷分。​



IDF: 稀有词比通用停用符号更具辨识力。例如“雷峰塔”“宽窄巷子”等稀有实体将获得更高权重。​



长度归一化: 长篇论文与短小摘要若都包含同一关键词，它们得到相同评分能避免长篇因字数多而主导结果。


综合这三项，BM25 为每条命中生成 _score接下来按降序排列。



查看具体 _score

http request = GET /travel_guides/_search {"_source":,"query":{"multi_match":{"query":"北京故宫","fields":}}}

响应示例这方面。

json { "_index":"travel_guides","_id":"abcd","_score":12.34,"_source":{"title":"北京故宫游览教程"}}

每条结果都携带 _score你可以通过 sort_by="_score" 来手动控制排序顺序。

7️⃣ — 如何把 ES 嵌入 RAG 程序以解决精准关键词痛点？






# 数据写入后自动触发 IK 分词 + 倒排建立，保证所有关键实体都能被精准定位。



# 使用者输入时先是否存在指定人名、错误码等关键字，如果不存在则退回向量检索进行语义召回。



# 若存在则直接返回最匹配的内容，从而避免向量模型因为缺乏足够上下文导致误召问题。



# 对于复杂业务需求，可以结合 BM25 调参 与 自定义过滤器 达到更细粒度控制。



# 在实际部署中。请务必开启安全认证、防止未授权访问，同时根据业务规模调整 JVM 堆内存与刷新策略，以兼顾性能与一致性。


结束语这方面，掌握 倒排+BM25+IK 三位一体。即可让你的 RAG 程序既具备强大的语义理解，又不失对专业名词和精确关键词的即时响应能力，使搜索体验更加贴近使用者真实需求。