Python - Elasticsearch Labs

利用 Elasticsearch 和 SigLIP-2 对山峰进行多模式搜索

Navneet Kumar — Tue, 04 Nov 2025 00:00:00 GMT

您是否曾想过按含义搜索相册？试着询问 "给我看我穿着蓝色夹克坐在长椅上的照片"、"给我看珠穆朗玛峰的照片 "或 "清酒和寿司"。喝杯咖啡（或您最喜欢的饮料），继续阅读。在本博客中，我们将向您展示如何构建多模态混合搜索应用程序。多模态是指应用程序可以理解和搜索不同类型的输入（文本、图像和音频），而不仅仅是文字。混合式意味着它结合了关键词匹配、kNN 向量搜索和地理围栏等技术，以提供更清晰的结果。

为此，我们使用谷歌的 SigLIP-2 为图像和文本生成矢量嵌入，并将其存储在 Elasticsearch 矢量数据库中。在查询时，我们将搜索输入（文本或图像）转换为嵌入，并运行快速的 kNN 向量搜索来检索结果。这种设置可实现高效的文本到图像和图像到图像搜索。Streamlit 用户界面为我们提供了一个前端，不仅可以进行基于文本的搜索，从相册中查找并查看匹配的照片，还可以从上传的图片中识别山峰，并查看相册中该山峰的其他照片，从而使该项目栩栩如生。我们还介绍了为提高搜索准确性而采取的措施，以及实用技巧和窍门。为便于进一步探索，我们提供了GitHub 存储库和Colab 笔记本。

如何开始

这篇博文的灵感来自于一个 10 岁的孩子，他让我给他们看我在珠峰大本营徒步旅行时拍摄的阿玛达布拉姆山的所有照片。在翻阅相册时，我还被要求辨认其他几座山峰，其中一些我还叫不出名字。

这让我想到，这可以成为一个有趣的计算机视觉项目。我们的目标

按名称查找山峰图片
从图片中猜测山峰名称，并在相册中找到类似的山峰
让概念查询发挥作用（人、河流、祈祷旗 等）

组建梦之队：SigLIP-2、Elasticsearch& Streamlit

很快我们就发现，要想实现这一目标，我们需要将文字（"阿玛达布拉姆"）和图像（我相册中的照片）都转化为可以进行有意义比较的矢量，即在同一个矢量空间中。一旦我们做到了这一点，搜索就只是 "寻找最近的邻居"。

为了生成图像嵌入，我们使用了多语言视觉语言编码器，因此山峰的照片和 "Ama Dablam "这样的短语会出现在同一个向量空间中。

谷歌最近发布的SigLIP-2 在这方面非常适合。它可以在没有特定任务训练的情况下生成嵌入式（零镜头设置），并能很好地适用于我们的使用案例：未标记的照片和具有不同名称和语言的山峰。由于它是针对文本与图像匹配进行训练的，因此即使查询语言或拼写不同，徒步旅行中的山峰图片和简短的文字提示最终也能接近嵌入。

SigLIP-2 在质量与速度之间实现了很好的平衡，支持多种输入分辨率，并可在 CPU 和 GPU 上运行。SigLIP-2 在设计上比以前的型号（如最初的 CLIP）更适合户外拍摄。在我们的测试中，SigLIP-2 始终能生成可靠的结果。此外，它还得到了很好的支持，因此是本项目的不二之选。

接下来，我们需要一个向量数据库来存储嵌入和强力搜索。它不仅应支持对图像嵌入进行余弦 kNN 搜索，还应在单个查询中应用地理围栏和文本过滤器。Elasticsearch 在这方面非常适合：它能很好地处理向量（在 dense_vector 字段上使用 HNSW kNN），支持结合文本、向量和地理查询的混合搜索，并提供开箱即用的过滤和排序功能。它还可以横向扩展，因此很容易从少量照片扩展到数千张照片。最后，我们需要一个轻量级前端，以便输入搜索查询并查看结果。对于基于 Python 的快速演示，Streamlit 非常适合。它提供了我们所需的基本功能--文件上传、响应式图像网格以及用于排序和地理围栏的下拉菜单。它很容易克隆并在本地运行，也可以在 Colab 笔记本中使用。

实施

Elasticsearch 索引设计和索引策略

我们将在这个项目中使用两个索引：peaks_catalog 和photos 。

峰值_目录索引

该索引是珠峰大本营徒步旅行期间可看到的著名山峰的简明目录。该索引中的每份文件都对应一座山峰，如珠穆朗玛峰。对于每个山峰文档，我们都会存储名称/别名、可选的经纬度坐标以及由 SigLIP-2 文本提示（+ 可选的参考图片）混合而成的单一原型向量。

索引映射：

现场

类型

示例

目的/说明

矢量/索引

本我

关键词

阿玛-达布拉姆

稳定的弹头/ID

姓名

文本 + 关键字子字段

["Ama Dablam","Amadablam"]

别名/多语言名称；names.raw 用于精确筛选

纬纶

地理点

{"lat":27.8617,"lon":86.8614}

以经纬度组合形式显示的山顶 GPS 坐标（可选）

海拔_m

整数

6812

海拔（可选）

嵌入文本

dense_vector

768

该山峰的混合原型（提示和可选的 1-3 幅参考图片

index:true, similarity:"cosine", index_options：{type:"hnsw", m:16, ef_construction:128}

该索引主要用于图像到图像的搜索，例如从图像中识别山峰。我们还使用该索引来增强文本到图片的搜索结果。

总之，peaks_catalog 将问题""这是什么山？" "转化为一个重点突出的 "最近邻问题"，有效地将概念理解与图像数据的复杂性分离开来。

peaks_catalog 索引的索引策略： 首先，我们创建了一份在 EBC 徒步旅行中可见的最突出山峰的列表。对于每个山峰，我们都会在yaml 文件中存储其地理位置、名称、同义词和海拔高度。下一步是生成每个峰值的嵌入值，并将其存储在text_embed 字段中。为了生成稳健的嵌入，我们使用了以下技术：

创建文本原型：
- 山峰名称
- 提示组合（使用多个不同的提示来尝试回答同一个问题），例如
  - "尼泊尔喜马拉雅山脉山峰的自然照片{name} "
  - "{name} 昆布地区的地标性山峰，高山景观"
  - "{name} 山顶，积雪，岩石山脊线"
- 可选的反概念（告诉 SigLIP-2 什么不能匹配）：为 "绘画、插图、海报、地图、徽标 "减去一个小矢量，这样我们就偏向于真实照片。
如果提供了峰值的参考图像，可选择创建图像原型。

然后，我们混合文本和图像原型，生成最终的嵌入。最后，文件将被索引到所有必填字段：

def l2norm(v: np.ndarray) -> np.ndarray: return v / (np.linalg.norm(v) + 1e-12) def compute_blended_peak_vec( emb: Siglip2, names: List[str], peak_id: str, peaks_images_root: str, alpha_text: float = 0.5, max_images: int = 3, ) -> Tuple[np.ndarray, int, int, List[str]]: """ Build blended vector for a single peak. Returns: vec : np.ndarray (L2-normalized) found_count : number of reference images discovered used_count : number of references used (<= max_images) used_filenames: list of filenames used (for logging) """ # 1) TEXT vector tv = embed_text_blend(emb, names) # 2) IMAGE refs: prefer folder by id; fallback to slug of the primary name root = Path(peaks_images_root) candidates = [root / peak_id] if names: candidates.append(root / slugify(names[0])) all_refs: List[Path] = [] for c in candidates: if c.exists() and c.is_dir(): all_refs = list_ref_images(c) if all_refs: break found = len(all_refs) used_list = all_refs[:max_images] if (max_images and found > max_images) else all_refs used = len(used_list) img_v = embed_image_mean(emb, used_list) if used_list else None # 3) Blend TEXT and IMAGE vectors, clamp alpha to [0,1] a = max(0.0, min(1.0, float(alpha_text))) vec = l2norm(tv if img_v is None else (a * tv + (1.0 - a) * img_v)).astype("float32") return vec, found, used, [p.name for p in used_list]

peaks_catalog 索引中的文件样本：

照片索引

该主索引存储相册中所有照片的详细信息。每份文档代表一张照片，包含以下信息：

相册中照片的相对路径。可用于查看匹配图像或在搜索用户界面中加载图像。
图片的 GPS 和时间信息。
SigLIP-2 生成的图像编码密集矢量。
predicted_peaks 可让我们根据峰名进行筛选。索引映射

现场

类型

示例

目的/说明

矢量/索引

路径

关键词

data/images/IMG_1234.HEIC

用户界面如何打开缩略图/全图

剪贴图片

dense_vector

768

SigLIP-2 图像嵌入

index:true, similarity:"cosine", index_options：{type:"hnsw", m:16, ef_construction:128}

预测峰值

关键词

["ama-dablam","pumori"]

索引时的 Top-K 猜想（廉价用户体验过滤器/面）

全球定位系统

地理点

{"lat":27.96,"lon":86.83}

启用地理筛选器

拍摄时间

date

2023-10-18T09:41:00Z

捕捉时间：排序/过滤

照片索引的索引策略： 对于相册中的每张照片，我们会采取以下措施：从图像元数据中提取图像shot_time 和gps 信息。

SigLIP-2 图像嵌入：通过模型传递图像并对向量进行 L2 归一化。将嵌入内容存储在clip_image 字段中。
预测峰值并将其存储在predicted_peaks 字段中。为此，我们首先获取上一步生成的照片图像向量，然后针对peaks_catalog 索引中的 text_embed 字段快速运行 kNN 搜索。我们保留顶部的 3-4 个山峰，忽略其余的。
我们通过对图片名称和路径进行散列计算_id 字段。这可以确保我们在多次运行后不会出现重复。

一旦我们确定了照片的所有字段，就会使用批量索引对照片文件进行批量索引：

def bulk_index_photos( es: Elasticsearch, images_root: str, photos_index: str = "photos", peaks_index: str = "peaks_catalog", topk_predicted: int = 5, batch_size: int = 200, refresh: str = "false", ) -> None: """Walk a folder of images, embed + enrich, and bulk index to Elasticsearch.""" root = Path(images_root) if not root.exists(): raise SystemExit(f"Images root not found: {images_root}") emb = Siglip2() batch: List[Dict[str, Any]] = [] n_indexed = 0 for p in iter_images(root): rel = relpath_within(root, p) _id = id_for_path(rel) # 1) Image embedding (and reuse it for predicted_peaks) try: with Image.open(p) as im: ivec = emb.image_vec(im.convert("RGB")).astype("float32") except (UnidentifiedImageError, OSError) as e: print(f"[skip] {rel} — cannot embed: {e}") continue # 2) Predict top-k peak names try: top_names = predict_peaks(es, ivec.tolist(), peaks_index=peaks_index, k=topk_predicted) except Exception as e: print(f"[warn] predict_peaks failed for {rel}: {e}") top_names = [] # 3) EXIF enrichment (safe) gps = get_gps_decimal(str(p)) shot = get_shot_time(str(p)) # 4) Build doc and stage for bulk doc = {"path": rel, "clip_image": ivec.tolist(), "predicted_peaks": top_names} if gps: doc["gps"] = gps if shot: doc["shot_time"] = shot batch.append( {"_op_type": "index", "_index": photos_index, "_id": _id, "_source": doc} ) # 5) Periodic flush if len(batch) >= batch_size: helpers.bulk(es, batch, refresh=refresh) n_indexed += len(batch) print(f"[photos] indexed {n_indexed} (last: {rel})") batch.clear() # Final flush if batch: helpers.bulk(es, batch, refresh=refresh) n_indexed += len(batch) print(f"[photos] indexed {n_indexed} total.") print("[done] photos indexing")

照片索引中的样本文件：

总之，照片索引是相册中所有照片的快速、可过滤、kNN 就绪存储。它的映射结构非常简单，只需足够的结构就能快速检索、清晰显示，并按空间和时间对结果进行切分。该索引可同时满足这两种搜索用途。创建这两个索引的 Python 脚本可在此处找到。

下面的 Kibana 地图可视化将相册中的文档显示为绿色圆点，将peaks_catalog 索引中的山峰显示为红色三角形，其中绿色圆点与珠峰大本营徒步路线非常吻合。

搜索用例

按名称搜索（文本到图像）：该功能可让用户使用文本查询查找山峰照片（甚至是 "祈祷旗 "等抽象概念）。为此，使用 SigLIP-2 将文本输入转换为文本向量。为了生成稳健的文本向量，我们采用了与在peaks_catalog 索引中创建文本嵌入相同的策略：将文本输入与小型提示集合相结合，减去次要的反概念向量，并应用 L2 归一化生成最终的查询向量。然后在photos.clip_image 字段上执行 kNN查询，根据余弦相似度检索匹配度最高的峰值，从而找到最接近的图像。作为查询的一部分，还可选择应用地理和日期筛选器和/或photos.predicted_peaks 术语筛选器来提高搜索结果的相关性（见下文查询示例）。这有助于排除在徒步过程中看不到的相似山峰。

带有地理过滤器的 Elasticsearch 查询：

POST photos/_search { "knn": { "field": "clip_image", "query_vector": [ ... ], "k": 60, "num_candidates": 2000 }, "query": { "bool": { "filter": [ { "geo_bounding_box": { "gps": { "top_left": "...", "bottom_right": "..." } } } ] } }, "_source": ["path","predicted_peaks","gps","shot_time"] } Response (first two documents): { "hits": { "total": { "value": 56, "relation": "eq" }, "max_score": 0.5779596, "hits": [ { "_index": "photos", "_id": "d01da3a1141981486c3493f6053c79e92a788463", "_score": 0.5779596, "_source": { "path": "IMG_2738.HEIC", "predicted_peaks": [ "Pumori", "Kyajo Ri", "Khumbila", "Nangkartshang", "Kongde Ri" ], "gps": { "lat": 27.97116388888889, "lon": 86.82331111111111 }, "shot_time": "2023-11-03T08:07:13" } }, { "_index": "photos", "_id": "c79d251f07adc5efaedc53561110a7fd78e23914", "_score": 0.5766071, "_source": { "path": "IMG_2761.HEIC", "predicted_peaks": [ "Kyajo Ri", "Makalu", "Baruntse", "Cho Oyu", "Khumbila" ], "gps": { "lat": 27.975558333333332, "lon": 86.82515 }, "shot_time": "2023-11-03T08:51:08" } } }

按图像搜索（图像到图像）：通过该功能，我们可以识别照片中的某座山，并在相册中查找该座山的其他图像。图像上传后，将由 SigLIP-2 图像编码器处理，生成图像矢量。然后在peaks_catalog.text_embed 字段上进行kNN 搜索，以确定最匹配的峰值名称。随后，根据这些匹配的山峰名称生成一个文本向量，并在照片索引中进行另一次 kNN 搜索，以找到相应的照片。

Elasticsearch 查询：

第 1 步：找到匹配的山峰名称

GET peaks_catalog/_search { "knn": { "field": "text_embed", "query_vector": [...image-vector... ], "k": 3, "num_candidates": 500 }, "_source": [ "id", "names", "latlon", "text_embed" ] } Response (first two documents): { "took": 2, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 3, "relation": "eq" }, "max_score": 0.58039916, "hits": [ { "_index": "peaks_catalog", "_id": "pumori", "_score": 0.58039916, "_source": { "id": "pumori", "names": [ "Pumori", "Pumo Ri" ], "latlon": { "lat": 28.01472, "lon": 86.82806 }, "text_embed": [ ... embeddings... ] } }, { "_index": "peaks_catalog", "_id": "kyajo-ri", "_score": 0.57942784, "_source": { "id": "kyajo-ri", "names": [ "Kyajo Ri", "Kyazo Ri" ], "latlon": { "lat": 27.909167, "lon": 86.673611 }, "text_embed": [ ... embeddings... ] } } ] } }

第 2 步：在photos 索引上进行搜索，找到匹配的图片（与文本到图片搜索用例中的查询相同）：

POST photos/_search { "knn": { "field": "clip_image", "query_vector": [ ...image-vector... ], "k": 30, "num_candidates": 2000 }, "_source": [ "path", "gps", "shot_time", "predicted_peaks", "clip_image" ], "query": { "bool": { "filter": [ { "term": { "predicted_peaks": "Pumori" } } ] } } } Response (first two documents): { "hits": { "total": { "value": 56, "relation": "eq" }, "max_score": 0.5779596, "hits": [ { "_index": "photos", "_id": "d01da3a1141981486c3493f6053c79e92a788463", "_score": 0.5779596, "_source": { "path": "IMG_2738.HEIC", "predicted_peaks": [ "Pumori", "Kyajo Ri", "Khumbila", "Nangkartshang", "Kongde Ri" ], "gps": { "lat": 27.97116388888889, "lon": 86.82331111111111 }, "shot_time": "2023-11-03T08:07:13" } }, { "_index": "photos", "_id": "c79d251f07adc5efaedc53561110a7fd78e23914", "_score": 0.5766071, "_source": { "path": "IMG_2761.HEIC", "predicted_peaks": [ "Kyajo Ri", "Makalu", "Baruntse", "Cho Oyu", "Khumbila" ], "gps": { "lat": 27.975558333333332, "lon": 86.82515 }, "shot_time": "2023-11-03T08:51:08" } } }

流光 UI

为了将所有功能整合在一起，我们创建了一个简单的 Streamlit 用户界面，让我们可以同时执行两种搜索用例。左侧栏显示可滚动的峰值列表（从photos.predicted_peaks 中汇总），并带有复选框和小地图/地理过滤器。顶部有一个按姓名搜索框和一个从照片上传识别按钮。中心窗格采用响应式缩略图网格，显示 kNN 分数、预测峰值徽章和捕获时间。每张图片都有一个查看图片按钮，用于全分辨率预览。

通过上传图片进行搜索：我们会预测峰值，并从相册中找到匹配的峰值。

文本搜索从文本中查找相册中匹配的峰值

结论

我们能看看 阿玛-达布拉姆 的照片吗？变成了一个可运行的小型多模态搜索系统。我们采集了原始的徒步旅行照片，将其转化为SigLIP-2 嵌入，并使用Elasticsearch对向量进行快速的kNN处理，再加上简单的地理/时间过滤器，根据意义浮现出正确的图像。在此过程中，我们将两个索引的关注点分开：一个是混合原型的小peaks_catalog （用于识别），另一个是图像向量和 EXIF 的可扩展photos 索引（用于检索）。它实用、可复制、易扩展。

如果您想对其进行调整，有几项设置可供使用：

查询时间设置： k （您希望返回多少个邻居）和num_candidates （最终评分前的搜索范围）。这些设置将在此处的博客中讨论。
索引时间设置： m （图形连接性）和ef_construction （构建时间精度与内存）。对于查询，也可以尝试使用ef_search --更高通常意味着更高的召回率，但需要权衡一定的延迟。有关这些设置的更多详情，请参阅本博客。

展望未来，用于多模态和多语言搜索的本地模型/路由器即将登陆 Elastic生态系统，这将使图像/文本检索和混合排名功能更加强大。

如果你想亲自尝试一下：

GitHub 代码库 ： https://github.com/navneet83/multimodal-mountain-peak-search
Colab 快速入门 ：https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

我们的旅程就此结束，是时候飞回去了。希望这对你有帮助，如果你改动（或改进）了它，我很乐意听听你的改动。

使用基于用户行为数据的判断列表在 Elasticsearch 中训练 LTR 模型

Alexander Dávila — Wed, 15 Oct 2025 00:00:00 GMT

使用"学习-排名 "模型的一大挑战是创建一个高质量的判断列表来训练模型。传统上，这一过程需要对查询与文档的相关性进行人工评估，为每个文档分配一个等级。这是一个缓慢的过程，不能很好地扩展，也很难维护（想象一下要手工更新一个有数百个条目的列表）。

现在，如果我们可以使用真实用户与搜索应用程序的交互来创建这些训练数据，会怎样呢？使用UBI数据可以让我们做到这一点。创建一个自动系统，捕捉并利用我们的搜索、点击和其他互动来生成判断列表。与人工交互相比，这一过程更容易扩展和重复，而且往往会产生更好的结果。在本博客中，我们将探讨如何查询存储在 Elasticsearch 中的 UBI 数据，以计算有意义的信号，从而为LTR模型生成训练数据集。

您可以 在这里找到完整的实验。

为什么 UBI 数据有助于训练 LTR 模型？

与人工标注相比，UBI 数据具有多项优势：

数量：鉴于 UBI 数据来自真实的互动，我们可以收集到比人工生成的数据多得多的数据。当然，前提是我们有足够的流量来生成这些数据。
真实用户意图：传统上，人工判断列表来自专家对可用数据的评估。另一方面，UBI 数据反映了真实的用户行为。这意味着我们可以生成更好的训练数据，从而提高搜索系统的准确性，因为这些数据是基于用户如何与您的内容进行实际互动并从中发现价值的，而不是对相关内容的理论假设。
不断更新：判断列表需要不断刷新。如果我们根据 UBI 数据创建它们，我们就可以获得最新的数据，从而更新判断列表。
成本效益高：无需手动创建判断列表，可多次高效重复这一过程。
自然查询分布：UBI 数据代表真实的用户查询，可推动更深层次的变化。例如，用户是否使用自然语言在我们的系统中进行搜索？如果是这样，我们可能需要采用语义搜索或混合搜索方法。

不过也有一些警告：

偏见放大： 热门内容更容易获得点击，因为它的曝光率更高。因此，这最终可能会放大热门项目，可能会淹没更好的选择。
覆盖面不全： 新内容缺乏互动，因此可能难以在结果中占据重要位置。罕见查询也可能缺乏足够的数据点来创建有意义的训练数据。
季节性变化：如果您预期用户行为会随时间发生巨大变化，那么历史数据可能无法告诉您什么是好结果。
任务模糊：点击并不总能保证用户找到想要的东西。

成绩计算

LTR 培训的成绩

为了训练 LTR 模型，我们需要提供一些数字来表示文档与查询的相关程度。在我们的实施过程中，这个数字是一个连续的分数，从 0.0 到 5.0+，分数越高表示相关性越高。

为了说明这个分级系统是如何运行的，请看这个手动创建的示例：

查询

文件内容

等级

说明

"最佳比萨饼配方"

"正宗意大利比萨面团配方及步骤图片"

4.0

高度相关，正是用户正在寻找的内容

"最佳比萨饼配方"

"意大利比萨的历史"

1.0

与主题有点吻合，是关于披萨的，但不是食谱

"最佳比萨饼配方"

"适合初学者的 15 分钟快速比萨食谱"

3.0

这是个不错的结果，但也许还达不到 "最佳 "配方的标准。

"最佳比萨饼配方"

"汽车保养指南"

0.0

完全不相关，与查询完全无关

正如我们在这里看到的，等级是一个数字，表示文档与我们的样本查询 "最佳披萨配方 "的相关程度。有了这些分数，我们的 LTR 模型就能知道哪些文档应该在结果中显示得更高。

如何计算等级是我们训练数据集的核心。有多种方法可以做到这一点，每种方法都有自己的优缺点。例如，我们可以分配一个二进制分数，1 表示相关 0 表示不相关，或者我们可以只计算每个查询结果文档中的点击次数。

在这篇博文中，我们将采用一种不同的方法，将用户行为作为我们的输入，并计算出一个等级数字作为输出。我们还将纠正可能出现的偏差，因为无论文件的相关性如何，结果越靠前，点击率越高。

计算成绩 - COEC 算法

COEC（点击量大于预期点击量）算法是一种根据用户点击量计算判断等级的方法。如前所述，用户倾向于点击位置较高的结果，即使该文档并非与查询最相关；这就是所谓的位置偏差。使用 COEC 算法的核心理念是，并非所有点击都具有同等意义；点击位置 10 的文档表明，该文档与查询的相关性远高于点击位置 1 的文档。引用有关 COEC 算法的研究论文（如上链接）：

"众所周知，搜索结果或广告的点击率（CTR）会随着搜索结果的位置而显著降低"。

您可以在这里进一步了解位置偏差。

为了利用 COEC 算法解决这个问题，我们采取了以下步骤：

1.建立位置基线：我们计算每个搜索位置（从 1 到 10）的点击率（CTR）。这意味着我们要确定点击位置 1、位置 2 等的用户比例。这一步骤可捕捉用户的自然位置偏差。我们使用以下方法计算点击率：

在哪里？

p = 位置。从 1 到 10 Cp = 在所有查询中，任何文档在位置 p 上的总点击次数 Ip = 总印象次数：在所有查询中，任何文档在位置 p 上出现的次数

在这里，我们希望位置越高，点击越多。

2. 计算预期点击量 (EC)：

该指标根据文档出现的位置和这些位置的点击率，确定文档 "本应 "获得的点击量：

在哪里？

Qd = 文档 d 出现的所有查询 pos(d,q)= 文档 d 在查询结果 q 中的位置

3.统计实际点击量：我们统计文档在所有查询中实际获得的总点击量，以下称为A(d)。

4.计算 COEC 分数：这是实际点击量（A(d)）与预期点击量（EC(d)）之比：

该指标对位置偏差进行了这样的归一化处理：

得分 1.0 表示文档在出现的位置上表现完全符合预期。
得分高于 1.0 表示该文件的位置表现优于预期。因此，这份文件与查询更相关。
如果得分低于 1.0，则表示该文件的表现不如预期。因此，该文件与查询的相关性较低。

最终结果是一个等级数字，它能反映用户正在寻找什么，并考虑到从与我们搜索系统的实际互动中提取的基于位置的期望值。

技术实施

我们将创建一个脚本来创建判断列表，以训练 LTR 模型。

该脚本的输入是 Elastic 中索引的 UBI 数据（查询和事件）。

输出结果是使用 COEC 算法从这些 UBI 文档生成的 CSV 文件中的判断列表。该判断列表可与Eland结合使用，以提取相关特征并训练 LTR 模型。

快速启动

要根据本博客中的样本数据生成判断列表，可以按照以下步骤操作：

1.克隆版本库：

git clone https://github.com/Alex1795/elastic-ltr-judgement_list-blog.git cd elastic-ltr-judgement_list-blog

2.安装所需程序库

对于这个脚本，我们需要以下库：

熊猫：保存判断列表
elasticsearch：从我们的弹性部署中获取 UBI 数据

我们还需要 Python 3.11

pip install -r requirements.txt

3.在.env 文件中更新弹性部署的环境变量

ES_HOST
API_KEY

要添加环境变量，请使用

source .env

4.创建 ubi_queries、ubi_events 索引，并上传样本数据。运行 setup.py 文件：

python setup.py

5.运行 Python 脚本：

python judgement_list-generator.py

如果按照这些步骤操作，你应该会看到一个名为 judgment_list.csv 的新文件，它看起来像这样：

该脚本将使用下图所示的calculate_relevance_grade()函数，应用之前讨论过的 COEC 算法计算等级。

数据架构

乌比查询

我们的 UBI 查询索引包含在搜索系统中执行的查询信息。这是一份样本文件：

{ "client_id": "client_002", "query": "italian pasta recipes", "query_attributes": { "search_type": "recipe", "category": "food", "cuisine": "italian" }, "query_id": "q002", "query_response_id": "qr002", "query_response_object_ids": [ "doc_011", "doc_012", "doc_013", "doc_014", "doc_015", "doc_016", "doc_017", "doc_018", "doc_019", "doc_020" ], "timestamp": "2024-08-14T11:15:00Z", "user_query": "italian pasta recipes" }

在这里，我们可以看到来自用户（client_id）、查询结果（query_response_object_ids）和查询本身（时间戳、user_query）的数据。

Ubi 点击事件

我们的 ubi_events 索引拥有用户每次点击结果中的文档时产生的数据。这是一份样本文件：

{ "action_name": "click", "application": "recipe_search", "client_id": "client_001", "event_attributes": { "object": { "description": "Authentic Italian Pizza Dough Recipe with Step-by-Step Photos", "device": "desktop", "object_id": "doc_001", "position": { "ordinal": 1, "page_depth": 1 }, "user": { "city": "New York", "country": "USA", "ip": "192.168.1.100", "location": { "lat": 40.7128, "lon": -74.006 }, "region": "NY" } } }, "message": "User clicked on document doc_001", "message_type": "click", "query_id": "q001", "timestamp": "2024-08-14T10:31:00Z", "user_query": "best pizza recipe" }

判断列表生成脚本

脚本概述

该脚本使用存储在 Elasticsearch 中的来自查询和点击事件的 UBI 数据自动生成判断列表。它执行这些任务：

获取并处理 Elasticsearch 中的 UBI 数据。
将 UBI 事件与其查询相关联。
计算每个位置的点击率。
计算每份文档的预期点击量 (EC)。
计算每份文档的实际点击次数。
计算每个查询-文档配对的 COEC 分数。
生成判断列表并将其写入 CSV 文件。

让我们逐一了解这些功能：

connect_too_elasticsearch()

def connect_to_elasticsearch(host, api_key): """Create and return Elasticsearch client""" try: es = Elasticsearch( hosts=[host], api_key=api_key, request_timeout=60 ) # Test the connection if es.ping(): print(f"✓ Successfully connected to Elasticsearch at {host}") return es else: print("✗ Failed to connect to Elasticsearch") return None except Exception as e: print(f"✗ Error connecting to Elasticsearch: {e}") return None

该函数使用主机和 api 密钥返回 Elasticsearch 客户端对象。

fetch_ubi_data()

def fetch_ubi_data(es_client: Elasticsearch, queries_index: str, events_index: str, size: int = 10000) -> Tuple[List[Dict], List[Dict]]: """ Fetch UBI queries and events data from Elasticsearch indices. Args: es_client: Elasticsearch client queries_index: Name of the UBI queries index events_index: Name of the UBI events index size: Maximum number of documents to fetch Returns: Tuple of (queries_data, events_data) """ logger.info(f"Fetching data from {queries_index} and {events_index}") # Fetch queries with error handling try: queries_response = es_client.search( index=queries_index, body={ "query": {"match_all": {}}, "size": size } ) queries_data = [hit['_source'] for hit in queries_response['hits']['hits']] logger.info(f"Fetched {len(queries_data)} queries") except Exception as e: logger.error(f"Error fetching queries from {queries_index}: {e}") raise # Fetch events (only click events for now) with error handling try: events_response = es_client.search( index=events_index, body={ "query": { "term": {"message_type.keyword": "CLICK_THROUGH"} }, "size": size } ) events_data = [hit['_source'] for hit in events_response['hits']['hits']] logger.info(f"Fetched {len(events_data)} click events") except Exception as e: logger.error(f"Error fetching events from {events_index}: {e}") raise logger.info(f"Data fetch completed successfully - Queries: {len(queries_data)}, Events: {len(events_data)}") return queries_data, events_data

该函数是数据提取层；它连接 Elasticsearch，使用 match_all 查询获取 UBI 查询，并过滤 UBI 事件，只获取 "CLICK_THROUGH "事件。

process_ubi_data()

def process_ubi_data(queries_data: List[Dict], events_data: List[Dict]) -> pd.DataFrame: """ Process UBI data and generate judgment list. Args: queries_data: List of query documents from UBI queries index events_data: List of event documents from UBI events index Returns: DataFrame with judgment list (qid, docid, grade, keywords) """ logger.info("Processing UBI data to generate judgment list") # Group events by query_id clicks_by_query = {} for event in events_data: query_id = event['query_id'] if query_id not in clicks_by_query: clicks_by_query[query_id] = {} # Extract clicked document info object_id = event['event_attributes']['object']['object_id'] position = event['event_attributes']['object']['position']['ordinal'] clicks_by_query[query_id][object_id] = { 'position': position, 'timestamp': event['timestamp'] } judgment_list = [] # Process each query for query in queries_data: query_id = query['query_id'] user_query = query['user_query'] document_ids = query['query_response_object_ids'] # Get clicks for this query query_clicks = clicks_by_query.get(query_id, {}) # Generate judgment for each document shown for doc_id in document_ids: grade = calculate_relevance_grade(doc_id, query_clicks, document_ids, queries_data, events_data) judgment_list.append({ 'qid': query_id, 'docid': doc_id, 'grade': grade, 'query': user_query }) df = pd.DataFrame(judgment_list) logger.info(f"Generated {len(df)} judgment entries for {df['qid'].nunique()} unique queries") return df

该函数处理判断列表的生成。它通过关联 UBI 事件和查询，开始处理 UBI 数据。然后，它会调用每个文档-查询对的 calculate_relevance_grade() 函数来获取判断列表的条目。最后，它会以 pandas 数据帧的形式返回结果列表。

计算相关性等级()

def calculate_relevance_grade(document_id: str, clicks_data: Dict, query_response_ids: List[str], all_queries_data: List[Dict] = None, all_events_data: List[Dict] = None) -> float: """ Calculate COEC (Click Over Expected Clicks) relevance score for a document. Args: document_id: ID of the document clicks_data: Dictionary of clicked documents with their positions for current query query_response_ids: List of document IDs shown in search results (ordered by position) all_queries_data: All queries data for calculating position CTR averages all_events_data: All events data for calculating position CTR averages Returns: COEC relevance score (continuous value, typically 0.0 to 5.0+) """ # If no global data provided, fall back to simple position-based grading if all_queries_data is None or all_events_data is None: logger.warning("No global data provided, falling back to position-based grading") # Simple fallback logic if document_id in clicks_data: position = clicks_data[document_id]['position'] if position > 3: return 4.0 elif position >= 1 and position <= 3: return 3.0 if document_id in query_response_ids: position = query_response_ids.index(document_id) + 1 if position <= 5: return 2.0 elif position >= 6 and position <= 10: return 1.0 return 0.0 # Calculate rank-aggregated click-through rates position_ctr_averages = {} position_impression_counts = {} position_click_counts = {} # Initialize counters for pos in range(1, 11): # Positions 1-10 position_impression_counts[pos] = 0 position_click_counts[pos] = 0 # Count impressions (every document shown contributes) for query in all_queries_data: for i, doc_id in enumerate(query['query_response_object_ids'][:10]): # Top 10 positions position = i + 1 position_impression_counts[position] += 1 # Count clicks by position for event in all_events_data: if event.get('action_name') == 'click': position = event['event_attributes']['object']['position']['ordinal'] if position <= 10: position_click_counts[position] += 1 # Calculate average CTR per position for pos in range(1, 11): if position_impression_counts[pos] > 0: position_ctr_averages[pos] = position_click_counts[pos] / position_impression_counts[pos] else: position_ctr_averages[pos] = 0.0 # Calculate expected clicks for this specific document expected_clicks = 0.0 # Count how many times this document appeared at each position for any query for query in all_queries_data: if document_id in query['query_response_object_ids']: position = query['query_response_object_ids'].index(document_id) + 1 if position <= 10: expected_clicks += position_ctr_averages[position] # Count total actual clicks for this document across all queries actual_clicks = 0 for event in all_events_data: if (event.get('action_name') == 'click' and event['event_attributes']['object']['object_id'] == document_id): actual_clicks += 1 # Calculate COEC score if expected_clicks > 0: coec_score = actual_clicks / expected_clicks else: coec_score = 0.0 logger.debug( f"Document {document_id}: {actual_clicks} clicks / {expected_clicks:.3f} expected = {coec_score:.3f} COEC") return coec_score

这是实现 COEC 算法的函数。它先计算每个位置的点击率，然后比较文档-查询配对的实际点击率，最后计算每个位置的实际 COEC 分数。

generate_judgment_statistics()

def generate_judgment_statistics(df: pd.DataFrame) -> Dict: """Generate statistics about the judgment list.""" stats = { 'total_judgments': len(df), 'unique_queries': df['qid'].nunique(), 'unique_documents': df['docid'].nunique(), 'grade_distribution': df['grade'].value_counts().to_dict(), 'avg_judgments_per_query': len(df) / df['qid'].nunique() if df['qid'].nunique() > 0 else 0, 'queries_with_clicks': len(df[df['grade'] > 1]['qid'].unique()), 'click_through_rate': len(df[df['grade'] > 1]) / len(df) if len(df) > 0 else 0 } return stats

它能从判断列表中生成有用的统计数据，如查询总数、唯一文档总数或等级分布。这纯粹是为了提供信息，不会改变最终的判断列表。

成果和影响

如果您按照快速入门部分的说明进行操作，您应该会看到一个 CSV 文件，其中包含一个有 320 个条目的判断列表（您可以在软件仓库中看到输出示例）。有了这些字段：

qid：查询的唯一 ID
docid：生成文件的唯一标识符
等级：查询文件对的计算等级
查询：用户查询

让我们看看 "意大利菜谱 "的查询结果：

qid

docid

职级

查询

Q1 意大利食谱

基本食谱

0.0

意大利食谱

Q1 意大利食谱

菜谱_比萨_玛格丽塔

3.333333

意大利食谱

Q1 意大利食谱

菜谱指南

10.0

意大利食谱

Q1 意大利食谱

法式羊角面包食谱

0.0

意大利食谱

Q1 意大利食谱

西班牙海鲜饭食谱

0.0

意大利食谱

Q1 意大利食谱

希腊穆萨卡菜谱

1.875

意大利食谱

我们可以从结果中看到，查询 "意大利菜谱"：

烩饭食谱无疑是该查询的最佳结果，其点击率比预期高出 10 倍
玛格丽塔比萨也是不错的选择。
希腊 Mousaka（令人吃惊）也取得了不错的成绩，其表现要好于它在比赛中的位置。这意味着一些寻找意大利食谱的用户转而对这一食谱感兴趣。也许这些用户普遍对地中海菜肴感兴趣。最后，这告诉我们，在我们上面讨论的另外两场 "更好 "的比赛中，这可能是一个很好的结果。

结论

利用 UBI 数据，我们可以自动训练 LTR 模型，从自己的用户中创建高质量的判断列表。UBI 数据提供了一个大数据集，反映了我们的搜索系统是如何被使用的。通过使用 COEC 算法来生成等级，我们可以考虑到固有的偏差，同时，它也反映了用户认为更好的结果。本文概述的方法可应用于实际使用案例，以提供更好的搜索体验，并随着实际使用趋势的变化而变化。

使用 ES|QL 进行 Elasticsearch 地理空间搜索

Craig Taverner — Mon, 12 Aug 2024 00:00:00 GMT

多年来，Elasticsearch 一直拥有强大的地理空间搜索和分析功能，但其应用程序接口与典型 GIS 用户习惯的应用程序接口大相径庭。去年，我们添加了 ES|QL 查询语言，这是一种管道式查询语言，与 SQL 一样简单，甚至更容易。它特别适合 Elastic 擅长的搜索、安全和可观察性用例。我们还在 ES|QL 中添加了对地理空间搜索和分析的支持，使其更易于使用，特别是对于来自 SQL 或GIS社区的用户。

Elasticsearch 8.12 和 8.13 为 ES|QL 带来了对地理空间类型的基本支持。8.14 版增加了地理空间搜索功能后，这一功能大大增强。更重要的是，这种支持的设计与其他空间数据库（如 PostGIS ）使用的开放地理空间联盟（OGC）的简单地物访问标准非常一致，使熟悉这些标准的 GIS 专家更容易使用。

在本博客中，我们将向您介绍如何使用 ES|QL 执行地理空间搜索，以及它与 SQL 和查询 DSL 的等效功能的比较。我们还将向您展示如何使用 ES|QL 执行空间连接，以及如何在 Kibana 地图中将结果可视化。请注意，此处描述的所有功能都在"技术预览版" 中，我们非常乐意听取您对我们如何改进这些功能的反馈意见。

搜索地理空间数据

让我们从一个查询示例开始：

FROM airport_city_boundaries | WHERE ST_INTERSECTS( city_boundary, "POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))"::geo_shape ) | KEEP abbrev, airport, region, city, city_location

这将搜索与三亚凤凰国际机场 (SYX) 周围矩形搜索多边形相交的任何城市边界多边形。

在一个包含机场、城市和城市边界的示例数据集中，该搜索可找到相交的多边形，并从匹配文档中返回所需字段：

缩写

机场

地区

城市

城市位置

SYX

三亚凤凰国际机场

天涯区

三亚

point(109.5036 18.2533)

这很容易！现在将其与经典的 Elasticsearch 查询 DSL 进行比较：

GET /airport_city_boundaries/_search { "_source": ["abbrev", "airport", "region", "city", "city_location"], "query": { "geo_shape": { "city_boundary": { "shape": { "type": "polygon", "coordinates" : [[ [109.4, 18.1], [109.6, 18.1], [109.6, 18.3], [109.4, 18.3], [109.4, 18.1] ]] } } } } }

这两个查询的意图都相当明确，但 ES|QL 查询与 SQL 非常相似。同样的查询在 PostGIS 中是这样的：

SELECT abbrev, airport, region, city, city_location FROM airport_city_boundaries WHERE ST_INTERSECTS( city_boundary, 'SRID=4326;POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'::geometry );

请看 ES|QL 的例子。如此相似，不是吗？

我们发现，Elasticsearch API 的现有用户发现 ES|QL 更易于使用。现在，我们希望现有的 SQL 用户，尤其是空间 SQL 用户，会发现 ES|QL 与他们习惯看到的感觉非常相似。

为什么不是 SQL？

Elasticsearch SQL 如何？它已经存在了一段时间，并具有一些地理空间功能。不过，Elasticsearch SQL 是作为原始查询 API 的封装器编写的，这意味着只支持可转译到原始 API 的查询。ES|QL 没有这种限制。作为一个全新的堆栈，它可以进行许多 SQL 无法实现的优化。我们的基准测试表明，ES|QQL 通常比查询 API 更快，尤其是在聚合方面！

与 SQL 的区别

显然，从前面的例子来看，ES|QL 与 SQL 有些相似，但也有一些重要的区别。例如，ES|QL 是一种管道式查询语言，它以 FROM 等源命令开始，然后用管道 | 字符将所有后续命令串联起来。这样就很容易理解每条命令是如何接收数据表并对该表执行某些操作的，例如使用WHERE 进行过滤，使用EVAL 添加列，或使用STATS 执行聚合。与从SELECT 开始定义最终输出列不同，可以有一个或多个KEEP 命令，最后一个命令指定最终输出结果。这种结构简化了查询的推理过程。

仔细观察上述示例中的WHERE 命令，我们会发现它与 PostGIS 示例非常相似：

ES|QL

WHERE ST_INTERSECTS( city_boundary, "POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))"::geo_shape )

PostGIS

WHERE ST_INTERSECTS( city_boundary, 'SRID=4326;POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'::geometry )

除了字符串引号字符的不同，最大的区别在于我们如何将字符串类型转换为空间类型。在 PostGIS 中，我们使用::geometry 后缀，而在 ES|QL 中，我们使用::geo_shape 后缀。这是因为 ES|QL 在 Elasticsearch 中运行，而类型转换操作符:: 可用于将字符串转换为ES|QL 支持的任何类型，在本例中就是geo_shape 。此外，Elasticsearch 中的geo_shape 和geo_point 类型意味着空间坐标系为 WGS84，通常使用 SRID 编号 4326。在 PostGIS 中，这一点需要明确，因此在 WKT 字符串中使用了SRID=4326; 前缀。如果删除该前缀，SRID 将被设置为 0，这更像 Elasticsearch 类型cartesian_point 和cartesian_shape ，它们与任何特定坐标系无关。

ES|QL 和 PostGIS 也提供了类型转换函数语法：

ES|QL

WHERE ST_INTERSECTS( city_boundary, TO_GEOSHAPE("POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))") )

PostGIS

WHERE ST_INTERSECTS( city_boundary, ST_SetSRID( ST_GeomFromText('POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'), 4326 ) )

OGC 功能

Elasticsearch 8.14 引入了以下四种 OGC 空间搜索功能：

ES|QL

PostGIS

描述

ST_INTERSECTS

ST_Intersects

如果两个几何图形相交，则返回 true，否则返回 false。

ST_DISJOINT

ST_Disjoint

如果两个几何图形不相交，则返回 true，否则返回 false。ST_INTERSECTS 的倒数。

ST_CONTAINS

ST_Contains

如果一个几何体包含另一个几何体，则返回 true，否则返回 false。

ST_WITHIN

ST_Within

如果一个几何体位于另一个几何体内，则返回 true，否则返回 false。ST_CONTAINS 的倒数。

这些函数的行为与 PostGIS 的对应函数类似，使用方法也相同。例如，如果两个几何图形相交，ST_INTERSECTS 返回 true，否则返回 false。如果您跟踪上表中的文档链接，可能会发现所有 ES|QL 示例都在FROM 子句之后的WHERE 子句中，而所有 PostGIS 示例都使用了字面几何图形。事实上，这两个平台都支持在查询的任何部分使用这些函数。

ST_INTERSECTS 的 PostGIS 文档中的第一个示例是

SELECT ST_Intersects( 'POINT(0 0)'::geometry, 'LINESTRING ( 2 0, 0 2 )'::geometry );

ES|QL 相当于此：

ROW ST_INTERSECTS( "POINT(0 0)"::geo_point, "LINESTRING ( 2 0, 0 2 )"::geo_shape )

请注意我们在 PostGIS 示例中没有指定 SRID。这是因为在 PostGIS 中使用geometry 类型时，所有计算都是在平面坐标系上进行的，因此如果两个几何图形具有相同的 SRID，SRID 是什么并不重要。在 Elasticsearch 中，大多数函数也是如此，但也有例外，geo_shape 和geo_point 使用球形计算，我们将在下一篇关于空间距离搜索的博客中看到这一点。

ES|QL 多功能性

因此，我们已经看到了在WHERE 子句和ROW 命令中使用空间函数的示例。它们还能在哪里发挥作用？EVAL 命令就是一个非常有用的地方。该命令允许您评估表达式并返回结果。例如，让我们确定按国名分组的所有机场的中心点是否都在勾勒出国家的边界内：

FROM airports | EVAL in_uk = ST_INTERSECTS(location, TO_GEOSHAPE("POLYGON((1.2305 60.8449, -1.582 61.6899, -10.7227 58.4017, -7.1191 55.3291, -7.9102 54.2139, -5.4492 54.0078, -5.2734 52.3756, -7.8223 49.6676, -5.0977 49.2678, 0.9668 50.5134, 2.5488 52.1065, 2.6367 54.0078, -0.9668 56.4625, 1.2305 60.8449))")) | EVAL in_iceland = ST_INTERSECTS(location, TO_GEOSHAPE("POLYGON ((-25.4883 65.5312, -23.4668 66.7746, -18.4131 67.4749, -13.0957 66.2669, -12.3926 64.4159, -20.1270 62.7346, -24.7852 63.3718, -25.4883 65.5312))")) | EVAL within_uk = ST_WITHIN(location, TO_GEOSHAPE("POLYGON((1.2305 60.8449, -1.582 61.6899, -10.7227 58.4017, -7.1191 55.3291, -7.9102 54.2139, -5.4492 54.0078, -5.2734 52.3756, -7.8223 49.6676, -5.0977 49.2678, 0.9668 50.5134, 2.5488 52.1065, 2.6367 54.0078, -0.9668 56.4625, 1.2305 60.8449))")) | EVAL within_iceland = ST_WITHIN(location, TO_GEOSHAPE("POLYGON ((-25.4883 65.5312, -23.4668 66.7746, -18.4131 67.4749, -13.0957 66.2669, -12.3926 64.4159, -20.1270 62.7346, -24.7852 63.3718, -25.4883 65.5312))")) | STATS centroid = ST_CENTROID_AGG(location), count=COUNT() BY in_uk, in_iceland, within_uk, within_iceland | SORT count ASC

结果在意料之中，英国机场的中心点在英国边界内，而不在冰岛边界内，反之亦然：

中心点

计数

英国

冰岛

within_uk

冰岛境内

点（-21.94663446396589364.13187285885215)

错误

true

错误

true

点 (-2.597342072712148 54.33551226578214)

true

错误

true

错误

点 (0.04453958108176276 23.74658354606057)

873

错误

事实上，这些函数可用于查询的任何部分，只要其签名是合理的。它们都接收两个参数，参数可以是一个字面空间对象，也可以是一个空间类型的字段，并且都返回一个布尔值。一个重要的考虑因素是，几何图形的坐标参考系（CRS）必须匹配，否则将返回错误信息。这意味着不能在同一个函数调用中混合使用geo_shape 和cartesian_shape 类型。不过，您可以混合使用geo_point 和geo_shape 类型，因为geo_point 类型是geo_shape 类型的特例，两者共享相同的坐标参考系。上文定义的每个函数的文档都列出了支持的类型组合。

此外，任一参数都可以是空间字面量或字段，顺序不限。您甚至可以指定两个字段、两个字面量、一个字段和一个字面量或一个字面量和一个字段。唯一的要求是类型必须兼容。例如，此查询比较同一索引中的两个字段：

该查询基本上是询问城市位置是否在城市边界内，一般来说应该是正确的，但总有例外：

基数

计数

城市

很少

错误

很多

740

true

一个更有趣的问题是，机场所在地是否在机场服务城市的边界之内。不过，机场位置所在的索引与包含城市边界的索引不同。这就需要一种方法来有效查询和关联这两个独立索引中的数据。

空间连接

ES|QL 不支持JOIN 命令，但可以使用ENRICH 命令实现连接的特殊情况，其行为类似于 SQL 中的 "左连接"。该命令的操作类似于 SQL 中的 "左连接"，允许您根据两个数据集之间的空间关系，用另一个索引中的数据来丰富一个索引的结果。

例如，我们可以通过查找包含机场位置的城市边界，用机场服务城市的附加信息来丰富机场表的结果，然后对结果进行一些统计：

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary | MV_EXPAND city_boundary | EVAL boundary_wkt_length = LENGTH(TO_STRING(city_boundary)) | STATS centroid = ST_CENTROID_AGG(location), count = COUNT(city_location), min_wkt = MIN(boundary_wkt_length), max_wkt = MAX(boundary_wkt_length) BY region | SORT count DESC | LIMIT 5

这将返回拥有最多机场的前 5 个区域，以及所有匹配区域机场的中心点和这些区域内城市边界的 WKT 表示长度范围：

中心点

计数

min_wkt

max_wkt

地区

点（-32.5609347096071932.598117914802714)

207

无效

点（-73.9451533276587740.70366442203522)

438

纽约市

点（-83.1039831787347842.300230911932886)

473

底特律

点（-156.302024586126220.176383580081165)

307

803

夏威夷

点（-73.8890273217111845.57078813901171)

837

蒙特利尔

那么，这里到底发生了什么？所谓的JOIN 发生在哪里？问题的关键在于ENRICH 命令：

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary

该命令指示 Elasticsearch 丰富从airports 索引中获取的结果，并在原始索引的city_location 字段和airport_city_boundaries 索引的city_boundary 字段之间执行intersects 连接，我们在前面的几个示例中使用了该连接。但其中一些信息在该查询中并不清晰。我们看到的是丰富策略的名称city_boundaries ，缺失的信息被封装在该策略定义中。

{ "geo_match": { "indices": "airport_city_boundaries", "match_field": "city_boundary", "enrich_fields": ["city", "airport", "region", "city_boundary"] } }

在这里我们可以看到，它将执行geo_match 查询（intersects 是默认值），要匹配的字段是city_boundary ，而enrich_fields 是我们要添加到原始文档中的字段。其中一个字段region 实际上被用作STATS 命令的分组键，如果没有这种 "左连接 "功能，我们是做不到这一点的。有关 enrich 策略的更多信息，请参阅enrich 文档。在阅读这些文档时，你会注意到它们描述了如何通过配置摄取管道，在索引时使用丰富索引来丰富数据。ES|QL 不需要这样做，因为ENRICH 命令在查询时起作用。只需用必要的数据和丰富策略准备丰富索引，然后在 ES|QL 查询中使用ENRICH 命令即可。

您可能还会注意到，最常见的地区是null 。这意味着什么？回想一下，我曾将此命令比作 SQL 中的 "左连接"，也就是说，如果没有为某个机场找到匹配的城市边界，则仍会返回该机场，但airport_city_boundaries 索引中的字段值为null 。结果发现，有 89 个机场没有找到匹配的city_boundary ，有一个机场找到了匹配的region 字段，但该字段是null 。这样就统计出了 90 个机场，结果中没有region 。另一个有趣的细节是MV_EXPAND 命令的必要性。这样做是必要的，因为ENRICH 命令可能会为每个输入行返回多个结果，而MV_EXPAND 则有助于将这些结果分成多行，每个结果一行。这也解释了为什么"Hawaii" 会显示不同的min_wkt 和max_wkt 结果：存在多个名称相同但边界不同的区域。

Kibana 地图

Kibana 在地图应用程序中添加了对空间 ES|QL 的支持。这意味着您现在可以使用 ES|QL 在 Elasticsearch 中搜索地理空间数据，并在地图上将结果可视化。

在添加图层菜单中有一个新的图层选项，名为"ES|QL" 。与迄今为止介绍的所有地理空间功能一样，该功能在"技术预览版" 中。选择该选项可根据 ES|QL 查询结果在地图上添加图层。例如，您可以在地图上添加一个图层，显示世界上所有的机场。

或者您也可以添加一个图层，显示airport_city_boundaries 索引中的多边形，或者更好的办法是使用上面那个复杂的ENRICH 查询，生成每个地区有多少个机场的统计数据？

后续工作计划

你可能已经注意到，在上面的两个例子中，我们又加入了一个空间函数ST_CENTROID_AGG 。这是STATS 命令中使用的聚合函数，也是我们计划添加到 ES|QL 中的众多空间分析功能中的第一个。当我们有更多展示时，我们会在博客上介绍！

在此之前，我们想向您详细介绍我们正在开发的一项特别令人兴奋的功能：执行空间距离搜索的能力，这是 Elasticsearch 最常用的空间搜索功能之一。你能想象距离搜索的语法会是什么样子吗？或许类似于 OGC 功能？敬请关注本系列的下一篇博客，一探究竟！

剧透警告：Elasticsearch 8.15 刚刚发布，其中包含使用 ES|QL 的空间距离搜索！

评估搜索相关性第一部分 —— BEIR 基准测试

Thanos Papaoikonomou,Thomas Veasey — Tue, 16 Jul 2024 00:00:00 GMT

这是系列博客文章的第一篇，探讨如何在更好地理解 BEIR 基准测试的背景下，评估您自己的搜索系统。我们将介绍具体的技巧与方法，帮助您在深入理解 BEIR 的背景下改进搜索评估流程。我们还将指出常见的陷阱，这些陷阱会降低评估的可靠性。最后，我们注意到，LLM 为搜索工程师提供了一种强大的新工具，我们将通过示例展示如何利用它们来协助搜索评估。

理解搜索相关性评估中的 BEIR 基准测试

要改进任何系统，您需要能够衡量其表现。在搜索领域，BEIR（或等效 MTEB 排行榜的检索部分）被认为是信息检索社区的“圣杯”，这并不令人意外。它是一个结构非常完善的基准测试，涵盖了不同任务的多样化数据集。更具体地说，它涵盖了以下领域：

参数检索 (ArguAna, Touche2020)
开放领域问答 (HotpotQA, Natural Questions, FiQA)
段落检索（MSMARCO）
重复问题检索（Quora，CQADupstack）
事实核查（FEVER, Climate-FEVER, Scifact）
生物医学信息检索（TREC-COVID、NFCorpus、BioASQ）
实体检索 (DBPedia)
引文预测 (SCIDOCS)

它提供了一个单一的统计信息 nDCG@10，用于衡量系统在其返回的顶部结果中，为每个任务样例匹配最相关文档的程度。对于人机交互的搜索系统来说，顶部结果的相关性至关重要。然而，评估搜索效果有很多细微差别，而单一的汇总统计数据无法涵盖这些差别。

BEIR 数据集的结构

每个基准测试包含三个组成部分：

要检索的语料库或文档
查询
查询的相关性判断（也称为 qrels）。

相关性判断以零或更高的分数表示。非零分数表示文档与查询有一定的相关性。

数据集

语料库大小

#测试集中的查询数量

#qrels 中正向标注的数量

#qrels 等于零

#语料库中的重复项数量

Arguana

8,674

1,406

Climate-FEVER

5,416,593

1,535

4,681

DBPedia

4,635,922

400

15,286

28,229

FEVER

5,416,568

6,666

7,937

FIQA-2018

57,638

648

1,706

HotpotQA

5,233,329

7,405

14,810

Natural Questions

2,681,468

3,452

4,021

16,781

NFCorpus

3,633

323

12,334

Quora

522,931

10,000

15,675

1,092

SCIDOCS

25,657

1,000

4,928

25,000

Scifact

5,183

300

339

Touche2020

382,545

932

1,982

5,357

TREC-COVID

171,332

24,763

41,663

MSMARCO

8,841,823

6,980

7,437

324

CQADupstack (sum)

457,199

13,145

23,703

表 1：数据集统计信息。这些数字是在数据集的测试部分计算得出的（MSMARCO 的 dev）。

表 1 列出了构成 BEIR 基准的数据集的一些统计数据，如语料库中的文档数量、测试数据集中的查询数量以及 qrels 文件中的正/负（查询、文档）对数量。通过快速查看数据，我们可以立即推断出以下几点：

大多数数据集在 qrels 文件中不包含任何负面关系，即零分，这会明确地将文档标记为与给定查询无关。
每个查询的平均文档关联数（#qrels/#queries）从 ArguAna 的 1.0 到 493.5（TREC-COVID）不等，但大多数情况下的值为 < 5。
一些数据集的语料库中存在重复文档，在某些情况下可能导致评估不准确，例如，当一个文档被认为与查询相关但其重复文档却不相关时。例如，在 ArguAna 中，我们识别出 96 个重复文档对案例，每对中只有一个文档被标记为与查询相关。通过将初始 qrels 列表“扩展”以包含重复文档，我们观察到 nDCG@10 分数平均相对提高了约 1%。

{ "_id": "test-economy-epiasghbf-pro02b", "title": "economic policy international africa society gender house believes feminisation", "text": "Again employment needs to be contextualised with …", "metadata": {} } { "_id": "test-society-epiasghbf-pro02b", "title": "economic policy international africa society gender house believes feminisation", "text": "Again employment needs to be contextualised with …", "metadata": {} }

ArguAna 中的重复对示例。在 qrels 文件中，只有第一个文档显示为与查询（“test-economy-epiasghbf-pro02a”）相关（作为反方论点）

在 MTEB 排行榜上比较模型时，人们很容易将重点放在平均检索质量上。这虽然是模型整体质量的一个良好代理指标，但并不一定能说明它在您特定场景下的表现。由于结果按数据集报告，因此值得了解不同数据集与您的搜索任务的关联程度，并仅使用最相关的数据集重新评估模型。如果您想深入研究，还可以检查各数据语料库的主题重叠情况。按主题对质量指标进行分层，可以更精细地评估模型的具体优势与劣势。

这里需要特别注意，当文档未在 qrels 文件中标注时，默认情况下它被视为与查询不相关。我们对此领域进行了更深入的探究，并收集了一些证据，以更清晰地阐明以下问题：“评估者面对没有真实标注信息的（查询，文档）对的频率有多高？”。这一点之所以重要，是因为当只有浅层标注可用时（即并非每个相关文档都被标记），一个信息检索系统可能仅仅因为它“选择”呈现了不同的相关（但未标记）文档，而被判定为比另一个系统更差。这是创建高质量评估集时的常见陷阱，尤其是对于大型数据集。为了可行，人工标注通常会关注当前系统返回的顶部结果，因此可能会遗漏其盲区中的相关文档。因此，通常更可取的做法是将更多资源集中在少数查询的更完整标注上，而不是广泛的浅层标注。

利用 BEIR 基准测试进行搜索相关性评估

为了启动分析，我们实施了以下场景（见笔记本）：

首先，我们将每个数据集的语料库加载到 Elasticsearch 索引中。
对于测试集中的每个查询，我们使用 BM25 检索前 100 个文档。
我们使用多种 SOTA 重排序模型对检索到的文档进行重新排序。
最后，我们报告第 2 步（检索后）和第 3 步（重新排序后）得出的前 10 名文档的 "评判率"。换句话说，我们计算的是 qrels 文件中得分排名前 10 的文档的平均百分比。

我们使用的模型重新排序列表如下：

Cohere 的 rerank-english-v2.0 和 rerank-english-v3.0
BGE-base
mxbai-rerank-xsmall-v1
MiniLM-L-6-v2

检索

重排序

数据集

BM25（%）

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7.54

4.87

7.87

4.52

4.53

6.84

Climate-FEVER

5.75

6.24

8.15

9.36

7.79

7.58

DBPedia

61.18

60.78

64.15

63.9

63.5

67.62

FEVER

8.89

9.97

10.08

10.19

9.88

FiQa-2018

7.02

11.02

10.77

8.43

9.1

9.44

HotpotQA

12.59

14.5

14.76

15.1

14.02

14.42

Natural Questions

5.94

8.84

8.71

8.37

8.14

8.34

NFCorpus

31.67

32.9

33.91

30.63

32.77

32.45

Quora

12.2

10.46

13.04

11.26

12.58

12.78

SCIDOCS

8.62

9.41

9.71

8.04

8.79

8.52

Scifact

9.07

9.57

9.77

9.3

9.1

9.17

Touche2020

38.78

30.41

32.24

33.06

37.96

33.67

TREC-COVID

92.4

98.4

98.2

93.8

99.6

97.4

MSMARCO

3.97

6.00

6.03

6.07

5.47

6.11

CQADupstack（平均）

5.47

6.32

6.87

5.89

6.22

6.16

表 2：在检索/重新排序的前 10 个文档上计算的（数据集、重排序器）对的评判率

从 表 2 可以看出，除了 TREC-COVID（覆盖率>90%）、DBPedia（~65%）、Touche2020 和 nfcorpus（~35%）之外，大多数数据集在检索或重新排序后的标注率介于 5% 到略高于 10% 之间。这并不意味着所有这些未标注文档都是相关的，但其中可能有一个子集——特别是那些排在靠前位置的——可能是正例。

随着通用指令调优语言模型的出现，我们拥有了一种新的强大工具，它有可能自动化判断相关性。这些方法的计算成本通常太高，不适合在线搜索，但我们这里关注的是离线评估。在下文中，我们将使用它们来探究一些 BEIR 数据集可能存在浅层标注问题的证据。

为了进一步验证这一假设，我们决定专注于 MSMARCO 数据集，选择 100 个查询及其前 5 个经重排序（使用 Cohere v2）且当前未被标记为相关的文档。我们遵循了两种不同的评估路径：首先，我们使用精心调优的提示（后续文章中将详述）引导最近发布的 Phi-3-mini-4k 模型来预测文档与查询的相关性（或不相关性）。与此同时，这些案例也进行了人工标注，以评估 LLM 输出与人工判断之间的一致性率。总体而言，我们可以得出以下两个结论：

LLM 响应与人工标注之间的一致性率接近 80%，作为该方向的起点，这似乎足够好。
在 57.6% 的情况下（基于人工判断），返回的文档被判定为实际上与查询相关。换一种说法：对于 100 个查询，我们有 107 个文档被判定为相关，但至少还有 0.576 × 5 × 100 = 288 个额外文档实际上是相关的！

以下是一些从 MSMARCO/dev 数据集中提取的示例，其中包含查询、注释的正例文档（来自 qrels）一个由于标注不全导致的假负例文档：

示例 1：

{ "query": { "_id": 155234, "text": "do bigger tires affect gas mileage" }, "positive_doc": { "_id": 502713, "text": "Tire Width versus Gas Mileage. Tire width is one of the only tire size factors that can influence gas mileage in a positive way. For example, a narrow tire will have less wind resistance, rolling resistance, and weight; thus increasing gas mileage.", }, "negative_doc": { "_id": 7073658, "text": "Tire Size and Width Influences Gas Mileage. There are two things to consider when thinking about tires and their effect on gas mileage; one is wind resistance, and the other is rolling resistance. When a car is driving at higher speeds, it experiences higher wind resistance; this means lower fuel economy." } }

示例 2：

{ "query": { "_id": 300674, "text": "how many years did william bradford serve as governor of plymouth colony?" }, "positive_doc": { "_id": 7067032, "text": "http://en.wikipedia.org/wiki/William_Bradford_(Plymouth_Colony_governor) William Bradford (c.1590 \u00e2\u0080\u0093 1657) was an English Separatist leader in Leiden, Holland and in Plymouth Colony was a signatory to the Mayflower Compact. He served as Plymouth Colony Governor five times covering about thirty years between 1621 and 1657." }, "negative_doc": { "_id": 2495763, "text": "William Bradford was the governor of Plymouth Colony for 30 years. The colony was founded by people called Puritans. They were some of the first people from England to settle in what is now the United States. Bradford helped make Plymouth the first lasting colony in New England." } }

人工评估此类特定查询，是理解搜索质量的一种普遍有用的技术，它是对 nDCG@10 等定量指标的补充。如果您有一组代表性的查询集，在每次修改搜索时都运行它们，这将为您提供关于性能如何变化的重要定性信息，而这些信息在统计数据中是看不见的。例如，它为您提供了更多关于搜索返回的错误结果的见解：它可以帮助您发现检索结果中的明显错误，相关错误类别，如误解特定领域术语等等。

我们的结果与围绕 MSMARCO 评估的相关研究一致。例如，Arabzadeh 等人遵循类似的流程，他们雇用众包工人进行偏好判断：除其他发现外，他们表明在许多情况下，重新排序模块返回的文档比 MSMARCO qrels 文件中的文档更受青睐。另一项证据来自 RocketQA 重新排序器的作者，他们报告称，经过人工检查，超过 70% 的重排序文档被判定为相关。

更新 - 2023 年 9 月 9 日：在对数据集进行仔细重新评估后，我们识别出另外 15 个相关文档案例，使其总数从 273 个增加到 288 个。

主要要点和后续步骤

对更高质量真实标注的追求永无止境，因为它对于基准测试和模型比较至关重要。如果谨慎使用并配以适当的指令调优，LLM 可以在某些评估领域提供协助
更普遍地说，鉴于基准测试永远不会完美，从单纯的分数比较转向捕捉统计显著性差异的更稳健技术可能更可取。Arabzadeh 等人等人的工作提供了一个很好的例子，他们基于研究结果构建了 95% 置信区间，以表明不同运行之间是否存在显著（或不显著）差异。在随附的笔记本中，我们提供了使用自助法实现置信区间的方法。
从最终用户的角度来看，在阅读基准测试结果时，考虑任务对齐性是有益的。例如，对于构建 RAG 管道的 AI 工程师来说，如果知道最典型的用例涉及从不同来源汇集多条信息，那么在 HotpotQA 等多跳问答数据集上评估其检索模型的性能，会比在整个 BEIR 基准测试的全局平均分更有意义

在下一篇博客文章中，我们将更深入地探讨如何使用 Phi-3 作为 LLM 评判工具，以及调优它以预测相关性的过程。

人工智能剽窃利用 Elasticsearch 检测剽窃行为

Priscilla Parodi — Tue, 19 Dec 2023 00:00:00 GMT

剽窃可以是直接剽窃，即抄袭部分或全部内容；也可以是转述剽窃，即对作者的作品进行改写，改动一些词或短语。

灵感和意译是有区别的。阅读一篇内容，获得启发，然后用自己的语言来探讨这个想法，即使得出的结论相似，也是有可能的。

虽然剽窃一直是讨论的话题，但内容的加速生产和发布使其具有现实意义，并构成了持续的挑战。

这种挑战并不局限于书籍、学术研究或司法文件，在这些领域经常会进行抄袭检查。它还可以延伸到报纸甚至社交媒体。

随着信息的丰富和出版的便捷，如何在可扩展的层面上有效检查抄袭行为？

大学、政府机构和公司使用的工具多种多样，虽然直接的词汇搜索可以有效检测直接抄袭，但主要的挑战在于识别转述的内容。

利用生成式人工智能检测剽窃行为

生成式人工智能带来了新的挑战。人工智能生成的内容在复制时是否被视为抄袭？

例如，OpenAI的使用条款规定，OpenAI 不会对 API 为用户生成的内容主张版权。在这种情况下，使用生成式人工智能的个人可以随意使用生成的内容，而无需引用。

不过，是否接受使用生成式人工智能来提高效率仍是一个讨论话题。

为了对剽窃检测做出贡献，OpenAI 开发了一个检测模型，但后来承认其准确性不够高。

"我们认为，这对于独立检测来说精度还不够高，需要与基于元数据的方法、人工判断和公众教育相结合，才能更加有效。"

然而，随着更多工具的出现，现在有了更多检测抄袭的选择，即使是在转述和人工智能内容的情况下。

使用 Elasticsearch 检测剽窃行为

有鉴于此，在本博客中，我们将利用自然语言处理（NLP）模型和矢量搜索（plagiarism detection）来探索元数据搜索之外的另一个使用案例。

我们利用 SentenceTransformers 提供的数据集（其中包含 NLP 相关文章），通过 Python 示例进行了演示。我们通过 "语义文本相似性 "检查摘要是否抄袭，"语义文本相似性 "考虑的是用之前导入 Elasticsearch 的文本嵌入模型生成的 "摘要 "嵌入。此外，为了识别人工智能生成的内容--人工智能剽窃，还将 OpenAI 开发的NLP 模型导入 Elasticsearch。

下图说明了数据流：

在使用推理处理器的摄取管道中，"抽象 "段落被映射为一个 768 维的向量，即 "abstract_vector.predicted_value"。

绘图：

"abstract_vector.predicted_value": { # Inference results field "type": "dense_vector", "dims": 768, # model embedding_size "index": "true", "similarity": "dot_product" # When indexing vectors for approximate kNN search, you need to specify the similarity function for comparing the vectors.

矢量表示之间的相似性使用矢量相似性度量来衡量，该度量使用 "相似性 "参数来定义。

余弦是默认的相似度量，计算公式为"(1 + cosine(query, vector))/ 2'.除非您需要保留原始矢量，并且无法事先对它们进行归一化处理，否则执行余弦相似性的最有效方法就是将所有矢量归一化为单位长度。这有助于避免在搜索过程中执行额外的矢量长度计算，而应使用 "dot_product"。

在同一管道中，另一个包含文本分类模型的推理处理器会检测内容是可能由人类撰写的 "真实 "内容，还是可能由人工智能撰写的 "虚假 "内容，并将 "openai-detector.predicted_value "添加到每个文档中。

摄取管道：

client.ingest.put_pipeline( id="plagiarism-checker-pipeline", processors = [ { "inference": { #for ml models - to infer against the data that is being ingested in the pipeline "model_id": "roberta-base-openai-detector", #text classification model id "target_field": "openai-detector", # Target field for the inference results "field_map": { #Maps the document field names to the known field names of the model. "abstract": "text_field" # Field matching our configured trained model input. } } }, { "inference": { "model_id": "sentence-transformers__all-mpnet-base-v2", #text embedding model id "target_field": "abstract_vector", # Target field for the inference results "field_map": { "abstract": "text_field" # Field matching our configured trained model input. Typically for NLP models, the field name is text_field. } } } ] )

在查询时，同样的文本嵌入模型也被用于在 "query_vector_builder "对象中生成查询 "model_text "的向量表示。

k-nearest neighbor (kNN) 搜索会根据相似度量找到与查询向量最近的 k 个向量。

每份文档的分数都来自相似度，确保分数越大，排名越靠前。这意味着文件在语义上更加相似。因此，我们打印了三种可能性：如果得分> 0.9，我们认为是 "高度相似"；如果< 0.7，是 "低度相似"，否则是 "中度相似"。您可以根据自己的使用情况，灵活设置不同的阈值，以确定哪种程度的 _score 是否属于抄袭。

此外，还进行了文本分类，以检查文本查询中是否有人工智能生成的元素。

查询：

from elasticsearch import Elasticsearch from elasticsearch.client import MlClient #duplicated text - direct plagiarism test model_text = 'Understanding and reasoning about cooking recipes is a fruitful research direction towards enabling machines to interpret procedural text. In this work, we introduce RecipeQA, a dataset for multimodal comprehension of cooking recipes. It comprises of approximately 20K instructional recipes with multiple modalities such as titles, descriptions and aligned set of images. With over 36K automatically generated question-answer pairs, we design a set of comprehension and reasoning tasks that require joint understanding of images and text, capturing the temporal flow of events and making sense of procedural knowledge. Our preliminary results indicate that RecipeQA will serve as a challenging test bed and an ideal benchmark for evaluating machine comprehension systems. The data and leaderboard are available at http://hucvl.github.io/recipeqa.' response = client.search(index='plagiarism-checker', size=1, knn={ "field": "abstract_vector.predicted_value", "k": 9, "num_candidates": 974, "query_vector_builder": { #The 'all-mpnet-base-v2' model is also employed to generate the vector representation of the query in a 'query_vector_builder' object. "text_embedding": { "model_id": "sentence-transformers__all-mpnet-base-v2", "model_text": model_text } } } ) for hit in response['hits']['hits']: score = hit['_score'] title = hit['_source']['title'] abstract = hit['_source']['abstract'] openai = hit['_source']['openai-detector']['predicted_value'] url = hit['_source']['url'] if score > 0.9: print(f"\nHigh similarity detected! This might be plagiarism.") print(f"\nMost similar document: '{title}'\n\nAbstract: {abstract}\n\nurl: {url}\n\nScore:{score}\n\n") if openai == 'Fake': print("This document may have been created by AI.\n") elif score < 0.7: print(f"\nLow similarity detected. This might not be plagiarism.") if openai == 'Fake': print("This document may have been created by AI.\n") else: print(f"\nModerate similarity detected.") print(f"\nMost similar document: '{title}'\n\nAbstract: {abstract}\n\nurl: {url}\n\nScore:{score}\n\n") if openai == 'Fake': print("This document may have been created by AI.\n") ml_client = MlClient(client) model_id = 'roberta-base-openai-detector' #open ai text classification model document = [ { "text_field": model_text } ] ml_response = ml_client.infer_trained_model(model_id=model_id, docs=document) predicted_value = ml_response['inference_results'][0]['predicted_value'] if predicted_value == 'Fake': print("\nNote: The text query you entered may have been generated by AI.\n")

输出：

High similarity detected! This might be plagiarism. Most similar document: 'RecipeQA: A Challenge Dataset for Multimodal Comprehension of Cooking Recipes' Abstract: Understanding and reasoning about cooking recipes is a fruitful research direction towards enabling machines to interpret procedural text. In this work, we introduce RecipeQA, a dataset for multimodal comprehension of cooking recipes. It comprises of approximately 20K instructional recipes with multiple modalities such as titles, descriptions and aligned set of images. With over 36K automatically generated question-answer pairs, we design a set of comprehension and reasoning tasks that require joint understanding of images and text, capturing the temporal flow of events and making sense of procedural knowledge. Our preliminary results indicate that RecipeQA will serve as a challenging test bed and an ideal benchmark for evaluating machine comprehension systems. The data and leaderboard are available at[ http://hucvl.github.io/recipeqa](http://hucvl.github.io/recipeqa). url:[http://aclweb.org/anthology/D18-1166](http://aclweb.org/anthology/D18-1166) Score:1.0

在本例中，利用数据集中的一个 "摘要 "值作为文本查询 "model_text "后，剽窃行为被识别出来。相似度分数为 1.0，表明相似度很高，即直接抄袭。矢量化查询和文档没有被识别为人工智能生成的内容，这在意料之中。

查询：

#similar text - paraphrase plagiarism test model_text = 'Comprehending and deducing information from culinary instructions represents a promising avenue for research aimed at empowering artificial intelligence to decipher step-by-step text. In this study, we present CuisineInquiry, a database for the multifaceted understanding of cooking guidelines. It encompasses a substantial number of informative recipes featuring various elements such as headings, explanations, and a matched assortment of visuals. Utilizing an extensive set of automatically crafted question-answer pairings, we formulate a series of tasks focusing on understanding and logic that necessitate a combined interpretation of visuals and written content. This involves capturing the sequential progression of events and extracting meaning from procedural expertise. Our initial findings suggest that CuisineInquiry is poised to function as a demanding experimental platform.'

输出：

通过更新文本查询 "model_text"，使用人工智能生成的文本，在传达相同信息的同时尽量减少相似词语的重复，检测到的相似度仍然很高，但得分为 0.9302529，而不是 1.0，这就是转述剽窃。人们还预计，由人工智能生成的这一查询会被检测到。

最后，考虑到文本查询 "model_text "是关于 Elasticsearch 的文本，而不是这些文档的摘要，检测到的相似度为 0.68991005，表明根据所考虑的阈值，相似度较低。

查询：

#different text - not a plagiarism model_text = 'Elasticsearch provides near real-time search and analytics for all types of data.'

输出：

Low similarity detected. This might not be plagiarism.

虽然在人工智能生成的文本查询中，以及在转述和直接复制内容的情况下，都能准确识别出抄袭行为，但在剽窃检测领域中，还需要认识到各个方面的问题。

在人工智能生成的内容检测方面，我们探索了一种模式，这种模式做出了宝贵的贡献。不过，必须认识到独立检测的固有局限性，因此需要结合其他方法来提高准确性。

选择文本嵌入模型带来的可变性是另一个考虑因素。使用不同数据集训练的不同模型会产生不同程度的相似性，这突出了所生成的文本嵌入的重要性。

最后，在这些例子中，我们使用了文件摘要。然而，剽窃检测通常涉及大量文件，因此必须解决文本长度的难题。文本通常会超过模型的标记限制，这就要求在建立嵌入之前将文本分割成块。处理这种情况的实用方法是使用 dense_vector 嵌套结构。

结论

在这篇博客中，我们讨论了检测抄袭（尤其是在转述和人工智能生成的内容中）所面临的挑战，以及如何利用语义文本相似性和文本分类来实现这一目的。

结合这些方法，我们提供了一个剽窃检测实例，成功识别了人工智能生成的内容、直接剽窃和转述剽窃。

我们的主要目标是建立一个过滤系统，简化检测工作，但人工评估对于验证工作仍然至关重要。

如果您有兴趣了解更多有关语义文本相似性和 NLP 的信息，我们建议您同时查看以下链接：

使用 Elasticsearch 进行词法和语义搜索

Priscilla Parodi — Tue, 03 Oct 2023 00:00:00 GMT

搜索是根据您的搜索查询或组合查询查找最相关信息的过程，相关搜索结果是与这些查询最匹配的文档。尽管与搜索相关的挑战和方法有多种，但最终目标始终不变，即尽可能找到问题的最佳答案。

考虑到这一目标，在本篇博文中，我们将探讨使用 Elasticsearch 检索信息的不同方法，重点关注文本搜索：词法搜索和语义搜索。

准备工作

为此，我们将提供 Python 示例，演示在模拟电子商务产品信息生成的数据集上进行搜索的各种情况。

该数据集包含 2,500 多种产品，每种产品都有说明。这些产品分为 76 个不同的产品类别，每个类别包含的产品数量各不相同，如下所示：

树状地图可视化 - category.keyword 的前 22 个值（产品类别）

安装时您需要

Python 3.6 或更高版本
弹性 Python 客户端
Elastic 8.8 或更高版本，配备 8GB 内存的机器学习节点
Elastic Learned Sparse EncodeR模型已预装到 Elastic 中，并已在部署中启动

我们将使用 Elastic Cloud，可免费试用。

除了本博文提供的搜索查询外，Python 笔记本还能指导您完成以下过程：

使用 Python 客户端与我们的弹性部署建立连接
将文本嵌入模型载入 Elasticsearch 集群
创建一个索引，其中包含用于索引特征向量和密集向量的映射。
创建带推理处理器的摄取管道，用于文本嵌入和文本扩展

词汇检索--稀疏检索

Elasticsearch 根据文本查询对文档进行相关性排序的经典方法是使用BM25模型的 Lucene 实现，这是一种用于词法搜索的稀疏模型。这种方法沿用了传统的文本搜索方法，即寻找完全匹配的术语。

为了实现这种搜索，Elasticsearch 通过执行文本分析将文本字段数据转换为可搜索格式。

文本分析 由分析器执行，分析器是一套规则，用于管理提取相关词组以供搜索的过程。一个分析器必须有一个标记符。标记化器接收字符流，并将其分解为单个标记（通常是单个单词），就像下面的例子一样：

用于词法搜索的字符串标记化

#Performs text analysis on a string and returns the resulting tokens. # Define the text to be analyzed text = "Comfortable furniture for a large balcony" # Define the analyze request request_body = { "analyzer": "standard", "text": text } # Perform the analyze request response = client.indices.analyze(analyzer=request_body["analyzer"], text=request_body["text"]) # Extract and display the analyzed tokens tokens = [token["token"] for token in response["tokens"]] print("Analyzed Tokens:", tokens)

输出

Analyzed Tokens: ['comfortable', 'furniture', 'for', 'a', 'large', 'balcony']

在本例中，我们使用的是默认分析器--标准分析器，它能提供基于英语语法的标记化，因此能很好地满足大多数使用要求。标记化可实现单个术语的匹配，但每个标记仍按字面进行匹配。

如果您想个性化搜索体验，可以选择不同的内置分析器。例如，通过更新代码以使用停顿分析器，就能在任何非字母字符处将文本分解为词块，并支持删除停顿词。

... # Define the analyze request request_body = { "analyzer": "stop", "text": text } ...

输出

Analyzed Tokens: ['comfortable', 'furniture', 'large', 'balcony']

当内置分析器无法满足您的需求时，您可以创建一个自定义分析器，该分析器使用零个或多个字符过滤器、一个标记器和零个或多个标记过滤器的适当组合。

"analyzer": { "my_analyzer": { "type": "custom", #For custom analyzers, use a type of custom or omit the type parameter. "tokenizer": "standard", #Built-in or customized tokenizer "filter": ["lowercase", "synonym"] #Built-in or customized token filters } }

在上述结合了标记符号化器和标记符号过滤器的示例中，文本将先由小写过滤器进行小写处理，然后再由同义词标记符号过滤器进行处理。

词汇匹配

BM25将根据术语的频率及其重要性来衡量文档与给定搜索查询的相关性。

下面的代码执行匹配查询，搜索最多两个文档，考虑到 "ecommerce-search " 索引中的 "描述" 字段值和搜索查询 " 大阳台的舒适家具 ".

改进文档的匹配标准可以提高查询的精确度。然而，更具体的结果是以较低的差异容忍度为代价的。

# BM25 response = client.search(size=2, index="ecommerce-search", query= { "match": { "description" : { "query": "Comfortable furniture for a large balcony", "analyzer": "stop" } } } ) hits = response['hits']['hits'] if not hits: print("No matches found") else: for hit in hits: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

输出

Score: 15.607948 Product: Barbie Dreamhouse Category: Toys Description: is a classic Barbie playset with multiple rooms, furniture, a large balcony, a pool, and accessories. It allows kids to create their dream Barbie world. Score: 9.137739 Product: Comfortable Rocking Chair Category: Indoor Furniture Description: enjoy relaxing moments with this comfortable rocking chair. Its smooth motion and cushioned seat make it an ideal piece of furniture for unwinding.

通过分析输出结果，最相关的结果是"芭比娃娃梦幻屋" 产品，属于"玩具" 类别，其描述高度相关，因为其中包括术语"家具" 、"大型"和"阳台" ，这是唯一一个在描述中有 3 个术语符合搜索查询的产品，该产品也是唯一一个在描述中有术语"阳台"的产品。

排名第二的产品是"舒适摇椅" ，归类为"室内家具" ，其描述包括"舒适" 和"家具" 等术语。数据集中只有 3 种产品至少与该搜索查询的 2 个词匹配，该产品就是其中之一。

"Comfortable"出现在 105 个产品的描述中，"furniture"出现在 4 个产品的描述中，有 4 个不同的类别：玩具、室内家具、室外家具和 "猫狗用品& 玩具"。

正如您所看到的，考虑到该查询，最相关的产品是玩具，第二相关的产品是室内家具。如果你想了解分数计算的详细信息，知道为什么这些文档是匹配的，可以将explain__query 参数设置为 true。

尽管这两个结果都是最相关的结果，但考虑到该数据集中的文档数量和术语出现率，查询"大型阳台的舒适家具" 背后的意图是搜索实际大型阳台的家具，不包括玩具和室内家具。

词法搜索相对简单快捷，但也有局限性，因为在不了解用户意图和查询的情况下，不可能总是知道所有可能的术语和同义词。自然语言使用中的一个常见现象是词汇不匹配。研究表明，不同的人（同一领域的专家）对同一事物的命名平均有80% 不同。

这些局限性促使我们寻找其他包含语义知识的评分模型。基于变换器的模型擅长处理像自然语言这样的连续输入标记，它通过考虑文档和查询的数学表示来捕捉搜索的基本含义。这样就能对文本进行密集的、上下文感知的矢量表示，为语义搜索提供动力，这是一种查找相关内容的精细方法。

语义搜索 - 密集检索

在这种情况下，将数据转换成有意义的向量值后，利用k-nearest neighbor（kNN）搜索算法在数据集中找到与查询向量最相似的向量表示。Elasticsearch 支持两种 kNN 搜索方法，即精确暴力 kNN和近似 kNN（也称为 ANN）。

粗暴的 kNN 可以保证准确的结果，但在处理大型数据集时并不能很好地扩展。近似 kNN 通过牺牲一些精度来提高性能，从而有效地找到近似近邻。

借助 Lucene 对 kNN 搜索和密集矢量索引的支持，Elasticsearch 利用了分层导航小世界 (HNSW) 算法，该算法在各种ann-benchmark 数据集上都表现出了强大的搜索性能。可以使用下面的示例代码在 Python 中执行近似 kNN 搜索。

使用近似 kNN 进行语义搜索

# KNN - approximate kNN response = client.search(index='ecommerce-search', size=2, knn={ "field": "description_vector.predicted_value", "k": 50, # Number of nearest neighbors to return as top hits. #The optimal value of k is dependent on the data. It can vary in different scenarios. "num_candidates": 500, # Number of nearest neighbor candidates to consider per shard. #Increasing num_candidates tends to improve the accuracy of the final k results. "query_vector_builder": { # Object indicating how to build a query_vector. kNN search enables you to perform semantic search by using a previously deployed text embedding model, the steps for this process are demonstrated in the Python notebook. "text_embedding": { "model_id": "sentence-transformers__all-mpnet-base-v2", # Text embedding model id "model_text": "Comfortable furniture for a large balcony" # Query } } } ) for hit in response['hits']['hits']: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

考虑到产品数据集中 " 描述"字段的嵌入情况，该代码块使用 Elasticsearch 的 kNN 返回最多两个描述与"Comfortable furniture for a large balcony " 的矢量化查询 (query_vector_build) 相似的产品。

产品嵌入之前是在摄取管道中生成的，摄取管道中的推理处理器包含 "all-mpnet-base-v2"文本嵌入模型的推理处理器，根据管道中正在摄取的数据进行推理。

选择该模型的依据是使用 "句子转换器评估"在训练过程中，使用不同的类别来评估模型。"all-mpnet-base-v2" 模型在Sentence-Transformers排行榜上显示出最佳平均性能，并在大规模文本嵌入基准 (MTEB)排行榜上占据有利位置。该模型预先训练了微软/mpnet-base模型，并在 1B 句子对数据集上进行了微调，将句子映射到 768 维的密集向量空间。

此外，还有许多其他模型可以使用，特别是那些针对特定领域数据进行微调的模型。

输出

Score: 0.79207325 Product: Patio Sofa Set with Ottoman Category: Outdoor Furniture Description: is a versatile and comfortable patio sofa set, including a sofa, ottoman, and coffee table, great for outdoor lounging. Score: 0.7836937 Product: Patio Sofa Set with Canopy Category: Outdoor Furniture Description: is a luxurious and comfortable patio sofa set with a canopy, providing shade and style for outdoor lounging.

根据所选模型、 过滤器 和 近似 kNN 调整，输出结果可能会有所不同。

kNN 搜索结果都属于"Outdoor Furniture" 类别，尽管"outdoor" 这个词并没有作为查询的一部分被明确提及，这凸显了语义理解在上下文中的重要性。

密集矢量搜索有几个优点：

启用语义搜索
处理超大数据集的可扩展性
灵活处理各种数据类型

不过，密集矢量搜索也有其自身的挑战：

为您的使用案例选择合适的嵌入模式
选定模型后，可能需要对模型进行微调，以优化特定领域数据集的性能，这一过程需要领域专家的参与
此外，索引高维向量的计算成本很高

语义搜索--学习型稀疏检索

让我们来探索另一种方法：学习稀疏检索，这是执行语义搜索的另一种方式。

作为一种稀疏模型，它利用 Elasticsearch 基于 Lucene 的倒排索引，该索引得益于数十年的优化。不过，这种方法不仅仅是用 BM25 等词汇评分功能添加同义词那么简单。相反，它利用更深层次的语言知识将学习到的联想融入其中，以优化相关性。

通过扩展搜索查询以包含原始查询中不存在的相关术语，Elastic Learned Sparse Encoder可以改进稀疏向量嵌入，如下例所示。

利用弹性学习稀疏编码器进行稀疏向量搜索

# Elastic Learned Sparse Encoder response = client.search(index='ecommerce-search', size=2, query={ "text_expansion": { "ml.tokens": { "model_id":"elser_model", "model_text":"Comfortable furniture for a large balcony" } } } ) for hit in response['hits']['hits']: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

输出

Score: 14.405318 Product: Garden Lounge Set with Side Table Category: Garden Furniture Description: is a comfortable and stylish garden lounge set, including a sofa, chairs, and a side table for outdoor relaxation. Score: 14.281318 Product: Rattan Patio Conversation Set Category: Outdoor Furniture Description: is a stylish and comfortable outdoor furniture set, including a sofa, two chairs, and a coffee table, all made of durable rattan material.

本例中的结果包括"Garden Furniture" 类别，该类别提供的产品与"Outdoor Furniture" 非常相似。

通过分析"ml.tokens" 、"rank_features" 字段，其中包含学习稀疏检索生成的标记，可以明显看出，在生成的各种标记中，有一些术语虽然不是搜索查询的一部分，但其含义仍然相关，如"relax" （舒适）、"sofa" （家具）和"outdoor" （阳台）。

下面的图片突出显示了查询中的一些术语，包括术语扩展和未扩展术语。

正如观察到的那样，该模型提供了一种上下文感知搜索，有助于缓解词汇不匹配问题，同时提供更多可解释的结果。在不进行特定领域再训练的情况下，它甚至可以超越密集向量模型。

混合搜索：结合词法和语义搜索获得相关结果

在搜索方面，没有放之四海而皆准的解决方案。这些检索方法各有所长，但也面临挑战。根据不同的使用情况，最佳选择可能会有所变化。通常情况下，不同检索方法的最佳结果是互补的。因此，为了提高相关性，我们要把每种方法的优势结合起来。

实现混合搜索的方法有多种，包括线性组合、给每个得分加权和互惠等级融合（RRF），其中互惠等级融合无需指定权重。

Elasticsearch：词法和语义搜索的两全之策

# BM25 + Elastic Learned Sparse Encoder (Linear Combination) response = client.search(index='ecommerce-search', size=2, query= { "bool": { "should": [ { "match": { "description" : { "query": "A dining table and comfortable chairs for a large balcony", "boost": 1 } } }, { "text_expansion": { "ml.tokens": { "model_id": "elser_model", "model_text": "A dining table and comfortable chairs for a large balcony", "boost": 1 } } } ] } } ) # The boost value is 1 for the text expansion and match query. This means that the relevance score of the results of these queries are not boosted. You can specify a boost value to give a weight to each score in the sum. The scores will be calculated as: score = boost value * match_score + boost value * text_expansion_score for hit in response['hits']['hits']: score = hit['_score'] product = hit['_source']['product'] category = hit['_source']['category'] description = hit['_source']['description'] print(f"\nScore: {score}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

在这段代码中，我们使用两个查询值为"大阳台的餐桌和舒适的椅子" 进行了混合搜索。我们没有使用"家具" 作为搜索词，而是指定了我们要查找的内容，并且两个搜索都考虑了相同的字段值，即"描述" 。排名由 BM25 和 ELSER 分数等权重的线性组合确定。

输出

Score: 31.628141 Product: Garden Dining Set with Swivel Rockers Category: Garden Furniture Description: is a functional and comfortable garden dining set, including a table and chairs with swivel rockers for easy movement. Score: 31.334227 Product: Garden Dining Set with Swivel Chairs Category: Garden Furniture Description: is a functional and comfortable garden dining set, including a table and chairs with swivel seats for convenience.

在下面的代码中，我们将对查询使用相同的值，但会使用对等排名融合方法合并 BM25（查询参数）和 kNN（knn 参数）的得分，对文档进行合并和排名。

# BM25 + KNN (RRF) response = client.search(index='ecommerce-search', size=2, query={ "bool": { "should": [ { "match": { "description": { "query": "A dining table and comfortable chairs for a large balcony" } } } ] } }, knn={ "field": "description_vector.predicted_value", "k": 50, "num_candidates": 500, "query_vector_builder": { "text_embedding": { "model_id": "sentence-transformers__all-mpnet-base-v2", "model_text": "A dining table and comfortable chairs for a large balcony" } } }, rank={ "rrf": { # Reciprocal rank fusion "window_size": 50, # This value determines the size of the individual result sets per query. "rank_constant": 20 # This value determines how much influence documents in individual result sets per query have over the final ranked result set. } } ) for hit in response['hits']['hits']: rank = hit['_rank'] category = hit['_source']['category'] product = hit['_source']['product'] description = hit['_source']['description'] print(f"\nRank: {rank}\nProduct: {product}\nCategory: {category}\nDescription: {description}\n")

RRF 功能处于技术预览阶段。在全球大会之前，语法可能会有所改变。

输出

Rank: 1 Product: Patio Dining Set with Bench Category: Outdoor Furniture Description: is a spacious and functional patio dining set, including a dining table, chairs, and a bench for additional seating. Rank: 2 Product: Garden Dining Set with Swivel Chairs Category: Garden Furniture Description: is a functional and comfortable garden dining set, including a table and chairs with swivel seats for convenience.

在这里，我们还可以使用不同的字段和值，Python 笔记本中提供了其中一些示例。

正如您所看到的，有了 Elasticsearch，您就可以两全其美：传统的词法搜索和矢量搜索（无论是稀疏搜索还是密集搜索），以实现您的目标并找到问题的最佳答案。

如果您想继续了解这里提到的方法，这些博客会很有用：

Elasticsearch 提供了矢量数据库以及构建矢量搜索所需的所有工具：

Elasticsearch矢量数据库
使用 Elastic 的矢量搜索用例

结论

在这篇博文中，我们探讨了使用 Elasticsearch 检索信息的各种方法，尤其侧重于文本、词法和语义搜索。为了证明这一点，我们提供了 Python 示例，使用包含电子商务产品信息的数据集展示了不同的搜索场景。

我们回顾了 BM25 的经典词汇搜索，并讨论了其优势和挑战，如词汇不匹配。我们强调了结合语义知识来克服这一问题的重要性。此外，我们还讨论了实现语义搜索的密集矢量搜索，并介绍了与这种检索方法相关的挑战，包括索引高维矢量时的计算成本。

另一方面，我们提到稀疏向量的压缩效果特别好。因此，我们讨论了 Elastic 的 "学习稀疏编码器"（Learned Sparse Encoder），该编码器可扩展搜索查询，以包含原始查询中不存在的相关术语。

在搜索方面，没有放之四海而皆准的解决方案。每种检索方法都有其优势和挑战。因此，我们还讨论了混合搜索的概念。

正如您所看到的，有了 Elasticsearch，您就可以同时拥有传统词法搜索和矢量搜索这两种搜索方式的优点！