IT瘾搜索推荐

网罗天下：超全特殊搜索引擎合集，开启探索新视界！ - 资源 - 虫部落

Fri, 09 May 2025 14:30:23 CST

在信息爆炸的时代，精准高效地获取所需资源是关键。今天，就给大家带来一份超全的特殊搜索引擎合集，涵盖网盘、图片、音乐、文献、动漫等海量类型，保准让你大呼过瘾，赶紧码住！
以下内容由知客驿站进行整理分享，更多资源尽在知客驿站： https://www.zkcee.com/
📁 网盘资源搜索类
PanSearch ：网盘资源搜索的利器，能帮你快速定位各类网盘里的宝藏资料，网址是 https://www.pansearch.me。
小云搜索：阿里云盘、夸克网盘、蓝奏云的资源都能搜，堪称网盘搜索神器，访问 https://www.yunso.net/即可体验。
千帆搜索：专注于电报（Telegram）中文资源的搜索引擎，资源超丰富，地址为 https://tg.qianfan.app/。
猫狸盘搜：阿里云盘的搜索神器，能精准找到阿里云盘里的各类文件， https://alipansou.com/是它的官网。
易搜：支持百度、阿里、夸克网盘的搜索引擎，功能强大，网址： https://yiso.fun/。
SOSO 云盘搜索导航：除了能搜索百度网盘、阿里云网盘，还能查询网盘链接提取码或密码，实用又便捷，地址： https://www.sosoyunpan.com/。
小白盘：专注于网盘搜索，简单好用，网址： https://www.xiaobaipan.com/。
茶杯狐：当你片荒剧荒时，来这里搜搜看，说不定就能找到想看的影视资源， https://cupfox.love/是它的入口。
学霸盘：百度网盘学习资料的搜索下载神器，对于学生党来说非常实用，官网是 https://www.xuebapan.com/。
小不点搜索：名副其实的正版资源搜索引擎，能一网打尽各类优质资源，地址： https://www.xiaoso.net/。
咕咕云搜索：专为百度云、百度网盘打造的搜索引擎，帮你快速找到云端的文件， https://www.h2ero.com/可访问。
奈斯搜索：阿里云盘资源搜索网站，资源丰富多样，网址： https://www.niceso.net/。
搜 BaiDu 盘：顾名思义，是百度云搜索、百度云盘资源下载的导航类搜索引擎， https://www.sobaidupan.com/是其链接。
凌风云：汇聚了十大网盘搜索引擎，一站式满足你的网盘搜索需求，访问 https://www.lingfengyun.com/查看。
UP 云搜：最全的阿里云盘资源搜索神器，阿里云盘用户必收藏，官网是 https://www.upyunso.com/。
兄弟盘：能搜索云盘资源，说不定能找到一些小众但实用的资料， https://xiongdipan.com/是它的地址。
搜搜：百度网盘文档的搜索引擎，对于找特定文档很有帮助，网址： https://www.xssousou.com/。
热盘搜：百度云搜索、网盘搜索的不错选择，能找到不少百度云上的热门资源， http://www.repanso.com/可访问。
超能搜：百度网盘搜索神器，助力你快速定位百度网盘里的文件， https://www.chaonengsou.com/是链接。
奇乐搜：阿里云盘、夸克网盘的综合搜索网站，一个站点满足两种网盘的搜索需求， https://www.qileso.com/是官网。
哎呦喂啊：搜歌曲和影视是它的特色，说不定能帮你找到心仪的影视作品或动听歌曲， https://www.aiyoweia.com/可体验。
短剧搜索大全：专门的短剧搜索平台，追短剧的小伙伴有福了，地址是 https://www.kdocs.cn/l/cp1MFwlimAAm?R=L1MvMQ==。
羚羊资源聚合搜索引擎：短剧、音乐、软件、PPT 等资源都能搜，是资源搜索的不二之选， https://files.ptger.cn/是入口。
网盘之家：收录了 43 个网盘搜索引擎，简直是网盘搜索的宝库， https://www.wowenda.com/可查看。
搜夸克：网盘搜索与网盘内容分类导航相结合，方便又实用， https://www.soquark.top/是网址。
自由图书：超全面的电子书导航网站，爱读书的你不容错过， https://www.book5678.com/是链接。
次元方舟动漫网：动漫爱好者的天堂，能搜索各类动漫资源， https://www.cyfz.vip/是官网。
Animoe 动漫：不仅能直接搜索动漫，还有追剧周表导航，方便追番， https://animoe.org/可访问。
狗番——高清番剧导航：搜索、追剧导航于一体，可在线直接看动漫， https://www.dogsfun.fun/是地址。
樱之空动漫：动漫在线播放网站，想看动漫即点即播， https://www.skr2.cc/是链接。
AGE 动漫：各种动漫导航，能在线观看， https://www.agedm.org/是入口。
数据搜索：专搜影视，是影视爱好者的最爱， http://m.9dups.com/app/index.html?id=test可体验。
数据搜索：同样是影视搜索、网盘搜索的好帮手， http://b.kkkob.com/apps/index.html?id=test, http://b.kkkob.com/apps/index.html?id=2是其网址。
PanSearch ：前面已介绍，是网盘资源搜索 | 网盘搜索引擎，网址： https://www.pansearch.me。
小云搜索：阿里云盘夸克网盘搜索神器，蓝奏云搜索也不在话下， https://www.yunso.net/可访问。
千帆搜索：资源超丰富的电报中文搜索引擎， https://tg.qianfan.app/是其链接。
猫狸盘搜：阿里云盘搜索神器， https://alipansou.com/可快速找到阿里云盘资源。
易搜：强大的网盘搜索引擎，支持百度、阿里、夸克网盘， https://yiso.fun/是地址。
SOSO 云盘搜索导航：百度网盘搜索、阿里云网盘搜索导航，还能查询网盘链接提取码或密码，网址： https://www.sosoyunpan.com/。
小白盘：网盘搜索的简洁实用之选， https://www.xiaobaipan.com/可查看。
📸 图片搜索类

以下内容由知客驿站进行整理分享，更多资源尽在知客驿站： https://www.zkcee.com/

imageSearch ：以图搜图聚合站，当你看到一张图片想查找相关信息或相似图时，它就能派上用场， https://picfind.top/是官网。
HQ ICON ：从 App Store 快速获取高清应用图标的平台，对于设计、开发人员来说很有用， https://icon.yukonga.top/可访问。
Vave BG ：AI 壁纸，能按照生成图片的关键词进行搜索，轻松找到心仪的壁纸， https://vavebg.com/是入口。
堆糖：高清图片、美图壁纸兴趣社区，搜剧照也是一绝，网址： https://www.duitang.com/。
视觉中国：全球领先的视觉素材数字版权库和交易平台，海量正版图片资源等你来， http://www.vcg.com/是官网。
标下智：一键搜索多家免版权图库，再也不用担心商用图片侵权， https://www.logosc.cn/so/可体验。
PPBC 中国植物图像库：最大的植物分类图片库，植物爱好者、研究人员的福音， https://ppbc.iplant.cn/是链接。
Public domain vectors ：免费可商用矢量素材站点，提供 7 万张矢量图像，支持 svg、eps 等格式， https://publicdomainvectors.org/可查看。
SVG Repo ：拥有 500.000 + 开放许可的 SVG 矢量和图标，素材丰富多样， https://www.svgrepo.com/是地址。
Icônes ：超级多的免费图标，且按照类别分好，支持多种格式免费下载， https://icon.ittools.cc/可访问。
🎵 音乐歌曲搜索类
SPlayer ：可在线播放的音乐搜索引擎，歌曲资源很全， https://splayer.uncley.cc/是网址。
QQ 音速网：能在线播放的音乐搜索引擎，免登录、免费直接听， https://www.qqyin.com/可体验。
Wandhi ：多站合一音乐搜索，支持音乐在线试听、下载， https://music.wandhi.com/是入口。
音乐魔石：全网无损音乐 mp3 歌曲免费下载网站，音质控的最爱， https://yym4.com/可访问。
搜狗表情包：虽然叫表情包搜索，但音乐搜索也有一手， https://pic.sogou.com/pic/emo/index.jsp可查看。
FREEMP3 ：输入歌曲名称就能立即下载，方便快捷， https://g2.freemp3cloud.com/是链接。
Musopen ：收集了 100,000 个古典乐谱 pdf 文件，这些乐谱免费且在公共领域，可浏览乐谱， https://musopen.org/是官网。
Mutopia ：提供 2000 多个免费下载 pdf 格式的乐谱， http://www.mutopiaproject.org/可下载。
IMSLP ：国际乐谱库，是目前最大的免费乐谱下载网站，找古典音乐谱子很合适， https://imslp.org/是地址。
环球钢琴网：提供 4 万余份钢琴谱，免费下载，还可在线播放钢琴曲、观看钢琴演奏视频， https://www.hqgq.com/是入口。
📚 文献与学习资源搜索类
好学电子课本网：主要是人教版，从小学到高中的各个年级、各个学科的电子课本、试卷都能搜， http://m.5haoxue.net/是网址。
中国高校课件下载中心：综合性的教育资源交流平台，课件资源丰富， http://download.cucdc.com/可访问。
学术资源搜索：谷歌学术资源搜索，帮助你快速定位各类学术文献， https://scholar.lanfanshu.cn/是链接。
MedReading ：读 SCI 文献，发高分文章查找文献和期刊最新影响因子，支持中英文， https://www.medreading.cn/pubmed_zh可体验。
国家哲学社会科学文献中心：中国科技论文在线，科技期刊搜索、科技论文搜索，是国内唯一的免费全文期刊库， https://www.paper.edu.cn/journal/index.shtml是官网。
查文献神器：名副其实的查文献神器， http://www.4243.net/可助你高效查找文献。
学子备战墙：有各种初高中、考研、考公的课程视频，学习资料等，无需注册登录都能免费下载， https://www.xzbzq.com/是地址。
数字素养网：全国中小学教师教育网址导航，是搜索教育资源的汇总网站，对于中小学教师教学资源或者家长辅导孩子很有帮助， https://szsyw.cn/jiaoshi可查看。
开源精选：专注于收录优质开源工具的导航网站，收集完全免费且超好用的开源软件，直接提供网盘下载地址， https://www.ossnav.com/是入口。
中国高校外语慕课平台：汇聚各大高校优质外语课程，学外语的好帮手， https://moocs.unipus.cn/可访问。
🤖 AI 搜索引擎类

以下内容由知客驿站进行整理分享，更多资源尽在知客驿站： https://www.zkcee.com/

知乎直答：知乎出的 AI 搜索关键词引擎， https://zhida.zhihu.com/可体验。
天工 AI 搜索更多信息搜索：搜、对话、写作、文档分析、画画、做 PPT 的全能 AI 助手， https://search.tiangong.cn/是网址。
360AI 搜索具有搜索：综合性的 AI 搜索引擎， https://www.sou.com/可查看。
秘塔 AI 搜索引擎：右下角有个 “生成演示文稿”，可直接把答案变成 PPT， https://metaso.cn/是链接。
Kimi ：帮你看更大的世界， https://kimi.moonshot.cn/可访问。
Globe Explorer ：网上搜索结果自动总结，还带大纲， https://explorer.globe.engineer/是地址。
Lepton Search ：开源 AI 搜索引擎， https://search.lepton.run/可体验。
AI 万花筒：专注收录各种 AI 工具的导航网站，目前收录了 1200 + AI 工具， https://www.aiwht.com/是官网。
映技派：同样专注收录各种 AI 工具的导航网站， https://www.yjpoo.com/可查看。
MikuTools ：轻量的工具集合，有原神配音等有趣功能， https://tools.miku.ac/可访问。
IT Tools ：在线 IT 工具集合，涵盖加密、转换器、Web、图片和视频、开发、网络、数学、测量、文本和数据等类型， https://zz.ittools.cc/是链接。
doyoudo ：有视频剪辑、特效合成、动画制作、音乐特效等后期制作的教程网站，还有资源导航， https://www.doyoudo.com/free可体验。
帮小忙：腾讯 QQ 浏览器在线工具箱平台， https://tool.browser.qq.com/是地址。
蜻蜓工具：好用免费的在线工具站， https://33tool.com/是网址。
美图设计室：可按模板名称和功能搜索，智能生成海报， https://www.designkit.com/是链接。
AI 法条查询：输入关键词，快速找到相关案例和法律法规，并对其关键词进行分析， https://meta.law/可体验。
法行宝：免费 AI 律师， https://cnkgraph.com/Book是地址。
聪豹・时间线：输入历史人物，以时间线形式呈现人物生平、事件脉络， https://www.wiseal.cn/是官网。
Perplexity ：AI 搜索引擎，还新增电商功能 Perplexity， https://www.perplexity.ai/可访问。
魔搭社区：AI 大模型搜索空间搜索， https://modelscope.cn/是入口。
纳米搜索在线版：AI 搜索引擎，但搜索结果却可以播客和视频的形式呈现，创作者神器， https://n.cn/可查看。
纳米搜索 APP 版：同纳米搜索在线版，搜索结果以播客和视频呈现， https://pan.quark.cn/s/5758681e5de5是下载链接。
AIGC 吧：AI 工具集合官网导航，国内外 AI 工具集导航大全， https://aigcba.com/可体验。
🧲 磁力搜索类
池里搜：磁力搜索，能寻找到书籍、影视等资源， https://chilisou15.xyz/可访问。
磁力酷：磁力搜索专家， https://ciliku.net/是官网。
黑马磁力：资源多，人人爱上的磁力搜索引擎， https://heimaai.top可体验。
小草磁力：专注于高清电影、电视剧、软件和番号磁力链接搜索的引擎， https://xccl85.xyz/是地址。
天堂磁力：资源丰富的磁力搜索， https://tt2.ttcl.cc/可查看。
磁力星球：在线磁力搜索引擎， https://so3.xingqiu.icu/是入口。
虫部落、快搜：学术搜索，数据搜索，图片检索，磁力搜索，电子书检索、开原文献、国家标准等一应俱全， https://search.chongbuluo.com/可访问。
🌐 综合搜索引擎类

以下内容由知客驿站进行整理分享，更多资源尽在知客驿站： https://www.zkcee.com/

百度：国内知名的综合搜索引擎，搜问题还会自动生成一个 AI 答案，并且可以语音播放， https://www.baidu.com/是网址。
Yandex ：俄罗斯最大的搜索引擎， https://yandex.com/可访问。
必应：内置 AI 功能的综合搜索引擎， https://cn.bing.com/是官网。
MemFree ：混合 AI 搜索引擎， https://www.memfree.me/zh可体验。
Google ：谷歌搜索的镜像， https://so.niostack.com/可访问。
非凡搜索：F 搜的镜像， https://ffsou.com/是网址。
🎁 其他特色资源搜索类
古腾堡工程：大约有 7 万多本书籍可供免费下载，是电子书爱好者的福地， https://www.gutenberg.org/是链接。
新电影导航：提供各种电影、漫画、动漫类的网站， https://www.xdy.me/可查看。
电影剧本：互联网上最大的电影剧本资源网站， https://imsdb.com可访问。
短剧狗：专门搜索短剧的搜索引擎， https://duanjugou.top/是官网。
SoAli.net ：电影、电子书、网剧、音乐搜索， https://soali.net/是链接。
天下老照片网：开放专业的历史老照片图库， http://www.laozhaopian5.com/可访问。
影印古籍搜索：支持诗词检索，甚至曲谱， https://sou-yun.cn/QueryPoem.aspx可体验。
英语台词社：54000 电影，110000 集美剧完整台词， https://www.taicishe.com/是网址。
数字素养网：全国中小学教师教育网址导航， https://www.ossnav.com/可查看。
oldswf ：收集了不少老的 flash 小游戏， https://oldswf.com/是入口。
网抑云音乐：免费听歌的网站， http://mc.alger.fun/#/可体验。
豆瓣 2024 年度电影榜单：豆瓣 2024 年度电影榜单搜索， https://movie.douban.com/annual/2024/可访问。
xinyuan ：影视镜头搜索， http://www.movieminer.top:5301/standalone/page/225是链接。
Movieminer ：一键拉片工具， http://www.movieminer.top/可查看。
扣子搜索：智能体搜索， https://www.coze.cn/store/agent?cate_type=recommend是官网。
羽燕招标：免费搜索全国招标信息， https://yuyan888.cn/h可访问。
国家哲学社会科学文献中心：中国科技论文在线，科技期刊搜索、科技论文搜索， https://www.paper.edu.cn/journal/index.shtml可查看。
查文献神器：文献搜索的利器， http://www.4243.net/可体验。
全能计算器：各种各样的计算器， https://www.omnicalculator.com/是网址。
淘花场：百度网盘资源搜索，阿里云盘搜索，网盘搜索导航， https://www.taohuachang.com/可访问。
爱悦读网：电子书搜索， http://www.iyd.wang/是链接。
SeedHub ：已收录 25000 + 资源， https://www.seedhub.cc/是入口。
Google 地图在线：谷歌地图镜像，谷歌卫星高清地图， http://www.gditu.net/可查看。
SVG Repo ：500.000 + 开放许可的 SVG 矢量和图标， https://www.svgrepo.com/是官网。
网盘共享中心——搜网盘：支持多种网盘的资源搜索网站， https://news.bqrdh.com/wp可体验。
数字素养网：全国中小学教师教育网址导航， https://szsyw.cn/jiaoshi可访问。
开源精选：优质开源工具导航， https://www.ossnav.com/是网址。
SOSO 云盘搜索导航： https://www.sosoyunpan.com/可体验。
小白盘：网盘搜索， https://www.xiaobaipan.com/是链接。

超谷歌搜索：阿里开源创新大模型搜索引擎 ZeroSearch，成本直降 80% 且能力更强

Fri, 09 May 2025 07:14:52 CST

IT之家 5 月 9 日消息，阿里巴巴昨日在 Github 等平台开源了 ZeroSearch 大模型搜索引擎。这是一种无需与真实搜索引擎交互即可激励大模型搜索能力的强化学习框架。

ZeroSearch 主要利用了大模型在大规模预训练过程中积累的丰富知识，将其转化为一个检索模块，能够根据搜索查询生成相关内容。同时，还可以动态控制生成内容的质量，这是传统搜索引擎所不具备的特殊功能。

研究人员在 NQ、TriviaQA、PopQA、HotpotQA 等 7 大问答数据集上进行了综合评测。结果显示，一个 70 亿参数的监督微调模型使用 ZeroSearch 后，其搜索能力达到了 33.06；140 亿参数的模型则达到了 33.97，超过了谷歌搜索的 32.47。

研究人员通过 SerpAPI 使用谷歌搜索进行约 64,000 次搜索查询的训练，成本约为 586.70 美元（IT之家注：现汇率约合 4238 元人民币）；而在四个 A100GPU 上使用 140 亿参数的大模型进行模拟时，成本仅为70.80 美元（现汇率约合 511 元人民币），意味着成本降低了 87.93% 以上。

参考链接：

论文地址：https://arxiv.org/abs/2505.04588
开源地址：https://github.com/Alibaba-nlp/ZeroSearch
抱抱脸：https://huggingface.co/collections/sunhaonlp/zerosearch-681b4ce012b9b6899832f4d0

如何高效搜索 Telegram 信息源？

Tue, 15 Apr 2025 07:58:27 CST

五大工具全面解析 + 实战教程指南

开源情报（OSINT, Open Source Intelligence）作为信息战、商业分析、网络安全调查、反欺诈等领域的 “利器”，越来越多地被情报分析师、记者、研究人员乃至普通网民所熟知。在这个资讯爆炸的时代，Telegram 成为了重要的信息源，尤其在俄乌战争、地下市场、泄露数据、政治动态等领域中，其重要性不容忽视。

那么， 如何高效、系统、深入地搜索 Telegram 中的公开情报信息？ 本文将以 5 个强大实用的 Telegram 搜索工具为核心，逐一解析它们的功能、使用方法、组合技巧以及实际应用场景，带你一步步成为 OSINT 搜索高手！

一、为什么要搜索 Telegram？

Telegram 是一个加密通讯平台，但其 “公开频道” 功能却是 OSINT 的宝库。许多组织、黑客、地下商人甚至政府消息源都使用 Telegram 发布内容。相比 Twitter、Facebook 等平台，Telegram 的 “封闭性” 与 “公开性” 共存，反而让它成为调查人员追踪目标、发现线索的首选平台之一。

二、核心搜索工具介绍

下面我们重点介绍五个可以用于 Telegram 搜索的工具，它们都是开源情报实战中不可多得的利器。

1. Lyzem Telegram Search

特点：

可搜索频道、群组、用户、BOT；
支持关键字、语言筛选；
提供频道分析数据（如订阅数、活跃度等）；
可用于发现目标活动范围或信息扩散路径。

使用教程：

打开网址： https://lyzem.com/
在搜索栏输入关键词（如 “Ukraine Drone”），可选择语言筛选；
点击搜索结果，可查看频道 / 群组简介和最近活跃情况；
可根据频道规模和内容活跃度判断其是否值得关注。

应用案例：
在追踪一个疑似诈骗组织活动时，输入关键词 “Crypto Scam”，找到了几个宣传投资骗局的频道。通过分析其发布时间与互动频率，进一步定位了其目标受众与资金流动路线。

2. Google Custom Telegram Search

特点：

利用 Google 自定义搜索引擎，索引 Telegram 的公开频道内容；
搜索结果更精准，支持高级搜索语法；
可批量查询关键词，搭配 Google Dork 使用效果更佳。

使用教程：

打开链接： https://cse.google.com/cse?&cx=006368593537057042503:efxu7xprihg#gsc.tab=0
输入关键词，如 bitcoin scam site:telegram.org；
查看 Google 返回的 Telegram 页面结果（通常是频道、贴文链接）；
结合搜索语法如 "telegram.org" AND "leak"，进一步精准定位。

使用技巧：

可结合 Google Dork，比如： "giveaway" site:t.me
可用于定位特定时间段发布的信息，搭配 Google 时间筛选功能。

3. TGStat.ru 国际版搜索

特点：

提供 Telegram 频道数据统计与分析；
可按照频道类别（如科技、新闻、黑客、成人等）筛选；
支持多语言界面，信息更新频繁；
提供最近帖子、订阅数、增长曲线等情报。

使用教程：

访问网站： https://tgstat.ru/en/search
输入关键字，可按语言、地区、类别筛选；
查看频道详情、帖子内容和数据图表；
还能查看该频道在其他社交平台的关联。

实际调查用途：
分析一个政治组织的消息扩散路径时，TGStat 提供的 “活跃用户时间分布” 和 “最常被提及的频道” 功能帮助我进一步拓展情报范围。

4. TelegramChannels.me

特点：

频道索引库，按类别细致分类；
可按国家、语言、活跃度排序；
每个频道有基础介绍、订阅链接和标签。

使用教程：

访问网站： https://telegramchannels.me/
浏览或搜索关键词；
可选定特定标签（如 “Leaks”, “Hack”, “Politics”）筛选结果；
点击频道标题，即可跳转至 Telegram 加入或查看内容。

使用建议：
适合初步探索某一主题下的 Telegram 生态图谱，比如想系统研究 “乌克兰战争” 的信息战格局，可逐类分析各阵营的频道分布。

5. Search.buzz.im

特点：

聚焦 Telegram 的内容搜索；
支持搜索公开频道和群组内容；
更新速度快，结果包含时间线和上下文；
UI 轻便直观，适合快速查找。

使用教程：

打开网址： https://search.buzz.im/
输入关键词（支持中英文）；
查看结果页面，包含简要预览内容；
可快速定位某条敏感信息的首次出现时间。

三、如何组合使用这些工具？

为了最大化搜索效果，可以将这些工具 串联起来使用，形成一个高效的情报采集链条：

情报采集链推荐流程：

Copy

   问题 -> 初筛关键词 -> TelegramChannels.me 初探生态 
     -> Lyzem 精准定位活跃频道 -> TGStat 分析数据
     -> Search.buzz.im 或 Google Custom Search 深度提取内容

实例：调查 “Telegram 上的金融诈骗团伙”

关键词确定： “crypto scam”、"investment fraud"
使用 TelegramChannels.me 搜频道 → 获取初始列表
用 Lyzem 查看活跃情况、加入日期、管理员信息
TGStat 分析是否存在订阅增长异动（操控痕迹）
Buzz.im 查找频道内是否有类似 “收款地址”、“钱包截图” 的内容
用 Google Custom Search 定向查找某个钱包地址是否在其他频道出现

四、使用技巧和注意事项

善用关键词组合：如 “泄露 + email”、“招聘 + 黑客” 等；
关注频道活跃曲线：TGStat 提供的数据可辨别是否是 “僵尸频道”；
频道间相互引用图谱：TGStat 或 Lyzem 能让你从一个点拓展到整个网络；
不要仅停留在表面：深挖频道历史内容，寻找可关联证据；
注意隐私与合规性：OSINT 虽是合法的公开情报，但也需遵守地区法律规定。

五、总结：Telegram 是 OSINT 的宝藏地

通过这五个工具的配合使用，我们可以快速、系统地在 Telegram 中构建一个强大的情报分析系统，无论你是追踪黑客活动、调查诈骗案件，还是监控政治动态，它们都将是你 OSINT 工具箱中必不可少的组成部分。

工具总览：

Lyzem Search： https://lyzem.com/
Google Custom Search： https://cse.google.com/cse?&cx=006368593537057042503:efxu7xprihg#gsc.tab=0
TGStat： https://tgstat.ru/en/search
TelegramChannels.me： https://telegramchannels.me/
Buzz.im Search： https://search.buzz.im/

END

Google搜索引擎架构Caffeine

Wed, 04 Dec 2024 22:09:28 CST

什么是 Google Caffeine？

Google Caffeine 是 Google 搜索引擎的一次架构重构，旨在满足不断增长的互联网内容和用户实时搜索需求。它替代了 Google 早期的分层索引系统，转而采用更加实时的索引机制，使搜索结果更加快速和新鲜。

发布时间：Google 于 2009 年 8 月发布 Caffeine 项目 Beta 版本，并于 2010 年 6 月正式启用。

Google Caffeine的产生背景

传统索引架构的局限性

在 Caffeine 出现之前，Google 使用的是一个分层的索引结构：

分层索引：
- 数据分为“主索引”和“增量索引”。
- 主索引：周期性地更新，通常需要几天或几周。
- 增量索引：包含最新的数据，但覆盖范围较小。
更新延迟：对于新增的网页或内容，用户可能需要等待较长时间才能在搜索结果中看到。
扩展性瓶颈：随着互联网内容的指数增长，传统架构难以高效处理。

Google Caffeine 的目标

提高索引速度：支持更快地抓取和处理新增内容（如新闻、博客、社交媒体）。
改进搜索结果的新鲜度：实现接近实时的搜索结果，用户能够快速获取最新信息。
扩展性：提升 Google 数据中心的存储和处理能力，满足日益增长的互联网规模。
提升性能：降低搜索延迟，改善用户体验。

Google Caffeine 的核心特性

实时索引：
- Caffeine 实现了一个单层实时索引系统。
- 新的网页和内容在被抓取后，几乎立即可供搜索使用。
分布式处理：
- 利用 Google 的分布式文件系统（GFS），对网页进行分片存储和处理。
- 大量服务器协同工作，提高数据处理速度。
高效的分片机制：
- 把网页划分为多个独立的“索引片”（index shard），每个片可以独立更新和查询。
改进抓取策略：
- 更频繁地抓取更新频率高的网站（如新闻网站）。
- 对重要页面和内容优先处理。
支持海量数据：
- Caffeine 的架构允许 Google 索引比以前多得多的网页内容，同时支持更多种类的数据（如图片、视频、实时内容）。

Caffeine 的技术优势

特性	传统索引架构	Google Caffeine
索引更新频率	周期性（数天至数周）	实时更新
处理速度	较慢	高效并行处理
扩展性	有限	动态可扩展
数据类型支持	主要是网页	多种数据类型

速度与效率：每秒可以处理数以千计的网页更新，显著提高了索引更新的频率。
可扩展性：动态扩展索引容量，适应互联网规模的持续增长。
新鲜度：通过实时处理机制，确保用户搜索结果中始终包含最新内容。
数据融合：Caffeine 不仅索引网页，还将图片、视频、社交媒体内容等多种类型数据整合到搜索结果中。

Google Caffeine的影响

对用户的影响

更快的搜索结果：用户可以几乎实时地获得最新的新闻、博客和社交媒体内容。
更全面的搜索覆盖：索引规模的扩大意味着用户能够搜索到更多样化的内容。
搜索体验提升：减少了延迟，搜索结果更加相关。

对网站管理员的影响

频繁抓取：Googlebot 的抓取频率增加，对频繁更新的网站尤为明显。
关注内容更新：网站需要更注重内容质量和频繁更新，以便在搜索中保持竞争力。
页面权重动态变化：页面排名可能会更快地反映内容的更新和链接关系的变化。

对互联网行业的影响

推动实时搜索：其他搜索引擎（如 Bing、Yahoo）也纷纷改进索引技术，以缩短数据处理延迟。
促进内容生产：更快速的内容索引激励了新闻网站和博客作者加速生产优质内容。
提高搜索质量：用户能够获得更加多样化和相关的搜索结果。

Google Caffeine 是一次革命性的搜索引擎升级，标志着搜索技术进入实时化时代。它不仅大幅提升了 Google 的搜索能力，还推动了整个互联网生态系统的快速发展。如果对其架构或技术实现有更深入的兴趣，可以讨论相关的分布式系统和大规模数据处理技术（如 GFS、 Bigtable、 MapReduce 等）。

Google Caffeine后更新

Google Caffeine 的推出是 Google 搜索引擎历史上的重要里程碑，但它并不是终点。Caffeine 后，Google 持续在搜索算法、基础架构和用户体验方面进行升级，以应对互联网快速变化的需求和挑战。

Google 在 Caffeine 后的升级，主要集中在以下几个方向：

更智能的查询理解：RankBrain、BERT、MUM。
用户体验优化：移动优先索引、页面体验更新。
实时性与动态性：实时数据索引和搜索。
安全性与透明性：加强数据隐私和搜索可信度。
生成式 AI 的应用：引入生成式 AI，提供更全面和互动的答案。

每一次升级都反映了 Google 对搜索体验优化的持续追求，同时适应了技术趋势和用户需求的变化。

以下是 Google 在 Caffeine 后的主要升级和改进：

RankBrain（2015 年）

RankBrain 是 Google 搜索引擎引入的机器学习算法，用于更好地理解用户查询背后的意图，特别是长尾查询和模糊表达。

核心功能：
- 将查询转换为向量形式（数值表示），便于理解和匹配用户意图。
- 提升了对自然语言查询的处理能力。
影响：
- 搜索结果变得更加相关和智能。
- RankBrain 成为 Google 排名因素之一，与内容相关性和页面权威性共同决定排名。

BERT（2019 年）

BERT（Bidirectional Encoder Representations from Transformers） 是 Google 推出的基于深度学习的自然语言处理技术，用于理解查询的上下文含义。

核心改进：
- BERT 能双向分析查询中的词语和短语，而不是孤立地理解单个词。
- 尤其对长查询和疑问句效果显著。
应用场景：在多个语言版本的搜索中使用，改善了 70 多种语言的搜索质量。
举例：查询 “2019年在巴西的游客需要签证吗？”
- BERT 可以正确理解“在巴西”是对游客的修饰，而不是对签证的修饰。

移动优先索引（Mobile-First Indexing，2016 年启动，2021 年完成）

随着移动设备使用量的增加，Google 改变了索引策略，从桌面优先转向移动优先。

核心概念：Google 搜索索引以网站的移动版本为基础，而非桌面版本。
影响：
- 网站需要优化其移动页面，以确保排名不受影响。
- 响应式设计和快速加载成为关键因素。

Page Experience Update（页面体验更新，2021 年）

Google 强调用户体验因素，将 Core Web Vitals（核心网页指标）纳入排名算法。

核心指标：
- LCP（Largest Contentful Paint）：页面主要内容的加载速度。
- FID（First Input Delay）：用户与页面首次交互的响应速度。
- CLS（Cumulative Layout Shift）：页面布局稳定性。
其他因素：
- HTTPS 安全性。
- 无侵入性广告。
影响：更注重用户友好的设计，缓慢或交互不佳的网站可能失去排名。

MUM（Multitask Unified Model，2021 年）

MUM 是 Google 搜索的多任务统一模型，旨在更智能地处理复杂查询，并提供综合答案。

核心特点：
- 使用多模态模型，能够同时处理文本、图像甚至视频数据。
- 支持多语言理解，并能将知识迁移到不同语言。
应用场景：复杂查询（例如：计划登山旅行需要哪些准备？），MUM 可以整合多种资源，生成更全面的答案。
改进：支持图文结合的搜索，比如用户上传一张图片并配以问题。

实时搜索与增强数据呈现

Google 持续增强搜索结果的动态性和直观性：

实时搜索：整合新闻、社交媒体动态（如 Twitter）、股市变化等实时数据。
丰富的结果展示：
- 使用知识图谱（Knowledge Graph）提供结构化信息。
- 提供更直观的搜索结果卡片（例如：直接在搜索页面上显示天气、赛事结果、影片简介等）。

神经匹配（Neural Matching，2018 年）

Neural Matching 是一种基于神经网络的算法，专注于更好地匹配用户查询和网页内容之间的相关性。

特点：更偏向于全局语义理解，而非关键词匹配。
应用场景：特别是在用户查询中未使用精确关键词的情况下表现突出。

AI 驱动的改进（2023 年及之后）

Google 不断使用更先进的 AI 模型改进搜索引擎，包括生成式 AI 的引入：

生成式 AI 回答：提供直接的、简短的答案，尤其在用户提出的问题非常具体时。
对话式搜索：搜索引擎逐渐具备类似 ChatGPT 的能力，能够与用户进行多轮对话。

数据隐私与安全性改进

近年来，Google 加强了对用户数据隐私的保护，同时确保搜索结果的可信度：

隐私保护：为用户提供更多控制搜索记录的方式。
搜索透明性：提供“关于此结果”（About This Result）的功能，帮助用户了解来源的可靠性。

Google 罕见的披露了给它带来最多广告收入的搜索查询词

Thu, 02 Nov 2023 19:31:36 CST

不是每一次搜索都能给 Google 带来收入。搜索巨人表示它通常只在五分之一的搜索查询结果中展示广告。此类的查询被称为“商业查询”。在 US v. Google 的反垄断诉讼中，我们有机会了解到了给 Google 带来最多广告收入的搜索查询词名单。该名单发生在 2018 年 9 月 22 日这一周，苹果的 iPhone 8 在这一周开始上市，因此给 Google 带来最多收入的是对苹果新手机的搜索。收入排在前 20 的关键词包括：iphone 8、iphone 8 plus、auto insurance、car insurance、cheap flights、car insurance quotes、direct tv、online colleges、at&t、hulu、iphone、uber、spectrum、comcast、xfinity、insurance quotes、free credit report、cheap car insurance、aarp 以及 lifelock。

Elasticsearch：使用 Elasticsearch 进行语义搜索

Thu, 28 Sep 2023 10:18:31 CST

在数字时代，搜索引擎在通过浏览互联网上的大量可用信息来检索数据方面发挥着重要作用。此方法涉及用户在搜索栏中输入特定术语或短语，期望搜索引擎返回与这些确切关键字匹配的结果。

虽然关键字搜索对于简化信息检索非常有价值，但它也有其局限性。主要缺点之一在于它对词汇匹配的依赖。关键字搜索将查询中的每个单词视为独立的实体，通常会导致结果可能与用户的意图不完全一致。此外，不明确的查询可能会产生不同的解释，从而导致混合或不准确的结果。

当处理上下文严重影响含义的语言时，会出现另一个关键限制。词语的含义在很大程度上取决于具体情况。单独使用关键字可能无法正确捕获这些查询，这可能会导致误解。

随着我们的数字环境不断发展，我们对更精致、更直观的搜索体验的期望也在不断变化。这为语义搜索的出现铺平了道路，语义搜索是一种旨在超越传统基于关键字的方法的局限性的方法。通过关注搜索查询的意图和上下文含义，语义搜索为关键字搜索带来的挑战提供了一种有前景的解决方案。

如上面的图片所示，如果我们通过 keyword 来进行搜索，我们想搜索的是 apple 水果，但是我们最终可能得到是关于 apple（苹果）公司的有关信息。其实它并不是我们想要的。

什么是语义搜索？

语义搜索是在互联网上搜索内容的高级方式。它不仅仅是匹配单词，而是理解你真正在寻找的内容。它能找出你的话背后的含义以及它们之间的关系。

这项技术使用人工智能和理解人类语言等技术。几乎就像它在说人类一样！它着眼于大局，检查具有相似含义的单词以及与你所问问题相关的其他想法。

基本上，语义搜索可以帮助你从互联网上的大量内容中准确获取所需的内容。这就像与一个超级聪明的搜索引擎交谈，它不仅可以获取你所说的单词，还可以获取你真正想要查找的内容。这使得它非常适合做研究、查找信息，甚至获得符合你兴趣的建议。

语义搜索的好处

精确度和相关性：语义搜索通过理解用户意图和上下文提供高度相关的结果。
自然语言理解：它理解复杂的查询，使自然语言交互更加有效。
消除歧义：它解决歧义查询，根据用户行为和上下文提供准确的结果。
个性化：语义搜索从用户行为中学习以获取定制结果，从而随着时间的推移提高相关性。

Elastic Search 中的语义搜索

Elastic Search 提供语义搜索，重点关注搜索查询的含义和上下文，而不仅仅是匹配关键字。它使用自然语言处理（NLP）和向量搜索来实现这一目标。 Elastic 有自己的预训练表示模型，称为 Elastic Learned Sparse EncodeR (ELSER)。

在进入 ELSER 之前，让我们更多地了解 NLP 和向量搜索。

自然语言处理（NLP）

自然语言处理是人工智能的一个分支，致力于使计算机能够以有价值且有用的方式理解、解释和生成人类语言。

NLP 涉及一组允许计算机处理和分析大量自然语言数据的技术和算法。这包括以下任务：

文本理解：NLP 帮助计算机理解一篇文章的内容。它可以找出文本中的重要内容，例如姓名、关系和感受。
文本处理：这涉及将句子分解为单词或短语、将单词简化为其基本形式以及识别句子的不同部分等任务。
命名实体识别 (NER)：NLP 可以识别文本中的特殊事物，例如人名、地名或组织名称。这有助于理解正在讨论的内容。

向量搜索

向量搜索是一种涉及将数据点或信息表示为多维空间中的向量的技术。空间的每个维度代表文档或数据点的不同特征或属性。

在这个向量空间中，相似的文档或数据点彼此距离更近。这允许有效的基于相似性的搜索。例如，如果你正在搜索与给定文档相似的文档，则可以计算表示文档的向量之间的相似度以查找最接近的匹配项。

向量搜索广泛用于各种应用，包括：

推荐系统：它有助于根据用户的喜好向他们推荐类似的项目。
信息检索：它允许在大型语料库中查找相似的文档。
异常检测：它有助于识别异常或异常数据点。

NLP 与向量搜索的工作原理

1）Vector embedding：
在此步骤中，NLP 涉及将文本数据转换为数值向量。使用词嵌入等技术将文本中的每个单词转换为高维向量

2.相似度分数：

引擎将向量化查询与向量化文档进行比较以确定它们的相似性。

3）人工神经网络算法：

近似最近邻 (ANN) 算法可有效查找高维空间中的近似最近邻。

4）查询处理：

用户的查询经历与文档类似的处理以生成向量表示。

5）距离计算：

引擎计算向量化查询和文档之间的距离（相似度分数）。

6）最近邻搜索：

引擎查找嵌入最接近查询嵌入的文档。

7）排名结果：

结果根据相似度分数进行排名。

ELSER

ELSER 是一个经过专门设计的预训练模型，可以出色地理解上下文和意图，而无需进行复杂的微调。 ELSER 目前仅适用于英语，其开箱即用的适应性使其成为各种自然语言处理任务的宝贵工具。它对稀疏向量表示的利用提高了处理文本数据的效率。 ELSER 的词汇表中包含约 30,000 个术语，通过用上下文相关的对应项替换术语来优化查询，确保精确而全面的搜索结果。

让我们深入探讨如何利用 ELSER 的潜力来增强 Elasticsearch 中的搜索能力。你可以参考文章 “ Elasticsearch：部署 ELSER - Elastic Learned Sparse EncoderR” 来配置自己的 ELSER。

第 1 步：创建具有所需映射的索引

在 Elasticsearch 中，“索引 (index)” 是指具有共同特征或属于相似类别的文档的集合。它类似于关系数据库中的表或其他一些 NoSQL 数据库中的类型。索引中的每个文档都分配有一个唯一标识符，并且包含 JSON 格式的结构化数据。
定义索引的映射，该映射将包含模型根据您的输入生成的 token。该索引必须有一个 rank_features 字段类型的字段来索引 ELSER 输出。

  

1.  PUT <index-name>
2.  {
3.    "mappings": {
4.      "properties": {
5.        "ml.tokens": { 
6.          "type": "rank_features" 
7.        },
8.        "name": { 
9.          "type": "text" 
10.        }
11.      }
12.    }
13.  }

第 2 步：使用推理处理器创建摄取管道

Elasticsearch 中的摄取管道使您能够在索引之前对数据应用各种转换。这些转换包括字段删除、文本值提取和数据丰富等任务。
管道包含一组称为处理器的可定制任务。这些处理器以顺序方式运行，对传入文档实施特定修改。使用推理处理器创建摄取管道，以使用 ELSER 对正在摄取的数据进行推理。

  

1.  PUT _ingest/pipeline/<pipeline-name>
2.  {
3.    "processors": [
4.      {
5.        "inference": {
6.          "model_id": ".elser_model_1",
7.          "target_field": "ml",
8.          "field_map": { 
9.            "text": "text_field"
10.          },
11.          "inference_config": {
12.            "text_expansion": { 
13.              "results_field": "tokens"
14.            }
15.          }
16.        }
17.      }
18.    ]
19.  }

第 3 步：将数据添加到索引

索引映射和摄取管道已设置，现在我们可以开始向索引添加数据。
摄取管道作用于传入数据并将相关标记添加到文档中

  

1.  curl -X POST 'https://<url>/<index-name>/_doc?pipeline=<ingest-pipeline-name' 
2.    -H 'Content-Type: application/json' 
3.    -H 'Authorization: ApiKey <Replace_with_created_API_key>' 
4.    -d '{
5.    "name" : "How to Adapt Crucial Conversations to Global Audiences"
6.  }'

摄取管道作用于传入数据并将相关 token 添加到文档中：

  

1.  {
2.   "name" : "How to Adapt Crucial Conversations to Global Audiences",
3.   "ml":{
4.      "tokens": {
5.          "voice": 0.057680283,
6.          "education": 0.18481751,
7.          "questions": 0.4389099,
8.          "adaptation": 0.6029656,
9.          "language": 0.4136539,
10.          "quest": 0.082507774,
11.          "presentation": 0.035054933,
12.          "context": 0.2709603,
13.          "talk": 0.17953876,
14.          "communication": 1.0619682,
15.          "international": 0.38651025,
16.          "different": 0.25769454,
17.          "conversation": 1.03593,
18.          "train": 0.021380302,
19.          "audience": 0.97641367,
20.          "development": 0.33928272,
21.          "adapt": 0.90020984,
22.          "certification": 0.45675382,
23.          "cultural": 0.63132435,
24.          "distraction": 0.38943478,
25.          "success": 0.09179027,
26.          "cultures": 0.82463825,
27.          "essay": 0.2730616,
28.          "institute": 0.21582486,
29.         },
30.         "model_id":".elser_model_1"
31.      }
32.  }

第 4 步：执行语义搜索

使用 text expansion 查询来执行语义搜索。提供查询文本和 ELSER 模型 ID。
文本扩展查询使用自然语言处理模型将查询文本转换为 token 权重对列表，然后将其用于针对 rank_features 字段的查询。

  

1.  GET <index-name>/_search
2.  {
3.     "query":{
4.        "text_expansion":{
5.           "ml.tokens":{
6.              "model_id":".elser_model_1",
7.              "model_text":<query_text>
8.           }
9.        }
10.     }
11.  }

第 5 步：将语义搜索与其他查询结合起来

我们还可以将 text_expansion 与复合查询中的其他查询结合起来，以获得更精细的结果。

  

1.  GET my-index/_search
2.  {
3.    "query": {
4.      "bool": { 
5.        "should": [
6.          {
7.            "text_expansion": {
8.              "ml.tokens": {
9.                "model_text": <query_text>,
10.                "model_id": ".elser_model_1",
11.              }
12.            }
13.          },
14.          {
15.            "query_string": {
16.              "query": <query_text>,
17.            }
18.          }
19.        ]
20.      }
21.    }
22.  }

我们还可以将 text_expansion 与复合查询中的其他查询结合起来，以获得更精细的结果。
与 Elasticsearch 中的其他查询相比，text_expansion 查询通常会产生更高的分数。我们可以使用 boost 参数调整相关性分数。

更多阅读：

Embedding - 另一种站内搜索方案

Sat, 06 May 2023 07:42:19 CST

最近在考虑站内搜索的技术方案时，首先考虑的是Embedding的方案而不是全文索引。

对于普通网站，数据量不算大，上全文检索很麻烦，需要专门的服务，第三方服务贵，自己搭需要额外服务器。

现在借助Embedding方案搭配向量数据，就可以简单很多，每次新增或者更新内容，同时生成向量数据存到数据库，搜索时，将搜索的关键词生成向量再去向量数据库搜索。

Embedding有不少开源方案，即使用OpenAI的成本也不高。

但我还没实际试过，不知道有没有已经用过这套方案的欢迎分享经验教训。

补充一下这分词和Embedding的区别 http://t.cn/A6NYugbE ：

分词是将原文的文本分词，搜索的时候关键字和分词结果匹配就能搜到结果，如果文本匹配。

比如你有段文字：“老鼠爱大米”，会分词成“老鼠”、“爱”、“大米”、“爱大米”、“老鼠爱大米”等，你搜任意个分词例如“老鼠”，就能找到，但是你搜“🐭”“mouse”“老鼠爱食物”是搜不到的。

Embedding是将文本变成多维数字向量，按照文本之间的相似度搜索的，语言无关，不需要精确匹配关键字只要意思相近也能匹配到。

同样你有段文字：“老鼠爱大米”，会变成数字向量，例如

[.., 0.3, 0.5, ....]，那么用户搜索“老鼠”，也先变成数字向量[.., 0.2, 0.3, ....]，然后去向量数据库搜索，会搜索到“老鼠爱大米”这个项对应的匹配度最高，并且超过一定阈值，那就返回它作为匹配的结果。类似的，你搜“🐭”，也是先变成向量[.., 0.21, 0.3, ....]再搜索，这个向量和之前“老鼠”的向量只有细微的差别，所以你一样能得到跟“老鼠”或“mouse”差不多的搜索结果。

另外OpenAI介绍Embedding的文档写的非常好👍🏻

http://t.cn/A6NYmQXQ

ChatGPT 式搜索对 Google 微软而言意味着成本增加 10 倍

Thu, 23 Feb 2023 23:50:17 CST

今天的搜索引擎首先需要构建一个庞大 Web 索引，用户搜索时对索引条目进行扫描、排序和分类，最相关条目出现在搜索结果中。整个搜索过程通常不需要一秒钟。相比之下，AI 聊天机器人 ChatGPT 搜索时需要启动一个庞大的神经网络模型，产生文本，可能还需要利用搜索引擎核查事实信息。整个过程要漫长得多，花费也更多。分析师估计，大语言模型的搜索成本可能是关键词搜索的 10 倍以上，意味着数十亿美元的额外成本。如果 Google 提供了 ChatGPT 式搜索它的成本每年将增加 60 亿美元。

ChatGPT会取代搜索引擎吗

Thu, 09 Feb 2023 17:05:14 CST

作为智能对话系统，ChatGPT最近两天爆火，都火出技术圈了，网上到处都在转ChatGPT相关的内容和测试例子，效果确实很震撼。我记得上一次能引起如此轰动的AI技术，NLP领域是GPT 3发布，那都是两年半前的事了，当时人工智能如日中天如火如荼的红火日子，今天看来恍如隔世；多模态领域则是以DaLL E2、Stable Diffusion为代表的Diffusion Model，这是最近大半年火起来的AIGC模型；而今天，AI的星火传递到了ChatGPT手上，它毫无疑问也属于AIGC范畴。所以说，在AI泡沫破裂后处于低谷期的今天，AIGC确实是给AI续命的良药，当然我们更期待估计很快会发布的GPT 4，愿OpenAI能继续撑起局面，给行业带来一丝暖意。

说回ChatGPT，例子就不举了，在网上漫山遍野都是，我们主要从技术角度来聊聊。那么，ChatGPT到底是采用了怎样的技术，才能做到如此超凡脱俗的效果？既然chatGPT功能如此强大，那么它可以取代Google、百度等现有搜索引擎吗？如果能，那是为什么，如果不能，又是为什么？

本文试图从我个人理解的角度，来尝试回答上述问题，很多个人观点，偏颇难免，还请谨慎参考。我们首先来看看ChatGPT到底做了什么才获得如此好的效果。

ChatGPT的技术原理

整体技术路线上，ChatGPT在效果强大的GPT 3.5大规模语言模型（LLM，Large Language Model）基础上，引入“人工标注数据+强化学习”（RLHF，Reinforcement Learning from Human Feedback ，这里的人工反馈其实就是人工标注数据）来不断Fine-tune预训练语言模型，主要目的是让LLM模型学会理解人类的命令指令的含义（比如给我写一段小作文生成类问题、知识回答类问题、头脑风暴类问题等不同类型的命令），以及让LLM学会判断对于给定的prompt输入指令（用户的问题），什么样的答案是优质的（富含信息、内容丰富、对用户有帮助、无害、不包含歧视信息等多种标准）。

在“人工标注数据+强化学习”框架下，具体而言，ChatGPT的训练过程分为以下三个阶段：

ChatGPT:第一阶段

第一阶段：冷启动阶段的监督策略模型。靠GPT 3.5本身，尽管它很强，但是它很难理解人类不同类型指令中蕴含的不同意图，也很难判断生成内容是否是高质量的结果。为了让GPT 3.5初步具备理解指令中蕴含的意图，首先会从测试用户提交的prompt(就是指令或问题)中随机抽取一批，靠专业的标注人员，给出指定prompt的高质量答案，然后用这些人工标注好的<prompt,answer>数据来Fine-tune GPT 3.5模型。经过这个过程，我们可以认为GPT 3.5初步具备了理解人类prompt中所包含意图，并根据这个意图给出相对高质量回答的能力，但是很明显，仅仅这样做是不够的。

ChatGPT:第二阶段

第二阶段：训练回报模型（Reward Model,RM）。这个阶段的主要目的是通过人工标注训练数据，来训练回报模型。具体而言，随机抽样一批用户提交的prompt(大部分和第一阶段的相同)，使用第一阶段Fine-tune好的冷启动模型，对于每个prompt，由冷启动模型生成K个不同的回答，于是模型产生出了<prompt,answer1>,<prompt,answer2>….<prompt,answerK>数据。之后，标注人员对K个结果按照很多标准（上面提到的相关性、富含信息性、有害信息等诸多标准）综合考虑进行排序，给出K个结果的排名顺序，这就是此阶段人工标注的数据。

接下来，我们准备利用这个排序结果数据来训练回报模型，采取的训练模式其实就是平常经常用到的pair-wise learning to rank。对于K个排序结果，两两组合，形成个训练数据对，ChatGPT采取pair-wise loss来训练Reward Model。RM模型接受一个输入<prompt,answer>，给出评价回答质量高低的回报分数Score。对于一对训练数据<answer1,answer2>，我们假设人工排序中answer1排在answer2前面，那么Loss函数则鼓励RM模型对<prompt,answer1>的打分要比<prompt,answer2>的打分要高。

归纳下：在这个阶段里，首先由冷启动后的监督策略模型为每个prompt产生K个结果，人工根据结果质量由高到低排序，以此作为训练数据，通过pair-wise learning to rank模式来训练回报模型。对于学好的RM模型来说，输入<prompt,answer>，输出结果的质量得分，得分越高说明产生的回答质量越高。

chatGPT:第三阶段

第三阶段：采用强化学习来增强预训练模型的能力。本阶段无需人工标注数据，而是利用上一阶段学好的RM模型，靠RM打分结果来更新预训练模型参数。具体而言，首先，从用户提交的prompt里随机采样一批新的命令（指的是和第一第二阶段不同的新的prompt，这个其实是很重要的，对于提升LLM模型理解instruct指令的泛化能力很有帮助），且由冷启动模型来初始化PPO模型的参数。然后，对于随机抽取的prompt，使用PPO模型生成回答answer，并用上一阶段训练好的RM模型给出answer质量评估的回报分数score，这个回报分数就是RM赋予给整个回答（由单词序列构成）的整体reward。有了单词序列的最终回报，就可以把每个单词看作一个时间步，把reward由后往前依次传递，由此产生的策略梯度可以更新PPO模型参数。这是标准的强化学习过程，目的是训练LLM产生高reward的答案，也即是产生符合RM标准的高质量回答。

如果我们不断重复第二和第三阶段，很明显，每一轮迭代都使得LLM模型能力越来越强。因为第二阶段通过人工标注数据来增强RM模型的能力，而第三阶段，经过增强的RM模型对新prompt产生的回答打分会更准，并利用强化学习来鼓励LLM模型学习新的高质量内容，这起到了类似利用伪标签扩充高质量训练数据的作用，于是LLM模型进一步得到增强。显然，第二阶段和第三阶段有相互促进的作用，这是为何不断迭代会有持续增强效果的原因。

尽管如此，我觉得第三阶段采用强化学习策略，未必是ChatGPT模型效果特别好的主要原因。假设第三阶段不采用强化学习，换成如下方法：类似第二阶段的做法，对于一个新的prompt，冷启动模型可以产生k个回答，由RM模型分别打分，我们选择得分最高的回答，构成新的训练数据<prompt,answer>,去fine-tune LLM模型。假设换成这种模式，我相信起到的作用可能跟强化学习比，虽然没那么精巧，但是效果也未必一定就差很多。第三阶段无论采取哪种技术模式，本质上很可能都是利用第二阶段学会的RM，起到了扩充LLM模型高质量训练数据的作用。

以上是ChatGPT的训练流程，主要参考自instructGPT的论文，ChatGPT是改进的instructGPT，改进点主要在收集标注数据方法上有些区别，在其它方面，包括在模型结构和训练流程等方面基本遵循instructGPT。可以预见的是，这种Reinforcement Learning from Human Feedback技术会快速蔓延到其它内容生成方向，比如一个很容易想到的，类似“A machine translation model based on Reinforcement Learning from Human Feedback”这种，其它还有很多。但是，我个人认为，在NLP的某个具体的内容生成领域再采用这个技术意义应该已经不大了，因为chatGPT本身能处理的任务类型非常多样化，基本涵盖了NLP生成的很多子领域，所以某个NLP子领域如果再单独采用这个技术其实已经不具备太大价值，因为它的可行性可以认为已经被chatGPT验证了。如果把这个技术应用在比如图片、音频、视频等其它模态的生成领域，可能是更值得探索的方向，也许不久后我们就会看到类似“A XXX diffusion model based on Reinforcement Learning from Human Feedback”,诸如此类，这类工作应该还是很有意义的。

另外一个值得关注的采取类似技术的工作是DeepMind的sparrow，这个工作发表时间稍晚于instructGPT，如果你仔细分析的话，大的技术思路和框架与instructGPT的三阶段基本类似，不过明显sparrow在人工标注方面的质量和工作量是不如instructGPT的。反过来，我觉得sparrow里把回报模型分为两个不同RM的思路，是优于instructGPT的，至于原因在下面小节里会讲。

chatGPT能否取代Google、百度等传统搜索引擎

既然看上去chatGPT几乎无所不能地回答各种类型的prompt，那么一个很自然的问题就是：ChatGPT或者未来即将面世的GPT4，能否取代Google、百度这些传统搜索引擎呢？我个人觉得目前应该还不行，但是如果从技术角度稍微改造一下，理论上是可以取代传统搜索引擎的。

为什么说目前形态的chatGPT还不能取代搜索引擎呢？主要有三点原因：首先，对于不少知识类型的问题，chatGPT会给出看上去很有道理，但是事实上是错误答案的内容（参考上图的例子（from @Gordon Lee）,ChatGPT的回答看着胸有成竹，像我这么没文化的基本看了就信了它，回头查了下这首词里竟然没这两句），考虑到对于很多问题它又能回答得很好，这将会给用户造成困扰：如果我对我提的问题确实不知道正确答案，那我是该相信ChatGPT的结果还是不该相信呢？此时你是无法作出判断的。这个问题可能是比较要命的。其次，ChatGPT目前这种基于GPT大模型基础上进一步增加标注数据训练的模式，对于LLM模型吸纳新知识是非常不友好的。新知识总是在不断出现，而出现一些新知识就去重新预训练GPT模型是不现实的，无论是训练时间成本还是金钱成本，都不可接受。如果对于新知识采取Fine-tune的模式，看上去可行且成本相对较低，但是很容易产生新数据的引入导致对原有知识的灾难遗忘问题，尤其是短周期的频繁fine-tune，会使这个问题更为严重。所以如何近乎实时地将新知识融入LLM是个非常有挑战性的问题。其三，ChatGPT或GPT4的训练成本以及在线推理成本太高，导致如果面向真实搜索引擎的以亿记的用户请求，假设继续采取免费策略，OpenAI无法承受，但是如果采取收费策略，又会极大减少用户基数，是否收费是个两难决策，当然如果训练成本能够大幅下降，则两难自解。以上这三个原因，导致目前ChatGPT应该还无法取代传统搜索引擎。

那么这几个问题，是否可以解决呢？其实，如果我们以ChatGPT的技术路线为主体框架，再吸纳其它对话系统采用的一些现成的技术手段，来对ChatGPT进行改造，从技术角度来看，除了成本问题外的前两个技术问题，目前看是可以得到很好地解决。我们只需要在ChatGPT的基础上，引入sparrow系统以下能力：基于retrieval结果的生成结果证据展示，以及引入LaMDA系统的对于新知识采取retrieval模式，那么前面提到的新知识的及时引入，以及生成内容可信性验证，基本就不是什么大问题。

基于以上考虑，在上图中展示出了我心目中下一代搜索引擎的整体结构:它其实是目前的传统搜索引擎+ChatGPT的双引擎结构，ChatGPT模型是主引擎，传统搜索引擎是辅引擎。传统搜索引擎的主要辅助功能有两个：一个是对于ChatGPT产生的知识类问题的回答，进行结果可信性验证与展示，就是说在ChatGPT给出答案的同时，从搜索引擎里找到相关内容片段及url链接，同时把这些内容展示给用户，使得用户可以从额外提供的内容里验证答案是否真实可信，这样就可以解决ChatGPT产生的回答可信与否的问题，避免用户对于产生结果无所适从的局面。当然，只有知识类问题才有必要寻找可信信息进行验证，很多其他自由生成类型的问题，比如让ChatGPT写一个满足某个主题的小作文这种完全自由发挥的内容，则无此必要。所以这里还有一个什么情况下会调用传统搜索引擎的问题，具体技术细节完全可仿照sparrow的做法，里面有详细的技术方案。传统搜索引擎的第二个辅助功能是及时补充新知识。既然我们不可能随时把新知识快速引入LLM，那么可以把它存到搜索引擎的索引里，ChatGPT如果发现具备时效性的问题，它自己又回答不了，则可以转向搜索引擎抽取对应的答案，或者根据返回相关片段再加上用户输入问题通过ChatGPT产生答案。关于这方面的具体技术手段，可以参考LaMDA，其中有关于新知识处理的具体方法。

除了上面的几种技术手段，我觉得相对ChatGPT只有一个综合的Reward Model，sparrow里把答案helpful相关的标准（比如是否富含信息量、是否合乎逻辑等）采用一个RM，其它类型toxic/harmful相关标准（比如是否有bias、是否有害信息等）另外单独采用一个RM，各司其职，这种模式要更清晰合理一些。因为单一类型的标准，更便于标注人员进行判断，而如果一个Reward Model融合多种判断标准，相互打架在所难免，判断起来就很复杂效率也低，所以感觉可以引入到ChatGPT里来，得到进一步的模型改进。

通过吸取各种现有技术所长，我相信大致可以解决ChatGPT目前所面临的问题，技术都是现成的，从产生内容效果质量上取代现有搜索引擎问题不大。当然，至于模型训练成本和推理成本问题，可能短时期内无法获得快速大幅降低，这可能是决定LLM是否能够取代现有搜索引擎的关键技术瓶颈。从形式上来看，未来的搜索引擎大概率是以用户智能助手APP的形式存在的，但是，从短期可行性上来说，在走到最终形态之前，过渡阶段大概率两个引擎的作用是反过来的，就是传统搜索引擎是主引擎，ChatGPT是辅引擎，形式上还是目前搜索引擎的形态，只是部分搜索内容Top 1的搜索结果是由ChatGPT产生的，大多数用户请求，可能在用户看到Top 1结果就能满足需求，对于少数满足不了的需求，用户可以采用目前搜索引擎翻页搜寻的模式。我猜搜索引擎未来大概率会以这种过渡阶段以传统搜索引擎为主，ChatGPT这种instruct-based生成模型为辅，慢慢切换到以ChatGPT生成内容为主，而这个切换节点，很可能取决于大模型训练成本的大幅下降的时间，以此作为转换节点。

来源：知乎 www.zhihu.com
作者：张俊林

【知乎日报】千万用户的选择，做朋友圈里的新鲜事分享大牛。点击下载

Yandex 的搜索引擎使用了 1922 个排名因子

Mon, 30 Jan 2023 20:26:37 CST

Yandex 搜索引擎等服务的源代码最近被前雇员泄露，SEO 们立即展开了分析，发现它的搜索排名算法使用了 1922 个排名因子。Yandex 不是 Google，它使用的排名因子 Google 未必使用，或者 Google 使用了但权重不同。尽管如此，Yandex 和 Google 的排名因子肯定有很多相似之处。Yandex 的排名因子包括 PageRank 和链接相关因子，文本相关性，内容年龄和新鲜度，终端用户行为信号，主机可靠性，维基百科等网站高优先度，等等。

美团外卖搜索基于Elasticsearch的优化实践

Fri, 18 Nov 2022 15:52:59 CST

美团外卖搜索工程团队在Elasticsearch的优化实践中，基于Location-Based Service（LBS）业务场景对Elasticsearch的查询性能进行优化。该优化基于Run-Length Encoding（RLE）设计了一款高效的倒排索引结构，使检索耗时（TP99）降低了84%。本文从问题分析、技术选型、优化方案等方面进行阐述，并给出最终灰度验证的结论。

1. 前言

最近十年，Elasticsearch 已经成为了最受欢迎的开源检索引擎，其作为离线数仓、近线检索、B端检索的经典基建，已沉淀了大量的实践案例及优化总结。然而在高并发、高可用、大数据量的 C 端场景，目前可参考的资料并不多。因此，我们希望通过分享在外卖搜索场景下的优化实践，能为大家提供 Elasticsearch 优化思路上的一些借鉴。

美团在外卖搜索业务场景中大规模地使用了 Elasticsearch 作为底层检索引擎。其在过去几年很好地支持了外卖每天十亿以上的检索流量。然而随着供给与数据量的急剧增长，业务检索耗时与 CPU 负载也随之上涨。通过分析我们发现，当前检索的性能热点主要集中在倒排链的检索与合并流程中。针对这个问题，我们基于 Run-length Encoding（RLE） ^[1] 技术设计实现了一套高效的倒排索引，使倒排链合并时间（TP99）降低了 96%。我们将这一索引能力开发成了一款通用插件集成到 Elasticsearch 中，使得 Elasticsearch 的检索链路时延（TP99）降低了 84%。

2. 背景

当前，外卖搜索业务检索引擎主要为 Elasticsearch，其业务特点是具有较强的 Location Based Service（LBS）依赖，即用户所能点餐的商家，是由商家配送范围决定的。对于每一个商家的配送范围，大多采用多组电子围栏进行配送距离的圈定，一个商家存在多组电子围栏，并且随着业务的变化会动态选择不同的配送范围，电子围栏示意图如下：

考虑到商家配送区域动态变更带来的问题，我们没有使用 Geo Polygon ^[2] 的方式进行检索，而是通过上游一组 R-tree 服务判定可配送的商家列表来进行外卖搜索。因此，LBS 场景下的一次商品检索，可以转化为如下的一次 Elasticsearch 搜索请求：

  POST food/_search
{
   "query": {
      "bool": {
         "must":{
            "term": { "spu_name": { "value": "烤鸭"} }
           //...
         },
         "filter":{
           "terms": {
              "wm_poi_id": [1,3,18,27,28,29,...,37465542] // 上万
            }
         }
      }
   }
  //...
}

对于一个通用的检索引擎而言，Terms 检索非常高效，平均到每个 Term 查询耗时不到0.001 ms。因此在早期时，这一套架构和检索 DSL 可以很好地支持美团的搜索业务——耗时和资源开销尚在接受范围内。然而随着数据和供给的增长，一些供给丰富区域的附近可配送门店可以达到 20000~30000 家，这导致性能与资源问题逐渐凸显。这种万级别的 Terms 检索的性能与耗时已然无法忽略，仅仅这一句检索就需要 5~10 ms。

3. 挑战及问题

由于 Elasticsearch 在设计上针对海量的索引数据进行优化，在过去的 10 年间，逐步去除了内存支持索引的功能（例如 RAMDirectory 的删除）。为了能够实现超大规模候选集的检索，Elasticsearch/Lucene 对 Term 倒排链的查询流程设计了一套内存与磁盘共同处理的方案。

一次 Terms 检索的流程分为两步：分别检索单个 Term 的倒排链，多个 Term 的倒排链进行合并。

3.1 倒排链查询流程

从内存中的 Term Index 中获取该 Term 所在的 Block 在磁盘上的位置。
从磁盘中将该 Block 的 TermDictionary 读取进内存。
对倒排链存储格式的进行 Decode，生成可用于合并的倒排链。

可以看到，这一查询流程非常复杂且耗时，且各个阶段的复杂度都不容忽视。所有的 Term 在索引中有序存储，通过二分查找找到目标 Term。这个有序的 Term 列表就是 TermDictionary ，二分查找 Term 的时间复杂度为 O(logN) ，其中 N 是 Term 的总数量。Lucene 采用 Finite State Transducer ^[3]（FST）对 TermDictionary 进行编码构建 Term Index。FST 可对 Term 的公共前缀、公共后缀进行拆分保存，大大压缩了 TermDictionary 的体积，提高了内存效率，FST 的检索速度是 O(len(term))，其对于 M 个 Term 的检索复杂度为 O(M * len(term))。

3.2 倒排链合并流程

在经过上述的查询，检索出所有目标 Term 的 Posting List 后，需要对这些 Posting List 求并集（OR 操作）。在 Lucene 的开源实现中，其采用 Bitset 作为倒排链合并的容器，然后遍历所有倒排链中的每一个文档，将其加入 DocIdSet 中。

伪代码如下：

  Input:  termsEnum: 倒排表；termIterator：候选的term
Output: docIdSet : final docs set
for term in termIterator:
  if termsEnum.seekExact(term) != null:
     docs = read_disk()  // 磁盘读取
     docs = decode(docs) // 倒排链的decode流程
     for doc in docs:
        docIdSet.or(doc) //代码实现为DocIdSetBuilder.add。
end for
docIdSet.build()//合并，排序，最终生成DocIdSetBuilder，对应火焰图最后一段。

假设我们有 M 个 Term，每个 Term 对应倒排链的平均长度为 K，那么合并这 M 个倒排链的时间复杂度为：O(K * M + log(K * M))。可以看出倒排链合并的时间复杂度与 Terms 的数量 M 呈线性相关。在我们的场景下，假设一个商家平均有一千个商品，一次搜索请求需要对一万个商家进行检索，那么最终需要合并一千万个商品，即循环执行一千万次，导致这一问题被放大至无法被忽略的程度。

我们也针对当前的系统做了大量的调研及分析，通过美团内部的 JVM Profile 系统得到 CPU 的火焰图，可以看到这一流程在 CPU 热点图中的反映也是如此：无论是查询倒排链、还是读取、合并倒排链都相当消耗资源，并且可以预见的是，在供给越来越多的情况下，这三个阶段的耗时还会持续增长。

可以明确，我们需要针对倒排链查询、倒排链合并这两个问题予以优化。

4. 技术探索与实践

4.1 倒排链查询优化

通常情况下，使用 FST 作为 Term 检索的数据结构，可以在内存开销和计算开销上取得一个很好的平衡，同时支持前缀检索、正则检索等多种多样的检索 Query，然而在我们的场景之下，FST 带来的计算开销无法被忽视。

考虑到在外卖搜索场景有以下几个特性：

Term 的数据类型为 long 类型。
无范围检索，均为完全匹配。
无前缀匹配、模糊查找的需求，不需要使用前缀树相关的特性。
候选数量可控，每个商家的商品数量较多，即 Term 规模可预期，内存可以承载这个数量级的数据。

因此在我们的应用场景中使用空间换取时间是值得的。

对于 Term 查询的热点：可替换 FST 的实现以减少 CPU 开销，常见的查找数据结构中，哈希表有 O(1) 的查询复杂度，将 Term 查找转变为对哈希表的一次查询。

对于哈希表的选取，我们主要选择了常见的 HashMap 和 LongObjectHashMap。

我们主要对比了 FST、HashMap 和 LongObjectHashMap（哈希表的一种高性能实现）的空间和时间效率。

在内存占用上：FST 的内存效率极佳。而 HashMap/LongObjectHashMap 都有明显的劣势；
在查询时间上：FST 的查询复杂度在 O (len(term))，而 Hash/LongObjectHashMap 有着 O(1) 的查询性能；

注：检索类型虽然为 Long，但是我们将底层存储格式进行了调整，没有使用开源的 BKD Tree 实现，使用 FST 结构，仅与 FST 进行对比。BKD Tree 在大批量整数 terms 的场景下劣势更为明显。

我们使用十万个 <Long, Long> 的键值对来构造数据，对其空间及性能进行了对比，结果如下：

	内存占用	10 万个 Key 的查询时间
FST	481kB	63ms
HashMap	9048kB	3.5ms
LongObjectHashMap	5545kB	1ms
结论	FST >> LongObjectHashMap > HashMap	LongObjectHashMap > HashMap >> FST

可以看到，在内存占用上 FST 要远优于 LongObjectHashMap 和 HashMap。而在查询速度上 LongObjectHashMap 最优。

我们最终选择了 LongObjectHashMap 作为倒排链查询的数据结构。

4.2 倒排链合并

基于上述问题，我们需要解决两个明显的 CPU 热点问题：倒排链读取 & 倒排链合并。我们需要选择合适的数据结构缓存倒排链，不再执行磁盘 /page cache 的 IO。数据结构需要必须满足以下条件：

支持批量 Merge，减少倒排链 Merge 耗时。
内存占用少，需要处理千万数量级的倒排链。

在给出具体的解决方案之前，先介绍一下 Lucene 对于倒排合并的原生实现、RoaringBitMap、Index Sorting。

4.2.1 原生实现

Lucene在不同场景上使用了不同的倒排格式，提高整体的效率（空间/时间），通过火焰图可以发现，在我们的场景上，TermInSetQuery 的倒排合并逻辑开销最大。

TermInSetQuery 的倒排链合并操作分为两个步骤：倒排链读取和合并。

倒排链读取：

Lucene 倒排链压缩存储在索引文件中，倒排链读取需要实时解析，其对外暴露的 API 为迭代器结构。
倒排链合并：

倒排链合并主要由 DocIdSetBuilder 合并生成倒排链，先使用稀疏结构存储 Doc ID，当 Doc ID 个数超过一定阈值时，升级到稠密结构（FixedBitSet）存储，实现方式如下（对应代码 IntArrayDocIdSet/BitDocIdSet）：
- 稀疏数据：存储采用 List<int[]> array 方式存储 Doc ID，最终经过 Merge 和排序形成一个有序数组 int[]，耗时主要集中在数组申请和排序。
- 稠密数据：基于 long[] 实现的 bitmap 结构（FixedBitSet），耗时主要集中在 FixedBitSet 的插入过程，由于倒排链需要实时 Decode 以及 FixedBitSet 的底层实现，无法实现批量 Merge，只能循环单个 Doc ID 插入，数据量大的情况下，耗时明显。

我们采用线上流量和数据压测发现该部分平均耗时约 7 ms。

4.2.2 RoaringBitmap

当前 Elasticsearch 选择 RoaringBitMap 做为 Query Cache 的底层数据结构缓存倒排链，加快查询速率。

RoaringBitmap 是一种压缩的位图，相较于常规的压缩位图能提供更好的压缩，在稀疏数据的场景下空间更有优势。以存放 Integer 为例，Roaring Bitmap 会对存入的数据进行分桶，每个桶都有自己对应的 Container。在存入一个32位的整数时，它会把整数划分为高 16 位和低 16 位，其中高 16 位决定该数据需要被分至哪个桶，我们只需要存储这个数据剩余的低 16 位，将低 16 位存储到 Container 中，若当前桶不存在数据，直接存储 null 节省空间。 RoaringBitmap有不同的实现方式，下面以 Lucene 实现（RoaringDocIdSet）进行详细讲解：

如原理图中所示，RoaringBitmap 中存在两种不同的 Container：Bitmap Container 和 Array Container。

这两种 Container 分别对应不同的数据场景——若一个 Container 中的数据量小于 4096 个时，使用 Array Container 来存储。当 Array Container 中存放的数据量大于 4096 时，Roaring Bitmap 会将 Array Container 转为 Bitmap Container。即 Array Container 用于存放稀疏数据，而 Bitmap Container 用于存放稠密数据，这样做是为了充分利用空间。下图给出了随着容量增长 Array Container 和 Bitmap Container 的空间占用对比图，当元素个数达到 4096 后（每个元素占用 16 bit ），Array Container 的空间要大于 Bitmap Container。

备注：Roaring Bitmap 可参考官方博客 ^[4]。

4.2.3 Index Sorting

Elasticsearch 从 6.0 版本开始支持 Index Sorting ^[5] 功能，在索引阶段可以配置多个字段进行排序，调整索引数据组织方式，可以调整文档所对应的 Doc ID。以 city_id，poi_id 为例：

如上示例所示：Index Sorting 会将给定的排序字段（如上图的 city_id 字段）的文档排序在一起，相同排序值的文档的 Doc ID 严格自增，对该字段建立倒排，那么其倒排链为自增数列。

4.3 基于 RLE 的倒排格式设计

基于以上的背景知识以及当前 Elasticsearch/Lucene 的解决方案，可以明确目前有 2 个改造点需要考虑。

合适的倒排结构，用于存储每个 Term 的倒排链。
合适的中间结构，用于存储多个 Term 合并后的倒排链。

对于索引倒排格式 PostingsEnum，支持接口为：

  public abstract class DocIdSetIterator {
  public abstract int docID();
  public abstract int nextDoc();
  public abstract int advance(int target);
}

倒排仅支持单文档循环调用，不支持批量读取，因此需要为倒排增加批量顺序读取的功能。

对于多倒排链的合并，由于原结构 DocIdSetBuilder 的实现也不支持批量对数据进行合并，我们探索了评估了 Elasticsearch 用于缓存 Query Cache 的数据结构 RoaringBitMap，然而其实现 RoaringDocIdSet 也无法满足我们对缓存数据结构特性需求，主要问题：

原生 RoaringDocIdSet 在构建时，只能支持递增的添加 Doc ID。而在实际生产中每一个商家的商品的 Doc ID 都是离散的。这就限制了其使用范围。
原生 RoaringDocIdSet 的底层存储结构 Bitmap Container 和 Array Container 均不支持批量合并，这就无法满足我们对倒排链合并进行优化的需求。

在明确这个问题的场景下，我们可以考虑最简单的改造，支持索引倒排格式 PostingsEnum 的批量读取。并考虑了如下几种场景：

在支持批量读取倒排的情况下，直接使用原结构 DocIdSetBuilder 进行批量的合并。
在支持批量读取倒排的情况下，使用 RoaringBitMap 进行批量合并。

然而我们发现即使对 bitset 进行分段合并，直接对数据成段进行 OR 操作，整体开销下降并不明显。其原因主要在于：对于读取的批量结果，均为稀疏分布的 Doc ID，仅减少倒排的循环调用无法解决性能开销问题。

那么问题需要转化为如何解决 Doc ID 分布稀疏的问题。在上文提及的 Index Sorting 即一个绝佳的解决方案。并且由于业务 LBS 的特点，一次检索的全部结果集均集中在某个地理位置附近，以及我们检索仅针对门店列表 ID 的特殊场景，我们最终选择对城市 ID、 Geohash、门店 ID 进行排序，从而让稀疏分布的 Doc ID 形成连续分布。在这样的排序规则应用之后，我们得到了一组绝佳的特性：每一个商家所对应的商品，其 Doc ID 完全连续。

4.3.1 Run-Length Encoding

Run-Length Encoding ^[3]（RLE）技术诞生于50年前，最早应用于连续的文本压缩及图像压缩。在 2014 年，第一个开源在 GitHub 的 RoaringBitmap 诞生 ^[6]，2016年，在 RoaringBitMap 的基础上增加了对于自增序列的 RLE 实现 ^[7]，并应用在 bitmap 这一场景上。

在 bitmap 这一场景之下，主要通过压缩连续区间的稠密数据，节省内存开销。以数组 [1, 2, 3, ..., 59, 60, 89, 90, 91, ..., 99, 100] 为例（如下图上半部分）：使用 RLE 编码之后就变为 [1, 60, 89, 12]——形如 [start1, length1, start2, length2, ...] 的形式，其中第一位为连续数字的起始值，第二位为其长度。

在数组完全连续场景下中，对 32768 个 id (short) 进行存储，数组存储需要 64 kB，Bitmap 存储需要使用 4 kB，而 RLE 编码后直接存储仅需要 4 byte。在这一特性下，如果商家倒排链完全有序，那么商家的倒排链，可被压缩到最低仅需要两个整数即可表示。

当然 RLE 并不适用所有情况，在目标序列完全不连续的场景下，如 [1, 3, 5, 7, ... , M]，RLE 编码存储需要使用 2 * M byte的空间，比数组直接存储的空间效率差一倍。

为了和 Elasticsearch 的实现保持一致，我们决定使用 RoaringBitMap 作为倒排存储的结构，以及中间结果合并的数据结构。针对 RoaringDocIdSet 我们进行了如下改造。

4.3.2 RLE Container 的实现

在对商家 ID 字段开启 Index Sorting 之后，同商家的商品 ID 已经连续分布。那么对于商家字段的倒排链就是严格自增且无空洞的整数序列。我们采用RLE编码对倒排链进行编码存储。由于将倒排链编码为 [start1, length1, start2, length2, ...]，更特殊的，在我们场景下，一个倒排链的表示为 [start, length]，RLE编码做到了对倒排链的极致压缩，假设倒排链为 [1, 2, ...., 1000]，用 ArrayContainer 存储，内存空间占用为 16 bit * 100 = 200 Byte, RLE 编码存储只需要 16 bit * 2 = 4 Byte。考虑到具体的场景分布，以及其他场景可能存在多段有序倒排的情况，我们最终选择了 [start1, length1, start2, length2, ...] 这样的存储格式，且 [start, start + length] 之间两两互不重叠。

对于多个商家的倒排合并流程，对于该格式的合并，我们并不需要对 M 个倒排链长度为 K 进行循环处理，这个问题转变为：如何对多组分段 [start, length] 进行排序，并将排序后的结果合并为一个数组。那么我们将原时间复杂度为 $O(K * M + log(K * M))$ 的合并流程，改造为复杂度为 O(M * logM) 的合并流程，大大降低了合并的计算耗时，减少了 CPU 的消耗。

4.3.3 SparseRoaringDocIdSet 实现

我们在 RoaringDocIdSet 的基础上增加了 RLE Container 后，性能已经得到了明显的提升，加速了 50%，然而依然不符合我们的预期。我们通过对倒排链的数据分析发现：倒排链的平均长度不大，基本在十万内。但是其取值范围广 [ 0, Integer.MAX-1 ]。这些特征说明，如果以 RoaringDocIdSet 按高 16 位进行分桶的话，大部分数据将集中在其中连续的几个桶中。

在 Elasticsearch 场景上，由于无法预估数据分布，RoaringDocIdSet 在申请 bucket 容器的数组时，会根据当前 Segment 中的最大 Doc ID 来申请，计算公式为：(maxDoc + (1 << 16) - 1) >>> 16。这种方式可以避免每次均按照 Integer.MAX-1 来创建容器带来的无谓开销。然而，当倒排链数量偏少且分布集中时，这种方式依然无法避免大量 bucket 被空置的空间浪费；另一方面，在对倒排链进行合并时，这些空置的 bucket 也会参与到遍历中，即使它被置为了空。这就又造成了性能上的浪费。我们通过压测评估证实了这一推理，即空置的 bucket 在合并时也会占用大量的 CPU 资源。

针对这一问题，我们设计了一套用于稀疏数据的方案，实现了 SparseRoaringDocIdSet，同时保持接口与 RoaringDocIdSet 一致，可在各场景下进行复用，其结构如下：

  class SparseRoaringDocIdSet {
   int[] index;// 记录有 container 的 bucket Index
   Container[] denseSets;// 记录紧密排列的倒排链
}

保存倒排链的过程与 RoaringDocIDSet 保持一致，在确认具体的 Container 的分桶时，我们额外使用一组索引记录所有有值的 bucket 的 location。

下图是一组分别使用 RLE based RoaringDocIdSet 和 SparseRoaringDocIdSet 对 [846710, 100, 936858, 110] 倒排链（RLE 编码）进行存储的示意图：

可以看到：在 SparseRoaringDocIdSet 实现下，所有不为空的 bucket 被紧密的排列在了一起，并在 index [] 中记录了其原始 bucket 的索引，这就避免了大量 bucket 被空置的情况。另外，在进行倒排链的合并时，就可以直接对紧密排列的 denseSet 进行遍历，并从 index [] 获得其对应的原始 bucket location，这就避免了大量的空置 bucket 在合并时带来的性能浪费。

我们分别对以下4个场景进行了压测：原生的 TermInSetQuery 对倒排链的合并逻辑、基于 FixedBitSet 的批量合并、RLE based RoaringBitmap、RLE based Dense RoaringBitmap。对 10000 个平均长度为 100 的倒排链进行合并压测，压测结果如下：

我们实现的 RLE based Dense RoaringBitmap，相比官方的基准实现耗时降低了 96%（TP99 13 ms 下降至 0.5 ms）。

4.4 功能集成

至此，核心的倒排索引问题已经解决，后续主要为工程问题：如何在 Elasticsearch 系统中集成基于 RLE 的倒排格式。对于高吞吐高并发的C端在线场景，我们希望尽可能保障线上的稳定，对开源数据格式的兼容，保障前向的兼容，做到随时可降级。

工程部分主要分为两部分：倒排索引的集成和在线检索链路。以下主要介绍全量索引部分的链路设计。

4.4.1 倒排索引集成

倒排索引格式的改造，一般情况下，需要实现一套 PostingsFormat，并实现对应的 Reader、Writer。为了保证对原有检索语句的兼容，支持多种场景的检索，以及为了未来能够无缝的配合 Elasticsearch 的版本升级，我们并没有选择直接实现一组新的 PostingsFormat，避免出现不兼容的情况导致无法升级版本。我们选择了基于现有的倒排格式，在服务加载前后初始化 RLE 倒排，并考虑到业务场景，我们决定将 RLE 倒排全量放入内存中，以达到极致的性能。具体的解决方案为：

索引加载过程中增加一组 Hook，用于获取现有的 InternalEngine（ Elasticsearch中负责索引增删改查的主要对象）。
对所有的 semgents 遍历读取数据，解析倒排数据。
对所有配置了 RLE 倒排优化的字段，生成 RLE 倒排表。
将 RLE 倒排表与 segment 做关联，保证后续的检索链路中能获取到倒排表。

为了避免内存泄漏，我们也将索引删除，segment 变更的场景进行了相应的处理。

4.4.2 在线检索链路

在线检索链路也采用了无侵入兼容的实现，我们实现了一套新的检索语句，并且在索引无 RLE 倒排的情况下，可以降级回原生的检索类型，更加安全。

我们基于 Elasticsearch 的插件机制，生成一组新的 Query，实现了其 AbstractQueryBuilder，实现对 Query 的解析与改写，并将 Query 与 RLE 倒排进行关联，我们通过改写具体的检索实现，将整个链路集成到 Elasticsearch 中。

5. 性能收益

对于 Elasticsearch 而言，一次检索分为这么几个阶段，可参考下图 ^[8]。

由协调节点进行请求的分发，发送到各个检索节点上。
每个数据节点的各自进行检索，并返回检索结果给协调节点，这一段各个数据节点的耗时即“数据节点查询耗时”。
协调节点等待所有数据节点的返回，协调节点选取 Top K 后进行 fetch 操作。1～3 步的完整耗时为“完整链路查询耗时”。

我们将上述改动（Index Sorting + Dense Roaring Bitmap + RLE）上线到生产环境的商品索引后，性能如下：

至此，我们成功将全链路的检索时延（TP99）降低了 84%（100 ms 下降至 16 ms），解决了外卖搜索的检索耗时问题，并且线上服务的 CPU 也大大降低。

6. 总结与展望

本文主要针对搜索业务场景中遇到的问题，进行问题分析、技术选型、压测、选择合适的解决方案、集成、灰度验证。我们最终实现了一套基于 RLE 倒排格式，作为一种新型的倒排格式，彻底解决了这个场景上的性能瓶颈，从分析至上线的流程长达数月。本文希望能提供一个思路，让其他同学在遇到 Elasticsearch 相关的性能问题时，也能遵循相同的路径，解决业务上的问题。

一般的，我们分析问题可以遵循这样的路径：

明确性能问题后，首先通过流量录制，获得一个用于后续基准压测的测试集合。
通过相关的性能分析工具，先明确是否存在 CPU 的热点或 IO 问题，对于 Java 技术栈，有很多常见的可用于分析性能的工具，美团内部有 Scaple 分析工具，外部可以使用 JProfiler、Java Flight Recorder、Async Profiler、Arthas、perf 这些工具。
对分析火焰图进行分析，配合源代码，进行数据分析和验证。
此外在 Elasticsearch 中还可以通过 Kibana 的 Search Profiler 用于协助定位问题。在录制大量的流量，抽样分析后，以我们的场景为例，进行 Profiler 后可以明确 TermInSetQuery 占用了一半以上的耗时。
明确问题后从索引、检索链路两侧进行分析，评估问题，进行多种解决方案的设计与尝试，通过 Java Microbenchmark Harness（JMH）代码基准测试工具，验证解决方案的有效性。
集成验证最终效果。

我们最终实现的关键点：

使用哈希表来实现索引 Term 的精确查找，以此减少倒排链的查询与读取的时间。
选取 RoaringBitmap 作为存储倒排链的数据结构，并与 RLE Container 相结合，实现对倒排链的压缩存储。当然，最重要的是，RLE 编码将倒排链的合并问题转换成了排序问题，实现了批量合并，从而大幅度减少了合并的性能消耗。

当然，我们的方案也还具有一些可以继续探索优化的地方。我们进行具体方案开发的时候，主要考虑解决我们特定场景的问题，做了一些定制化，以取得最大的性能收益。在一些更通用的场景上，也可以通过 RLE 倒排获得收益，例如根据数据的分布，自动选择 bitmap/array/RLE 容器，支持倒排链重叠的情况下的数据合并。

我们在发现也有论文与我们的想法不谋而合，有兴趣了解可以参考具体论文 ^[9]。另外，在增量索引场景下，如果增量索引的变更量非常大，那么势必会遇到频繁更新内存 RLE 倒排的情况，这对内存和性能的消耗都不小，基于性能的考量，也可以直接将 RLE 倒排索引的结构固化到文件中，即在写索引时就完成对倒排链的编码，这样就能避免这一问题。

7. 作者简介

泽钰、张聪、晓鹏等，均来自美团到家事业群/搜索推荐技术部-搜索工程团队。

8. 参考文献

[1] https://en.wikipedia.org/wiki/Run-length_encoding

[2] https://www.elastic.co/guide/en/elasticsearch/reference/7.10/query-dsl-geo-polygon-query.html

[3] https://en.wikipedia.org/wiki/Finite-state_transducer

[4] Frame of Reference and Roaring Bitmaps

[5] https://www.elastic.co/cn/blog/index-sorting-elasticsearch-6-0

[6] Chambi S, Lemire D, Kaser O, et al. Better bitmap performance with roaring bitmaps[J]. Software: practice and experience, 2016, 46(5): 709-719.

[7] Lemire D, Ssi‐Yan‐Kai G, Kaser O. Consistently faster and smaller compressed bitmaps with roaring[J]. Software: Practice and Experience, 2016, 46(11): 1547-1569.

[8] 检索两阶段流程：https://www.elastic.co/guide/cn/elasticsearch/guide/current/_fetch_phase.html#_fetch_phase

[9] Arroyuelo D, González S, Oyarzún M, et al. Document identifier reassignment and run-length-compressed inverted indexes for improved search performance[C]//Proceedings of the 36th international ACM SIGIR conference on Research and development in information retrieval. 2013: 173-182.

阅读美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 安全 | 运维 | iOS | Android | 测试

| 在公众号菜单栏对话框回复【2021年货】、【2020年货】、【2019年货】、【2018年货】、【2017年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者使用。任何商用行为，请发送邮件至tech@meituan.com申请授权。

✨基于Spring-Data-Elasticsearch 优雅的实现多字段搜索 + 高亮 + 分页 + 数据同步✨

Sun, 16 Oct 2022 15:13:47 CST

theme: devui-blue highlight: a11y-dark

持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第17天，点击查看活动详情

系列说明

本系列文章基于我的开源微服务项目【校园博客】进行分析和讲解，所有源码均可在GitHub仓库上找到。系列文章地址请见我的校园博客专栏。

GitHub地址： https://github.com/stick-i/scblogs

目前项目还有很大改进和完善的空间，欢迎各位有意愿的同学参与项目贡献（尤其前端），一起学习一起进步。

项目的技术栈主要是：
后端 Java + SpringBoot + SpringCloud + Nacos + Getaway + Fegin + MybatisPlus + MySQL + Redis + ES + RabbitMQ + Minio + 七牛云OSS + Jenkins + Docker
前端 Vue + ElementUI + Axios（说实话前端我不太清楚）

前言

本篇文章主要是一些对Spring-Data-Elasticsearch使用上的记录和讲解，对原理和基础知识并没有介绍，适合有一定ES基础的朋友阅读。

为了给项目添加一个好的搜索功能，我去学习了一下elasticsearch。

在学习elasticsearch-client的期间，发现它提供的api不太优雅，用起来也不太舒服，而且我觉得有些操作完全是可以封装在内部的，比如获取数据后，对数据转化为bean的操作；还有属性高亮，不仅设置比较麻烦，而且设置完成的高亮居然是单独在一个字段里的，需要开发者去手动的替换才行，这些操作我觉得其实都可以封装在内部的，害，个人感慨，请勿介意。

然后我就去看了一下spring-data里面提供的 es 操作库，发现有很多操作都封装的比较完善，使用起来也比较优雅，于是我便使用spring-data-elasticsearch完成了这个功能，查阅了很多资料、博客、官方文档，有些地方我觉得官方文档讲的也不够详细，导致走了很多弯路，也可能是我没有找到详细的文档。

为了方便大家学习和少走弯路，也便于本人日后回顾，故记录于此。

本篇文章讲的内容是在项目的 /blog-service/blog-content-server 路径下，感兴趣的同学欢迎随时查看，觉得不错的话也欢迎点点star噢。

技术要点

使用 copyTo 和 ElasticsearchRepository 完成的多字段搜索。
使用注解 @Highlight 和 @HighlightField 完成的高亮显示。
使用 Pageable 和 SearchPage 实现分页和高亮两不误的接口。
使用 RabbitMQ 完成 MySQL 和 elasticsearch 的数据同步。

依赖项

我当前的环境：

springboot 2.6.6
elasticsearch 7.12
kibana 7.12（这个不是必须的）
然后当前版本的spring默认是用的 7.15.2 的我担心和我的es不兼容，就加了个标签给它改了一下版本：
```
    <elasticsearch.version>7.12.1</elasticsearch.version>
```

核心依赖其实就这一个，这里面已经依赖了elasticsearch需要的一些依赖，例如 elasticsearch-rest-high=level-client。

  <dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-elasticsearch</artifactId>
</dependency>

然后如果跟我一样使用 RabbitMQ 做数据同步的话，还需要引用mq的依赖：

  <!--AMQP依赖，包含RabbitMQ-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>
<!-- json序列化依赖，需要手动配置bean -->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>

配置文件

这里需要配置elasticsearch的账号密码

  spring:
  elasticsearch:
    uris: "http://localhost:9200"
    username: 12345
    password: 12345

核心代码

实体类BlogDoc

下面是我代码当中跟 es 进行交互的实体类，代码上有相关的注释，我将一些多余的、意义不大的属性删掉了，方便大家查看。

  package cn.sticki.blog.content.pojo;

import com.fasterxml.jackson.annotation.JsonIgnore;
import lombok.Data;
import org.springframework.data.annotation.Id;
import org.springframework.data.elasticsearch.annotations.Document;
import org.springframework.data.elasticsearch.annotations.Field;
import org.springframework.data.elasticsearch.annotations.FieldType;

import java.util.Date;

/**
 * Blog ES文档类型
 *
 * @author 阿杆
 * @version 1.0
 * @date 2022/7/8 15:24
 */
@Data
@Document(indexName = "blog")
public class BlogDoc {

/**
 * 博客id
 */
@Id
Integer id;

/**
 * 封面图链接
 */
@Field(type = FieldType.Keyword, index = false)
String coverImage;

/**
 * 标题
 */
@Field(type = FieldType.Text, analyzer = "ik_max_word", copyTo = "descriptiveContent")
String title;

/**
 * 描述
 */
@Field(type = FieldType.Text, analyzer = "ik_max_word", copyTo = "descriptiveContent")
String description;

/**
 * 创建时间
 */
@Field(type = FieldType.Date, pattern = "uuuu-MM-dd HH:mm:ss")
Date createTime;

/**
 * 发表状态（1表示已发表、2表示未发表、3为仅自己可见、4为回收站、5为审核中）
 */
@Field(type = FieldType.Integer)
Integer status;

/**
 * 由其他属性copy而来，主要用于搜索功能，不需要储存数据
 */
@JsonIgnore
@Field(type = FieldType.Text, analyzer = "ik_max_word", ignoreFields = "descriptiveContent", excludeFromSource = true)
String descriptiveContent;

}

注解说明：

@Document(indexName = "blog")：声明该实体类对应es中的哪个 索引库。
@Id：声明该字段对应索引库当中的id。
@JsonIgnore：这个应该很熟悉吧，就是 在json序列化时将对象中的一些属性忽略掉，使返回的json数据不包含该属性。
@Field(...) ，这些其实都 对应es的api调用时传入的字段，有一点es基础会很容易看懂，也可以看看我写的elasticsearch专栏下的其他文章，前几篇是我学基础的时候记录的。
- type = FieldType.Integer ：声明字段属性，如果不写，默认为auto，就是es会帮你自动匹配成最合适的字段类型，建议还是写一下。
- index = false ：声明该字段不需要建立索引，一般用于不会被拿来搜索、排序、统计的字段，比如我这里写的封面图链接。
- analyzer = "ik_max_word" ：声明该text字段需要使用的分词器，我这里是用的ik分词器，需要开发者去手动安装，但对中文分词比较友好。
- excludeFromSource = true：翻译出来意思是“从源中排除”，应该是指这个字段的属性不会插入到es索引库当中吧，这个字段是我用来``copy_to`的，主要是搜索的时候使用，本身并不会直接存入数据，所以这个字段如果有数据，我希望插入的时候把它忽略。
- copyTo = "descriptiveContent"：这个就是跟es的copy_to一样，就是说把当前属性拷贝到“descriptiveContent”当中，可以拷贝多个属性到同一个字段中，便于搜索、查询。
- pattern = "uuuu-MM-dd HH:mm:ss" ：声明该自定义的格式字符串，一般在type = FieldType.Date时使用。
- format：跟pattern差不多，官方解释是用于定义至少一种预定义格式。如果未定义，则使用默认值*_date_optional_time 和epoch_millis*。也就是只能使用给定的枚举值，不能自定义，自定义的话得用pattern。下图是谷歌翻译的官方解释：

实体类属性copy_to

大家都知道，在es当中如果有多个字段需要被同时查询（比如我的博客业务，要搜索内容的时候，我会把用户输入的关键字同时拿来匹配标题和文章描述），那可以用 multi_match、 query_string进行多字段查询，也可以用 copy_to将多个字段复制到一个新属性上再去查新属性，这几种方法都是可以的，但是copy_to它的性能会高一些，尤其是在同时要查的属性非常多的时候，这属于是一种储存换取速度的方式。

copy_to的属性在上面已经讲过了，跟es的api用来起来差不多的，但是我上面的代码还写了一个 descriptiveContent：

  /**
 * 由其他属性copy而来，主要用于搜索功能，不需要储存数据
 */
@JsonIgnore
@Field(type = FieldType.Text, analyzer = "ik_max_word", ignoreFields = "descriptiveContent", excludeFromSource = true)
String descriptiveContent;

这个属性就是被cope_to到的那个属性，但实际上我们在写代码的时候并不会给它赋值或者取值或者别的怎么样，总是就是希望他尽可能透明，仅在对es时有效，因为es里是已经提前定义好这个索引库了的，es创建索引库的代码我会贴在文章最后。

这是因为，后面我们要使用 ElasticsearchRepository的时候，被查询的字段如果不存在于这个实体类，idea会有一个很碍眼的提示， ~~作为强迫症患者~~，这就引发了我的思考，是不是我们在定义实体类的时候，要和定义索引库的时候一样给出全部的字段呢？尽管这个字段只是一个“隐身”的字段。 ~~为了把这个碍眼的提示去掉~~ 为了让代码变得更可读一点，所以我加上了这个字段，并加了一些忽略的属性使它尽可能隐身。

Mapper层（Repository）

核心代码如下，具体解释和分析在下面：

  package cn.sticki.blog.content.mapper;

import cn.sticki.blog.content.pojo.BlogDoc;
import org.springframework.data.domain.Pageable;
import org.springframework.data.elasticsearch.annotations.Highlight;
import org.springframework.data.elasticsearch.annotations.HighlightField;
import org.springframework.data.elasticsearch.annotations.HighlightParameters;
import org.springframework.data.elasticsearch.core.SearchPage;
import org.springframework.data.elasticsearch.repository.ElasticsearchRepository;

/**
 * BlogRepository操作类
 * 提供save、findById、findAll、count、delete、exists等接口
 *
 * @author 阿杆
 * @version 1.0
 * @date 2022/7/9 10:53
 */
public interface BlogRepository extends ElasticsearchRepository<BlogDoc, Long> {

/**
 * 通过描述内容来搜索博客
 *
 * @param descriptiveContent 描述语句
 * @param pageable           分页
 * @return 博客列表
 */
@SuppressWarnings("SpringDataRepositoryMethodReturnTypeInspection")
@Highlight(fields = {
@HighlightField(name = "title", parameters = @HighlightParameters(requireFieldMatch = false)),
@HighlightField(name = "description", parameters = @HighlightParameters(requireFieldMatch = false)),
})
SearchPage<BlogDoc> findByDescriptiveContent(String descriptiveContent, Pageable pageable);

}

继承ElasticsearchRepository

这个其实就有点像继承 BaseMapper，它会给你提供一些基础的CRUD方法，方便你直接使用，比如save、delete、find之类的。
它是个泛型类，两个参数分别是 <实体类，id的类型>。
在该接口下（BlogRepository）按照特殊的命名规则声明的方法，可以直接调用，不需要开发者实现接口，且它返回的内容是已经封装好的， 你需要的数据会被封装在你提供的实体类里面（不用手动解析数据）。

大概就是 findByXxxAndXxxOrXxx() 这个类型，具体的可以参考官网： https://docs.spring.io/spring-data/elasticsearch/docs/4.3.5/reference/html/#elasticsearch.query-methods.criterions，这里也截一点给大家看看（谷歌浏览器翻译的）：
也可以使用 @Query 注解写原生的 api 请求接口，不太优雅，个人不推荐使用。

然后这里我只添加了一个方法：

  SearchPage<BlogDoc> findByDescriptiveContent(String descriptiveContent, Pageable pageable);

这个意思就是所通过 DescriptiveContent 属性来查询数据，后面的两个参数一个是搜索的内容，一个是分页的参数（分页需要配合支持分页的返回值才行）。

这个findByXxx的Xxx属性必须是实体类里面存在的属性才可以，不然会提示错误：

高亮显示

  @SuppressWarnings("SpringDataRepositoryMethodReturnTypeInspection")
@Highlight(fields = {
@HighlightField(name = "title", parameters = @HighlightParameters(requireFieldMatch = false)),
@HighlightField(name = "description", parameters = @HighlightParameters(requireFieldMatch = false)),
})

使用注解 @Highlight 和 @HighlightField，来设置高亮的字段，使用 @HighlightParameters 来添加高亮的参数。

我这里设置了requireFieldMatch = false，这个参数是 取消只有字段匹配才给高亮的规则，这是因为我搜索的字段是由另外两个字符copyTo而来的，高亮的内容肯定是在另外两个字段里面，设置该参数可以让其他字段的高亮也展示出来。

这里还有一篇高亮显示的教程文章，我讲的比较粗糙，他这个写的比较详细，贴给大家学习： https://blog.csdn.net/qq_45794678/article/details/111188548

官方文档给的说明就这么点。。。 ~~怕我学会了然后教别人吗~~。。。

分页功能

通过 Pageable 做参数和 SearchPage 做返回值来完成了对分页的需求，传参的时候使用 PageRequest.of(page, size) 来创建分页参数即可。

得到结果后仅需将分页的内容替换掉实体类的内容即可，并且数据里面包含有获取页码的信息的接口：

Service层

核心代码如下：

  @Service
public class BlogContentServiceImpl implements BlogContentService {

@Resource
private BlogRepository blogRepository;

/**
 * 搜索博客
 *
 * @param key 搜索内容
 * @param page 页码
 * @param size 页大小
 * @return 搜索到的结果列表
 */
@Override
public List<BlogDoc> searchBlog(String key, int page, int size) {
// 1. 获取数据
SearchPage<BlogDoc> searchPage = blogRepository.findByDescriptiveContent(
// 1.1 设置key和分页，这里是从第0页开始的，所以要-1
key,PageRequest.of(page - 1, size));
// 2. 高亮数据替换
List<SearchHit<BlogDoc>> searchHitList = searchPage.getContent();
ArrayList<BlogDoc> blogDocList = new ArrayList<>(searchHitList.size());
for (SearchHit<BlogDoc> blogHit : searchHitList) {
// 2.1 获取博客数据
BlogDoc blogDoc = blogHit.getContent();
// 2.2 获取高亮数据
Map<String, List<String>> fields = blogHit.getHighlightFields();
if (fields.size() > 0) {
// 2.3 通过反射，将高亮数据替换到原来的博客数据中
BeanMap beanMap = BeanMap.create(blogDoc);
for (String name : fields.keySet()) {
beanMap.put(name, fields.get(name).get(0));
}
}
// 2.4 博客数据插入列表
blogDocList.add(blogDoc);
}
return blogDocList;
}

}

替换高亮数据

到这里其实就只要做一件事了，因为Repository返回的数据已经帮你封装好实体类了，不需要再去json转bean了，它唯一的缺点就是，高亮数据还是得自己去做替换，所以我上面这些代码也就是做了这一件事，就是把高亮的数据替换掉原来的数据。

这里我用到了 BeanMap，代码里不用写死属性名称，相对来说更优雅一点，如果有需要的话，也可以把中间这一段分离成一个单独的方法，可以提供给不同的类使用。

数据同步

数据同步指的是 elasticsearch 和 MySQL 的数据同步，由于我的项目做的是微服务架构，我的 博客服务和 博客内容服务是两个微服务（本文讲的是博客内容服务），博客服务提供文章的 增删改查功能，并连接MySQL，博客内容服务提供 搜索功能，并连接ES，故两者的数据需要同步。

这里我使用的是RabbitMQ，主要逻辑如下：

用户新建修改或删除博客时，博客服务发送消息到MQ中，发到自己的交换机里，并指定key。
内容服务提前创建队列并绑定到博客服务的交换机中。
当内容服务接收到消息时，做出对应的操作。

核心代码如下：

  /**
 * 内容服务对博客服务的消息队列监听器
 *
 * @author 阿杆
 * @version 1.0
 * @date 2022/7/10 9:32
 */
@Slf4j
@Component
public class BlogServerListener {

@Resource
private BlogRepository blogRepository;

@RabbitListener(bindings = @QueueBinding(
exchange = @Exchange(name = BLOG_EXCHANGE),
value = @Queue(name = BLOG_SAVE_QUEUE),
key = {BLOG_INSERT_KEY, BLOG_UPDATE_KEY}
))
public void saveListener(BlogDoc blogDoc) {
log.debug("save blogDoc，{}", blogDoc);
blogRepository.save(blogDoc);
}

@RabbitListener(bindings = @QueueBinding(
exchange = @Exchange(name = BLOG_EXCHANGE),
value = @Queue(name = BLOG_DELETE_QUEUE),
key = BLOG_DELETE_KEY
))
public void deleteListener(Long blogId) {
log.debug("delete blog ,id->{}", blogId);
blogRepository.deleteById(blogId);
}

}

其实可以看出，通过Repository来实现这些操作都是很简单的。

需要注意的是，这里的save操作，是 ES的全量更新，所以发送过来的数据，一定要是完整的数据，否则会导致部分字段丢失。

然后发送消息的大概就是代码是：

  rabbitTemplate.convertAndSend(BLOG_EXCHANGE, BLOG_UPDATE_KEY, blog);

MQ序列化配置

这里RabbitMQ的序列化配置我也贴一下，这个可以让MQ消息变成json格式的。

  package cn.sticki.common.amqp.autoconfig;

import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
import org.springframework.amqp.support.converter.MessageConverter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * @author 阿杆
 * @version 1.0
 * @date 2022/6/25 18:01
 */
@Configuration
public class AmqpMessageConverterConfig {

@Bean
public MessageConverter messageConverter() {
return new Jackson2JsonMessageConverter();
}

}

后记

本篇文章主要使用了 ElasticsearchRepository 和相关注解来完成了一些常有的需求，比较优雅（个人认为）的实现了查询分页和高亮的功能（网上找到的教程都没有把分页和高亮一起适配的）。但如果有更为复杂的需求，可能还是需要使用 ElasticsearchRestTemplate来完成。官网： https://docs.spring.io/spring-data/elasticsearch/docs/4.3.5/reference/html/#elasticsearch.operations.resttemplate

电商搜索里都有啥？详解闲鱼搜索系统（长文）

Tue, 27 Sep 2022 11:19:54 CST

作者：闲鱼技术——云钟

搜索是电商平台的核心流量入口，承载着平台主要的 成交引导、 意图收敛、 活动投放。一个稳定、高效、可扩展的搜索系统是电商平台得以生存发展的基石。本文探讨如何构建 完善的商品搜索系统，并根据闲鱼二手交易的差异化特性介绍 闲鱼搜索系统的时效性优化。

首先，构建一个搜索系统——电商场景的搜索

搜索引擎

搜索系统的核心是搜索引擎，目前Lucene、ElasticSearch等开源引擎已十分成熟，阿里云也提供完整的搜索解决方案-OpenSearch，包含基于Ha3的搜索引擎（Heaven ask 3）及系列管控工具。这里，我们简单描述下搜索引擎内的基本概念作为导引，不过多深入引擎的具体实现（那将是一个冗长的话题，网络上的资料也随处可见）。

搜索引擎的基本概念

• 分词通过一定规则对文本分出单词，每个单词作为搜索的最小粒度单元。只有单词匹配，文档才能被召回，因此分词的准确是搜索精准的基础。如“红色摩托车” 被分词成“红色”， “摩托车”，那它将被“摩托车”或者“红色”召回，如果分词成“红色摩托”， “车”，那它在引擎中被搜索出的概率就将大打折扣。
• 索引
- • 倒排索引 称为反向索引、置入档案或反向档案，是一种索引方法。被用来存储在全文搜索下 某单词在文档存储位置的映射。它是文档检索系统中最常用的数据结构。
  - • _ 红色苹果手机, doc1_
  - • _ 红色苹果, doc2_
  - • “红色”，“苹果” -> doc1, doc2
  - • _“手机” -> doc1 _
- • 正排索引 也叫attribute索引或者profile索引，是存储doc某特定字段（正排字段）对应值的索引，用来进行过滤、统计、排序或者算分使用。正排索引中“正"指的是从doc-> fieldInfo的过程。
- • 索引内容类型 文本索引、空间索引、向量索引、数值索引
• 排序方法 匹配召回的结果集，通过特定的排序规则呈现。这里的排序规则，可以是单一维度的排序（如按价格、销量、发布时间）；人工设置的权重分；相关性得分；特定场景的模型打分等。

基于这三个基本概念，搜索动作就可以简化地理解为“ 利用搜索词的分词结果，通过倒排索引匹配相应的文档，并依据特定排序方法有序透出”的过程。

搜索引擎仅提供搜索的基础能力，现实环境下的搜索场景当然要复杂的多，一款地图搜索和一款商品搜索所面临的挑战大相径庭。作为原材料的搜索引擎，该打造成何种形状，就看面对问题如何去设计模具了。

以闲鱼为例，搜索系统的整体架构如下：

闲鱼搜索系统架构图

在线服务

上述架构图中的步骤1 ~ 8为一次搜索请求的完整执行流程

1）请求接入模块 -> 应用层

处理客户端或h5请求， 请求接入模块的主要工作： 参数校验、 负载均衡、安全拦截。大部分的非法请求在这一层被拦截，避免进入系统核心模块后，导致不可预期的结果。 应用层承载 面向用户的业务逻辑：实际处理用户的业务请求，进行安全合规检测，同时并行请求投放的各类资源位。

2）应用层 -> 排序接入层

排序接入层是连接应用层与底层引擎的纽带，也是闲鱼搜索系统的最核心模块。他负责解析应用层的搜索请求，并对其进行合适流程编排：意图预测->请求拼串->搜索引擎召回->精排模型打分->重排规则->外部混排。

3）排序接入层 -> 意图预测模块

负责分词并预测搜索请求的实际意图，包括错词改写(例：平果->苹果)、同义词的合并（例：pingguo->苹果），类目预测（例：“苹果”出手机，还是出水果，它们各自的权重又是多少？）。

4）排序接入层 -> 搜索引擎

利用意图预测得到的信息，合并应用层参数，拼装出合法的搜索引擎请求，在搜索引擎内部历经“海选”、“粗排” 、"精排" 三个阶段，得到符合召回条件的商品集。

5）排序接入层 -> 精排模型打分

由于RT的限制，搜索引擎内部无法完成对海量商品复杂度较高的打分计算。这一步的工作，将引擎召回的商品集送入更精准的打分系统进行算分。为什么不把打分服务放在引擎内部？技术上是可行的，但由于打分服务变更频率频繁，而引擎相对稳定，处于系统迭代稳定性的考虑，独立拆分精排打分服务是更好的选择。

6）排序接入层 -> 混排模块

部分业务场景下，合作方有合并混排的诉求。独立拆分混排服务，隔离开发环境，让不熟悉主搜的外部开发同学在独立混排模块内做开发，即使服务异常，也不至于影响闲鱼本身的搜索能力。

7）排序接入层 -> 应用层

排序完成的商品列表，在应用层补充实时信息，如各类标签，促销信息等。同时，将商品搜索结果与广告等各类投放组装层最终的搜索结果页。

8) 应用层 -> 接入层 -> 客户端

将最终的搜索结果页返回到客户端或h5页面进行渲染。

离线模块

与在线服务对应，搜索系统的离线模块负责数据的dump，清洗，索引构建。

搜素引擎离线模块

image.png

全量索引(Fullindex) ：数据源来自多表join后的全量业务数据，包含所有商品信息，由buildSerive构建好索引后提供给Ha3使用，系统内仅有一份全量索引。

批次增量索引 (IncIndex) ：根据周期内（通常30分钟到1小时）数据产出方发送的增量消息（如：商品修改信息），在BuildService上构建成索引段，定期发送给Ha3加载，引擎存在多段批次增量。

实时索引(RtIndex): 将数据产出方实时生产的数据经中转Topic发送至Ha3，由Ha3引擎内的BS lib构建出实时索引加载使用，时效性为实时。在新的批次增量索引加载后，Ha3对实时索引作清理。

稳定性

搜索承载闲鱼导购线的核心流量，因此对系统的稳定性和业务的高可用有极高的要求。闲鱼搜索系统，分别在中心机房(张北)和单元机房（南通）进行了异地多机房部署，确保当单一机房故障时，流量可转发至正常机房服务。

应用层异地多活

image.png

引擎层异地多活

image.png

外围系统

核心链路以外，搜索业务的高效运作也离不开一系列外围系统。

投放系统 —— 资源位与配置的投放

image.png

评测系统 —— 算法标注、效果评测

image.png

Debug平台 —— 可视化的在线debug工具，负责线上请求回放、舆情排查等

image.png

然后，优化它 —— 闲鱼搜索系统时效性优化

差异化场景

上一章节提到的搜索系统架构适用于大部分电商平台，但闲鱼搜索场景与常规电商平台之间，又存在着显著差异。

常规电商平台

闲鱼

库存

多库存

孤品，单库存

商品分层

精品\普通\滞销分级明显

无明显冷热差异，每天有超过50%的商品获得曝光

商品结构

标品、结构化程度高

非标、结构化程度低

算法

基于商品历史信息

多基于统计数据

用户身份

买卖家分离

买卖家重叠程度高

目标

GMV

促成交易量，构建健康二手生态

搜索词

头部Query集中度高

兴趣广泛、Query分散

其中，闲鱼商品 单库存， 无明显冷热差异且 变更频繁的特性，对全链路的 实时处理能力都提出较高的要求。试想一下，热门的商品被买下架后，并没有及时同步引擎。对买家、卖家和平台来说都是一种困扰与损失。

image.png

闲鱼搜索经年累月的业务迭代，累积了相当量级的实时增量。最严重的时期，引擎的增量延时一度达到8小时之久，对用户体验、成交效率形成了巨大冲击。因此过去的一段时间，我们开启了 搜索时效优化的专项。

image.png

Searcher扩列

排查链路实时处理能力的瓶颈，如上文离线模块中对实时增量的描述（数据产出方实时生产的数据经中转Topic实时发送至Ha3，由Ha3引擎内的BS_lib构建出实时索引加载使用），在实时增量到达索引所在searcher列之前都未出现延时，因此瓶颈位于在线searcher的BS_lib的消费能力，最直接的方式是提升searcher的处理能力。因此，我们将searcher的列数从16列扩大至24列，提升了50%的实时增量处理能力，增量延时缓解。

引擎架构治理

我们重新思考了闲鱼主搜引擎的架构与定位。在之前的架构中，倒排、正排、详情字段部署在同个引擎（Ha3引擎支持这种能力）。倒排、正排用作查询索引，详情字段补充商品详细信息，并对外提供信息补全服务。但查询的请求量是极其不对等的，详情字段的qps为索引字段的5.3倍。倒排与正排字段的数量远大于详情字段, 因此查询请求的机器要求是小CPU, 大内存，详情请求的机器则是大CPU，小内存。两类字段部署在同一引擎，各自的资源短板被放大。同时，各字段实时增量是累加的。因此，我们拆分了 查询引擎 与 详情引擎， 缓解增量压力的同时，机器资源消耗也有所降低。

image.png

增量分级

做了以上两个优化后，增量延迟有所缓解，但整体的增量量级并没有下降多少。因此在离线链路中，我们开发了增量Profile插件，用来统计字段修改的频率。

image.png

其中两个字段合计占到修改量的37%（总400+字段），经排查，两个字段并不需要秒级的实时性。 引擎的离线链路中，虽然设定了批次增量与实时增量，但事实上所有开启的增量都会走实时增量通道，挤占优先级更高的增量的吞吐量。因此，进入引擎的增量务必根据业务诉求再做一次分级。由此，我们在buildService上开发了增量分级插件，提供增量分级处理的能力，对于准实时性要求的增量仅做批次增量（1小时进引擎），不挤占核心实时增量的通道，保障商品核心特征的实时性。

image.png

辅表写扩散问题

优化增量量级的另一个重要关注点就是辅表写扩散问题。商品以item_id为主键分列部署，离线阶段，当辅表有驱动增量时，跟主表join后增量翻倍增长。例：商品上挂载用户在线状态的特征，当用户状态变化时，该用户的所有商品都会发出实时增量消息。量级将远大于用户在线状态的实际消息量级。解决方式是将这一类字段，单独改造成在线辅表，通过在线join的方式查询。

image.png

经过以上系列的优化后，我们最终把 引擎延迟抹平，达到真正实时化搜索的定义( 基本无延迟, 红框部分为全量后追增量阶段, 采用逐行Rolling模式, 切换中机器不服务，对用户体验无感知)。

image.png

最后

电商平台的搜索是一项系统性工程，经过多年发展，已沉淀出一套通用性的框架。里面不仅包含对搜索引擎的理解，也体现服务端架构设计的可伸缩、平行扩展等概念。但仅有框架的认知还不足以支撑快节奏的互联网网业务发展。在通用框架的基础上，深刻理解搜索业务，关注稳定性、研发效能，找到应用场景的痛点，有针对性的做出架构调整，才能构建出真正助力业务发展的搜索系统。

欧盟开放 Web 搜索项目启动

Wed, 21 Sep 2022 17:00:10 CST

搜索是数字经济的支柱，但它控制在少数巨头手中。为了实现信息的自由、不带偏见和透明的访问，欧盟 7 个国家 14 个研究和计算中心发起了开放 Web 搜索项目，为欧盟的 Web 搜索构建开放的基础设施。未来三年，研究人员将开发核心的索引 Open Web Index (OWI)。索引将与搜索引擎分开，创建索引的昂贵过程可以在大型集群上完成，而搜索引擎则可以在本地执行。通过 Open-Web-Search Engine Hub，任何人都可以分享其搜索引擎规格和预计算定期更新的索引。最终目标是创造一个以人为中心无隐私问题的搜索。

浅谈有赞搜索QP架构设计

Mon, 05 Sep 2022 13:27:28 CST

一、有赞搜索平台整体设计

在介绍QP前先简单介绍一下搜索平台的整体结构，方便大家快速了解QP在搜索平台中的作用。下图简单展示了一个搜索请求开始到结束的全部流程。业务通过简洁的api接入los，管理员在搜索平台新建配置并下发，完成整个搜索接入，并通过abtest验证QP带来的优化效果。

二、QP的作用

在NLP中，QP被称作Query理解（QueryParser），简单来说就是从词法、句法、语义三个层面对query进行结构化解析。这里query从广义上来说涉及的任务比较多，最常见的就是搜索系统中输入的查询词，也可以是FAQ问答或阅读理解中的问句，又或者可以是人机对话中用户的聊天输入。
在有赞，QP系统专注对查询内容进行结构化解析，整合了有赞NLP能力，提供统一对外接口，与业务逻辑解耦。通过配置化快速满足业务接入需求，同时将算法能力插件化，并支持人工干预插件执行结果。
以精选搜索为例，当用户输入衣服时用户往往想要搜的是衣服类商品，而不是衣服架，衣服配饰等衣服周边用品。通过将衣服类目进行加权，将衣服类的商品排在靠前的位置，优化用户搜索体验。 QP目前应用在新零售，微商城、精选、爱逛买手店、分销市场、帮助中心知识库、官网搜索等场景，通过类目加权，产品词识别，搜索词纠错，同近义词召回提升用户搜索效果。

三、QP应用整体设计

上图完整描述了QP请求流程和配置流程的执行情况。当搜索请求到达QP时，根据请求体中的场景标记获取QP配置。QP配置中包含搜索词位置标记，插件列表，dsl改写脚本等内容。
QP根据配置，按序执行相应插件。插件在执行后，可通过干预配置以及超参数对结果进行人工干预。
QP在获取到算法插件执行结果后，根据改写配置，对搜索dsl进行改写。如将纠错词放置在搜索词同一层级，将dsl改写成fuction score结构进行类目加权。

四、QP应用分层设计

上图按照请求流程从上到下展示了QP的分层设计，接下来将简单描述各层作用：
controller层：查询改写服务入口，对请求做预处理。
service层：根据场景获取QP改写配置，获取dsl里的搜索词，调用相应的插件返回qp结果。
plugin层：负责算法插件执行，调用插件对应的算法实现handler，对算法结果做干预并针对调用成功或者失败做处理。
handler层：算法具体实现放置在该层，该层会依赖各种算法服务（如小盒子，Milvus等）。
Intervener层：负责对handler结果做人工干预。
processor层：根据QP改写配置，调用改写插件，完成dsl的改写。

五、QP算法插件设计

5.1 预处理Preprocess插件

按照配置规则对搜索词进行预处理，预处理方式如下：
* 删除特殊符号 " “ \ 等；
* 大写转小写，全角转半角；
* 连续英文联合切分，连续数字联合切分，其余单独切分；
* 默认截取list前50个字/词；
* 将list拼接成一个字符串。

样例

  输入："史蒂夫新款\时尚套装夏修身圆领百搭钩花DWF镂空雪纺两件套套裙；"
输出："史蒂夫新款时尚套装夏修身圆领百搭钩花dwf镂空雪纺两件套套裙"

5.2 纠错Correction插件

纠错插件的作用是对搜索词中错误内容进行识别，返回正确内容。

样例

  输入：[上海牛黄皂]
输出：[上海硫磺皂]

当用户输入“上海牛黄皂”时，通过纠错插件能正确输出“上海硫磺皂”，其技术架构如下图所示。 1、纠错模型在bert基础上采用知识蒸馏，提升模型精度降低模型时延。
2、根据同音字召回候选集，使用tri-gram语言模型对候选集排序。

5.3 细粒度分词Tokenizer插件（基础分词）

样例

  输入：[雪地靴女2020年新款皮毛一体冬季加绒加厚防滑东北厚底保暖棉鞋子]
输出：[雪地 靴 女 2020 年 新款 皮毛 一体 冬季 加绒 加厚 防滑 东北 厚底 保暖 棉 鞋子]

该分词插件由Java版结巴 jieba-analysis 修改而来，修改内容如下：
* 从全网商品标题数据，有赞行业数据，开源数据中统计出词频，作为基础分词词典；
* 解决词典中由英文单词导致英文字符串被分开的问题；
* 限制DAG的长度，即匹配词的长度，以此控制分词粒度，目前默认是2，分出来的词除英文和数字外，长度不会超过2。

5.4 语义分词sementicSegment插件

样例

  输入：[雪地 靴 女 2020 年 新款 皮毛 一体 冬季 加绒 加厚 防滑 东北 厚底 保暖 棉 鞋子]
输出：[雪地靴 女 2020年 新款 皮毛一体 冬季 加绒加厚 防滑 东北 厚底 保暖 棉鞋子]

该插件在细粒度分词的基础上，通过模型生成语义树将关联度大的词列表进行合并，输出语义分词结果。在样例中，雪地与靴关联度更大，所以在语义分词中将雪地与靴合并输出。

5.5 实体识别Tagging插件

样例

  输入：["汽车","脚垫","刷子"]
输出：[{"word":"汽车","tag":"产品修饰词"},{"word":"脚垫","tag":"产品修饰词"},{"word":"刷子","tag":"产品词"}]

实体识别插件主要用于识别出搜索内容中的产品词。比如用户在输入“汽车脚垫刷子”时，如果没有做产品词识别，“脚垫”相关的商品会因为商品分高而排在“刷子”商品前面，影响用户搜索体验。
反之，经过命名实体识别，对“刷子”做产品词提权，刷子类商品就可以排在脚垫类商品前面，优化搜索体验。
目前有赞规划的实体类别列表如下所示：

  产品词 eg：“修身连衣裙”中的“连衣裙”
产品修饰词 eg：“汽车脚垫”中的“汽车”
普通词
新词
修饰
品牌
机构实体
地点地域
材质
人名
功能功效
专有名词
影视名称
型号
文娱书文曲
系列
游戏名称
款式元素
颜色
场景
风格
营销服务
人群
时间季节
性别
类目
母婴
规格
新品
前缀
后缀
数字
符号

实体识别方法

基于正则可以识别数字、符号、规格、时间季节。

  // 数字
private numWordRegex = "[0-9]+";  
// 符号
private String symbolWordRegex = "[\\[\\]\\{\\}【】「」\\\\\\|、｜‘'\"“”’；：;:>.。》/？\\?<《，,~`·！\\!@#\\$¥%\\^…&\\*（\\(\\)）\\-_—=\\+\\s]+";  
// 规格
private String unitRegex = "(?:\\d+|\\d+\\.\\d+|[一二三四五六七八九十百千万]+)\\s*(?:m|米|cm|厘米|ml|毫升|l|升|度|平米|件|块|元|片|张|本|条|瓶|部|辆|个|桶|包|盒|g|克|kg|千克|吨|寸|斤)";  
// 时间季节
private String seasonRegex = "[春夏秋冬]+[季天]?";  
private String yearRegex = "(?:18|19|20)\\d{2}";

基于词库可以识别产品词、品牌、产品修饰词。

  品牌：query->二级类目->品牌，条件：在当前类目品牌词库里且模型预测不是“产品词”，此时打“品牌”实体标。    
产品词：在产品词库且模型预测是普通词。   
产品修饰词：多个词出现时，除最后一个，其余打“产品修饰词”实体标。

基于模型可以识别剩余23类实体，类别如下所示：

  产品词
普通词
新词
修饰
品牌
机构实体
地点地域
材质
人名
功能功效
专有名词
影视名称
型号
文娱书文曲
系列
游戏名称
款式元素
颜色
场景
风格
营销服务
人群
时间季节

模型结构：

5.6 类目预测categoryPredict插件

样例

  输入：牛奶绒
输出: {
        "categoryId": "101000010001",
        "categoryName": "被套",
        "categoryChainList": [
            "家居建材",
            "床上用品",
            "被套"
        ],
        "parentCategoryId": "10100001",
        "level": 3,
        "hasChildren": true,
        "percent": 0.9010684490203857
    }

该插件会根据用户的搜索内容输出类目结果，主要应用在类目加权上。
例如当用户在有赞精选上输入牛奶绒，期望返回牛奶绒床单。
未使用类目加权，返回的商品大多为牛奶相关产品，不符合用户的搜索期望。
使用类目加权后，将床上用品类产品提权，返回的商品牛奶绒床单，符合用户期望。
类目预测模型是在对比学习基础上实现，具体内容可看对比学习在有赞的应用

5.7 同近义词插件

样例

  输入：[衬衣]
输出：[衬衫]

同近义词插件目前非常实现轻量，通过离线同义词表，搜索内容中的产品词作为输入，输出同义词。

六、总结与展望

本文从QP整体设计，分层设计，插件设计较为完整的介绍了QP的架构设计。目前经过一年多的迭代，QP已经实现业务场景小时级接入，优化了零售，微商城，精选，爱逛，分销等场景搜索效果。后续将会继续丰富算法插件能力同时完成QP可视化配置能力方便业务自主接入。

本文由吴鑫强，任艳萍负责收集整理。

资源搜索引擎

Fri, 22 Jul 2022 12:43:00 CST

易搜	阿里百度夸克网盘搜索
阿里盘搜	阿里云盘搜索
tg中文搜索	电报资源搜索引擎
千帆搜索	电报资源搜索引擎
搜漫	漫画搜索引擎
影视搜	影视聚合搜索引擎
辅助狗	无捆绑软件搜索引擎
查报告	可查询各行业的分析报告
蓝廋	蓝奏网盘搜索引擎
学霸盘	课程资料百度网盘
问答库	考试答案平台
库问搜索	PDF文献资料搜索

腾讯音乐知识图谱搜索实践

Sat, 05 Feb 2022 00:00:00 CST

分享嘉宾：Elvin 腾讯音乐高级工程师

编辑整理：李一中科雨辰

出品平台：DataFunTalk

导读：近几年来，图数据在计算机领域得到了广泛的应用。互联网数据量指数级增长，大数据技术、图数据方面的应用增长很快，各家互联网大厂都在图数据分析和应用方面大量投入。为了让我们的搜索更加智能化，腾讯音乐也借助了知识图谱。今天和大家分享下腾讯音乐在图谱检索与业务实践方面的探索，主要包括以下几大部分：

音乐知识图谱介绍
图数据库选型
项目架构介绍
知识图谱搜索功能应用举例
总结与展望

01 音乐知识图谱介绍

首先和大家介绍下音乐知识图谱的相关知识。

1. 音乐数据分类

图状数据广泛存在，其中与音乐相关的业务数据主要有以下三类：

内容方面有歌曲、综艺、影视、专辑等；
歌手方面有歌手信息、歌手之间的关系，包括组合、相似等；
歌手和歌手内容之间的关系有演唱、作词、作曲等。

2. 音乐知识图谱的应用场景

(1) 复杂搜索需求实现

音乐知识图谱不仅可以做简单的搜索，还可以实现复杂搜索需求。例如要查询周杰伦的男女对唱的歌曲有哪些，如果要实现这个查询，需要对周杰伦的歌曲进行一定的过滤，歌手的数量要等于2，另一位歌手的性别是女性，还要考虑基于播放量、歌手权重等等的排序。在传统关系型数据要实现这个功能很复杂。利用知识图谱就比较简单了，先找到歌手周杰伦，查找周杰伦的所有歌曲中满足2人合唱，另一个歌手性别是女性的，只要两跳就可以实现复杂的搜索查询。

(2) 搜索结果的相关推荐

可以根据搜索的关键词，查询图谱中的实体节点，根据实体节点查询出关联的节点，用关联的节点给出推荐的结果。例如用户搜索周华健，可以通过关联信息推荐出李宗盛。如果通过搜索引擎，很难推荐出李宗盛，而用知识图谱，只要两跳，周华健歌手到对应组合（纵贯线），从组合再到另一歌手李宗盛，只要两跳。

(3) 基于知识计算给出答案

可以根据知识图谱的计算来给出一些答案，通过图谱的关联信息，实体上下位信息，实体属性信息，查询出相应的答案。例如用户搜索刘德华90年年代的歌曲，用知识图谱的话，只要歌手刘德华，时间90年代歌曲，两个联合起来就可以得到结果。

3. 搜索召回和知识图谱召回优缺点

搜索召回，是基于文本匹配的，召回之后会涉及相关性排序，相对来说比较复杂，精准度不足，可能过度召回。搜索召回的流程比较复杂，排序策略也相对复杂。

知识图谱召回，是基于实体之间的关系进行查询，可以做到精准召回，也没有过召回，召回的流程可以很短，也就是几条图查询的语句。另外，知识图谱还具备一定的推理能力。

02 图数据库选型

要实现图查询，首先得做图数据库的选型。

图数据库的选型，需要考虑以下几点因素：

开源非付费，考虑到成本及源码可控性，选择拥抱开源；
分布式框架可扩展，随着数据的增加和减少，后台必须是可扩展的；
高性能毫秒级多跳查询，要做到毫秒级的在线响应；
支持千亿级规模数据量；
支持数据批量导入导出。

我们对比了8个数据库，对优缺点进行了分析，对这些数据库进行了分类：

第一类，以Neo4j为代表的，只有单机版本，性能比较优秀，但是不满足分布式可扩展性要求。Neo4j的商业版本支持分布式，但是却是收费的。
第二类，JanusGraph、HugeGraph这类数据库，支持分布式可扩展的，他们的共同特点是在现有的图谱上增加了通用的图语义解释层，受到存储层架构的限制，存储层是外部数据库实现，不支持计算下推的功能，导致性能较差。
第三类，以NebulaGraph为代表，这一类数据库都实现了自己的存储层，支持计算下推，做了效率上的优化，性能提升很多。

从上图看到综合性能测试数据。我们通过1度邻居（跟点直接相连的点），2度邻居，共同邻居，这三个方面来对数据库性能进行测试，可以看到Nebula不管是单机性能，还是集群性能，都要远超于其他竞品。考虑到性能，社区活跃度，版本迭代速度，语言上的通用性，我们最终选择了Nebula数据库做为我们项目的图数据库。

03 项目架构介绍

1. 在线层

包含以下模块：

Storaged负责具体数据的存储，包括点数据、边数据，以及相关的索引；
Metad负责存储图数据的meta信息，例如数据库的schema、addition等；
Nebula graphd负责数据计算的逻辑层，是无状态的，可以进行平行扩展，内部执行计算引擎来完成查询的整个过程。
Nebula proxy是我们新增的模块，作为整个nebula模块的代理层，可以接受外部的命令，并对图数据进行操作，包括图的查询，更新，删除。另外，nebula proxy也负责协议的转换，集群的心跳和路由注册。

由于单集群有重建数据的需求，也为了防止机房故障，我们选择双集群来支撑整个服务的可用性。

在线层请求处理的流程为，cgi在接收到用户请求后，将用户请求传给broker模块，broker请求模版匹配生成相应的图查询语句，从Zookeeper中提取可用的集群，将查询语句发给nebula proxy进行图谱召回，nebula proxy将具体的查询语句传递给nebula graphd, nebula graphd负责执行最终的语句，然后把结果返回给broker层，broker层补充一些前端显示摘要后，将数据返回给前端做展示。

2. 离线层

音乐数据有实时的新增数据，例如新增发行的唱片，还有全量数据的更新，所以我们选择了全量加增量的数据层方案。

(1) 全量数据生成方案

音乐很多数据存在数据库中，先将数据从DB中dump出来后，由IndexBuilder模块将数据格式转换为所需的格式后形成一个全量的源数据，将全量的源数据上传到HDFS后，通过运行spark任务，把数据转为Nebula底层所需的数据文件，IndexMgr发现有新的常量数据生成后，将数据文件下载下来，将全量数据加载到NebulaProxy，这样全量数据就生成好了。

(2) 实时数据的生成

每隔一段时间，通常是几分钟，将几分钟之内的业务修改数据dump出来后，转为特定的格式，形成一个增量的源数据，增量的源数据存入到Kafka里面，可以用于数据的重发和恢复，DataSender从Kafka队列里面拉取到最新的数据，通过NebulaProxy发送到集群，这样增量数据就生效了。

这里涉及到了一个增量补发的问题，因为存量过程dump过程中要耗费很长时间，可能要花几个小时，在全量数据dump过程中也有新的增量数据，这期间的增量数据可能并没有进入到全量的数据当中。所以这里需要进行一个历史增量的补发，从T0后（全量同步开始时间）的新增数据，不在全量数据中，需要将T0之后的数据全部进行补发。

04 知识图谱搜索功能应用举例

1. 配置化召回

常规召回方式为：根据Query生成查询语句，获取召回结果，根据策略混排，召回结果展示。

这样做的问题是，每做一次，每增加一种新的召回策略，以上四步都要重复，所以召回不够灵活，业务改动大。

我们增加了一种新的基于Query模板的召回方式，就是根据模板生成对应的查询语句，同时预先设置了一些常用的混排策略。比如我们配置一个学校加校歌的模板，当查询校歌的时候，我们把学校的名字提取出来，填到查询语句里面，形成一个完整的图查询语句。同时也预置了一些混排插入策略，填入对应的混排参数，就可以做到上线。这样做的优点就是召回比较灵活，和搜索相比，召回上线的代价比较小。

2. 业务应用

我们最终上线了上图这些业务，支持各类搜索场景。

校歌搜索：当用户搜索大学校名和校歌组合时，召回对应的学校的校歌；
歌手场景：当用户搜索歌手名字的时候，返回歌手所在组合，以及合唱过知名歌曲的合作歌手等；
影视场景：当用户搜索影视主题曲、片尾曲、插曲等等的时候，返回对应的影视的歌曲。

05 总结与展望

今天的讨论从图数据的选型开始，到schema分类定义，项目架构层设计，再到知识图谱的搜索。结论是采用图数据，可以很好的把专家经验智能融入图谱。通过图数据技术实现的知识库，增强了检索、推荐、可视化等功能，腾讯音乐很好的对知识图谱技术进行了应用，大大提高了客户的搜索体验感，增强了客户黏度。让我们拥抱AI技术，让其更好地服务于生活。

06 精彩问答

Q：在搜索过程中有考虑音频信息吗？

A：这个是有考虑的，我们可以通过音频识别技术，首先去识别歌曲的一个大的分类流派，比如说像民谣摇滚流行这些流派，然后在线检索的时候，我们会通过这种语音搜索去召回。另外，我们跟QQ音乐天津实验室也有合作，比如像听目前的金科视曲，后台走的也是走我们的限量搜索，也是通过对音频信息进行的召回。

Q：语义检索结果排在第几位？是怎么和关键词检索一起排序的？

A：首先我们会通过算法去挖掘某一个语义标签跟某一首歌曲的相似度，语意搜索的话就可以通过语音标签进行召回，优先把语义相似度高的结果排到前面。当然也会有一些奇异的情况，比如说像赵雷有一首歌叫民谣，民谣这首歌就是一个歌曲，它同时也是一个语义，我们排序的时候也会兼顾这种混排的效果，最下层排序，首先会把民谣的歌曲放在前面，因为它毕竟是一个比较知名歌手的歌曲，下面会把对应的语义的结构放在后面，然后我们在更上层会有基于算法的排序模型去给用户推荐点击量高的调前。

Q：全量索引版本切换双buffer内存是否会翻倍？

A：实际上我们索引切换的过程中是没有双buffer的，是按每一个分片下的每一个副本进行逐个切换，切换的时候会进行动态的卸载，所以并没有占用额外的内存。

Q：跨越截断，是在index截断好，还是在线选择截断？

A：是在线选择截断，如果离线截断会导致数据丢失，这样是没办法回溯的。截断也是分片的，向量检索也是可以分片之后，做并行检索。

今天的分享就到这里，谢谢大家。

在文末分享、点赞、在看，给个3连击呗~

分享嘉宾：

活动推荐：

2022年02月19日，由英伟达、中电港联合举办的《深度学习推理优化与部署实践》技术分享，邀请英伟达、京东科技、vivo技术大咖，围绕“如何给深度学习加速？”为大家带来系列分享，感兴趣的小伙伴可识别下方海报二维码进行报名。

关于我们：

DataFun：专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请近1000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章500+，百万+阅读，12万+精准粉丝。

分享、点赞、在看，给个 3连击呗！

百度搜索中台新一代内容架构：FaaS化和智能化实战

Thu, 13 Jan 2022 03:28:31 CST

导读：百度搜索中台内容计算架构为在线提供了数十亿的异构且有丰富特征和信号的优质原材料。我们以 Serverless 理念为指引，通过FaaS化和智能化的系统性建设，构建了新一代内容数据计算系统，实现了业务研发效率、资源成本和架构稳定性维护性的显著提升。本文从搜索中台内容架构演进过程中遇到的问题入手, 分析系统设计思路，然后详细介绍具体实践方案。

全文10719字，预计阅读时间7分钟

一、背景

搜索中台内容计算架构支持了数十个业务线的上百个检索场景，每个场景的数据都有一定的差异性，之前这些差异性都是由业务同学通过自定义的脚本进行独立开发。这些脚本存在开发成本高、维护成本高的情况，我们引入了业务框架+服务平台，实现了业务可以独立开发、自动部署和上线，同时代码库可以复用，一定程度上解决了开发成本和维护成本的问题。伴随业务快速发展，自定义入场开发的场景和诉求越来越多，在此过程中出现了以下问题：

学习成本大: 业务框架做了抽象，业务要上手开发需要学习完整的接入规范、开发规范，有的场景可能只要较少的业务代码开发，但是学习时间却要一周甚至更久，在新场景接入、尤其是简单业务场景，越来越多的情况下，学习成本变成了个棘手问题
资源成本高: 很多的业务场景有潮汐式特征，即每天只有一小段时间有内容计算，假设它只有1小时有，那么之前的架构浪费了23/24的资源，即另外23小时没有任何计算确占着资源，导致巨大的资源浪费
维护成本高: 搜索自身的复杂性，导致出现问题的时候开发者排查异常困难，有时候强依赖某些有经验的同学，整个系统的维护成本越来越高

在业务接入越来越多、业务迭代也越来越高频、业务的数据量越来越大的情况下，如何通过技术手段，实现开发成本、资源成本和维护成本的显著提升？相信这个问题，也是一个业务系统经过一定发展后，大概率会遇到的一个问题。

二、思路与目标

业界对于Serverless的大规模实践主要是聚焦于Web端应用，中后台的实践相对少一些。我们面对的场景是搜索中台数据的实时计算，而搜索本身又是非常复杂的业务。但是通过对我们场景的抽象与分析，我们具备了在中后台复杂场景实践Serverless/FaaS的可行性：

一方面，虽然业务开发的功能需求千差万别，本质上仍然有很多通用共性的地方。对于业务特定化的处理逻辑都可以将逻辑转化成一个一个的函数。而共性的功能可以通过抽象成通用组件。通过函数的编排和组件的复用可以乐高式搭建出适合业务的搜索数据计算系统。同时业务完全聚焦于业务自身逻辑中去，高可用、高并发、高扩展这些用户都不需要关注, 极大的简化的业务接入成本。
另一方面，由于业务流量的波峰波谷异常明显，通过深入业务层的智能化调度的实现，不仅可以提升业务在流量峰值的扩展能力，而且通过调度可以实现资源的充分利用，节约大量的资源成本。同时，针对越来越复杂的的系统，必然导致问题的排查恢复的成本也越来越高，通过智能化控制系统的引入，实时发现分析处理异常问题，使得整个系统更稳定更有韧性。

结合业务痛点，总结起来主要是两方面的工作：

通过 FaaS化建设，业务从聚焦于服务研发转变为聚焦于函数开发，全面的提升业务的开发效率。这里的FaaS化改造不仅仅说的是技术底座的变革，更是全系统全流程整体的业务效率的提升。
通过 智能化建设，让架构系统根据服务的容量和状态进行动态调整，使得可以在追求更低资源成本的同时提供更高质量服务。智能化建设即包括从0到n极致化的智能伸缩调度，还包括根据系统的多维度实时状态信息进行智能分析自愈的智能控制系统。

三、FaaS化改造: 追求业务明显感知的卓越效能

FaaS的极简化的思维从直观的角度上来说本身就会给业务带来巨大的人效的提升，如下图所示：

如上图所示业务在过去的普通云化服务中需要关注内容较多：从应用程序本身、组件和数据，以及服务的运行时环境，到最后的服务容器等基础设施的管理都需要业务方去关注。
当业务转变到FaaS化的思维中，业务需要开发处理的只是业务的一段逻辑表达，这里是以Function的方式表示，其他部分(包括组件、数据、运行时环境和基础设施等一系列因素，业务甚至连原本应用程序本身)都不需要管理。

搜索中台内容计算在FaaS化方面主要进行两部分工作，其一是核心框架，其二是业务全流程系统建设，最终保证业务的开发效率与现在相比有根本性的转变。

3.1 核心框架: 业务抽象与能力复用

核心框架是我们整个系统改造的基石，对业务来说主要包含两部分:

极致抽象的业务框架：是核心框架基础中的基础，提供新的开发范式同时，为后续智能调度奠定良好基础
高度复用的基础服务：强大丰富的后端服务能力封装，支持业务低成本复用，降低开发成本同时提升稳定性。同时系统还提供强大的编排能力，低成本支持业务从简单到复杂的发展

极致抽象的业务框架

业务框架作为FaaS层和业务代码的载体，是整个业务逻辑的代码框架。框架本身维护数据流语义，面向有向无环图（DAG）的数据流，调用业务函数代码。业务框架是面向有向无环图的数据流实时计算，支持完备的流式计算语义：

业务端使用开发成本低的脚本语言进行开发（例如Python），基础服务框架使用C++实现，通过架构层面的优化策略来达到服务性能和开发成本的平衡。

基础框架的发展本身经历了两个阶段：

阶段1:基础框架引擎使用C++实现(原来业务框架阶段基于脚本语言实现)，架构代码与业务代码的充分解耦，直接调用业务函数代码，业务开发效率已经有了质的飞跃。
阶段2:为了规避脚本语言在进程中只能使用单核（如Python、Php、JS等）特点，让业务函数具备容器内使用多核的能力，为后续支持极速扩容奠定基础。

下面就来看下整体框架的构成方式，看上图右侧部分:

流式计算框架: 我这边是直接基于百度StreamCompute流式计算框架开发，该框架原生支持基础流式计算数据流语义、支持拓扑函数的编排描述，为整个FaaS提供坚实的基础底座。大家实际使用过程中可以选取合适的流式计算框架开发。
数据预处理: 这里包含的功能比较多，从大体上协议解析、性能优化和数据观测等三个方面的工作
协议解析: 这里主要说明的框架的基础通信协议的定义解析，为了各业务数据通用性定义为入参和出参均为原始字符串；
性能优化: 接入数据流框架本身，通过批量顺序读写、数据压缩的方式提高数据穿入过程中的服务吞吐；
数据观测: 进行基础指标汇报包括QPS、延时、内部队列等一系列信息，和异步的Trace信息(进入到Kafka中)。
进程管理&服务管理: 并不在数据的主通道上，主要是应对整个容器内部进程和服务的管理。
进程管理: 伴生服务，负责启动、维护、销毁整个子进程的生命周期。
服务管理: 伴生服务，负责初始化并且维护远端的rpc 的client，修改访问参数，如超时、重试、下游访问策略等。负责新进程的创建、回收，以及进程间交互信息的维护。
进程通信异步数据分发: 这里有三个关键点: 数据不丢 、 异常健全 和支持 下游竞争消费。调研了包括数据管道通信、共享内存、系统队列和RPC等操作方式，考虑到稳定性、扩展性和实现成本等因素选择基于Baidu-RPC框架实现进程异步数据分发；
单进程模式： 当进程个数为1的时候则_跳过进程通信_，直接在本进程内部进行方法调用；
多进程模式：每个进程完全独立启动,业务视角隔离，但是公用一套业务代码环境。子进程处理完成后将请求结果反馈给父进程。
业务逻辑处理: 主要包括校验解析&函数调用&本地优化加速几部分，如上图左边就是业务逻辑处理的展开图。
解析&校验&优化: 每个线程内会进行参数解析协议校验，为了方便老业务迁移，支持多用户协议解析，线程并发优化；
执行引擎: 函数接口是真正函数调用地方，支持不同语言的调用引擎。eg: 如果业务使用Python，使用pybind。
数据提交: 执行完成后会统一推送到本地输出队列，本地队列里面的信息会异步提交到远端的消息队列里面给后续算子消费。

高度复用的基础服务

业务依赖的后端服务，包括多媒体长留服务，数据存储服务，策略计算等十项服务能力，所有的服务架构的支持目标都是通过简单配置、少量代码的方式进行服务接入。

架构通用能力：包括索引算分(倒排、正排、向量索引)，数据审核(政治敏感数据/色情数据识别&过滤)，多路分发、数据建库等能力；
与业务联合研发的能力：数据的低质过滤能力(实现数据清洗/归一化/数据去重/类目拼接)，数据多元融合，数据质量打分计算(质量打分/作弊识别/物料打分)
基于公司强大基础能力: 多媒体处理服务(外链转内链/OCR/水印计算/重复图计算/主体识别/视频转储等)，自然语言处理服务,数据沉淀服务

支持的BaaS服务主要是两个特点: 简单稳定 & 充分集成公司内其他优质能力。用户通过 SDK调用、 算子复用和 数据流复用等方式直接进行能力复用，完全不需要进行服务的部署和管理，服务易用性、稳定性由搜索中台来处理。使用任何服务后端都可以收口在一个地方，避免业务频繁跟多个服务团队进行交流处理，极大降低业务使用成本。

业务最开始接入通常只需要简单的少数功能（例如，修改部分字段的信息)，多数业务直接用我们提供的平台化的开发模板即可完成开发。但是随着业务的逐步深耕,业务逐步使用，业务会向复杂逐步过渡，例如搜索中台某业务通过复用 超过8种能力的组合使用，建设出具有深度定制的数据系统。

3.2 全流程效能提升: 提供极简的用户使用体验

如3.1中提到的核心框架是FaaS化的基础但并不是全部。因为改造的底层逻辑是让业务聚焦于开发业务逻辑。这个过程不仅仅包括代码的开发阶段，而是包括从接入、开发、调试测试、上线维护的全流程阶段，因此我们需要对于系统进行全流程效能提升，才能最终保证业务的全面效率提升：

快速接入:权限申请到数据接入的全面简化。简化的建设主要是两方面思路：其一是流程上的简化（例如: 权限申请流程无需架构同学参与，组内同学就可以审批处理）；其二开发过程的简化，对于常见的流式数据系统(公司其他中台或者官方数据系统) & 通用存储(常用的公司数据存储 eg Mysql、Mongo、公司内部的表格存储甚至原生FTP本地文件) 支持配置化的批量导入。同时我们也提自定义(完美适配Docker)的任务系统提供做够的灵活性保证业务的低成本接入；
极速开发:平台完善函数内容。我们这边开发有两种模式，一种适合初学者的Air模式，一种是适合高端玩家的Pro模式；针对于Air模式本身，用户可以直接在平台完成代码的提交和调试功能，完全一键处理；
快速调试&测试:业务可以根据自己实际的需要可以通过平台化的方式调试通用的模板函数，也可以通过线下集成调试环境一体化的对整个系统进行调试。针对于测试提供了平台化的测试方案，业务可以默认0配置的情况下进行服务性能和执行数据结果的DIFF；
问题定位: 这部分对于业务问题解决尤为重要。主要包括监控报警和云日志两部分功能(具体架构设计在2.1可观测性建设中有详细的描述)：
监控报警：包含两部分信息通用部分和业务自定义两部分。其中通用部分提供包括算子总体堆积程度，每个算子的处理的信息，app 实例状态等等20多项常用数据指标，直接集成到管理平台内部，可以不需配置直接使用。而自定义部分提供了基础的SDK函数装饰器，可以极低成本给监控自定义代码段的成功率，延时等信息；
云日志：包含数据Trace(数据流向)、日志Trace以及相关的数据报表服务,业务都可以极低成本进行服务接入。

通过的FaaS化建设，业务接入、开发、迭代、维护等全流程阶段的效率都有了巨大的提升, 达到了 10倍人效提升。

四、智能化:追求更低成本、更高质量的服务

通过上一部分提到的FaaS化改造，业务的全流程服务效率问题得到巨大的改善。接下来通过智能化改造的工作在避免大量资源浪费、降低资源成本的同时，提高业务的服务质量。智能化的工作主要包括两部分：

通过智能化的资源调度方案，极大的节约用户的资源成本，真正做到按需使用，而且可以有效处理流量洪峰，提高系统稳定性。
通过智能化的控制架构，有效处理异常问题，做到问题主动感知、决策并且主动处理，提升系统韧性的同时降低大量的维护人力成本。

下面针对于这两部分系统设计进行详细阐述。

4.1 智能调度: 极致化弹性伸缩

过去，业务的app主要配置固定容量配置，我们多数的业务流量都有明显的潮汐式，大量业务天级别只有1个小时，甚至几分钟的流量，这样就造成了大量资源浪费。

智能调度的核心作用就是实现业务的资源的按需分配, 实现从0→n的资源满足，具体上来讲主要有如下功能：

自动伸缩：根据当前服务流量的波动情况自动分配出来对应可以满足整体实例消费情况的实例数进行消费,包含纵向本地扩容+容器横向伸缩的方式相结合 多阶段扩容；
服务资源回收&冷启动：保证长时间没流量的服务容器，资源完全被回收，不占用任何服务资源，当新流量资源到来的时候，服务接着过去资源的数据消费，保证数据生效稳定性的同时，使得业务完全做到按需使用；
异常实例迁移：主要通过热点实例迁移，长尾实例迁移保证服务全局的正常运行；
容器资源自适应：主要通过检测内存使用状态，对资源容器进行自适应的调整，保证容器资源在不浪费的同时，保证服务不会超限而造成服务的OOM。

其中自动伸缩是一个这个场景下最典型的调度场景，下面以自动伸缩为出发点从设计思路&核心架构两个方面来具体阐述。

设计思路：多阶段扩容的设计原因

扩缩容最初只有传统意义上的横向扩缩容，在我们的业务场景下可以达到分钟级的是时效性，多数业务可以满足需求。然而，针对于高时效业务，当流量高峰突然到来的时候(例如3倍过去高峰流量)，分钟级的扩容速度业务无法接受。为了解决这个问题一般只能给一定业务流量BUFFER(比如2倍流量)。如果资源BUFFER充足，业务方则有大规模的的资源浪费，如果资源BUFFER不足时效性依然没有完全解决。

其实业务的核心诉求是架构能否做到相对稳定的秒级伸缩。可以快速缓解业务流量洪峰的压力，提高系统稳定性扩展性的同时达到最佳的资源利用。通过分析横向扩缩容底层现状我们发现:

启动时间分析: _容器的调度时间+rumtime初始化时间_占据了整个启动时间的98%以上，一般需要5分钟，依赖于公司基础PaaS环境，优化成本非常高；
开发业务：业务都是通过脚本语言开发（通常是Python），受到解释器限制极限只能用满CPU单核, 有时甚至由于业务代码逻辑问题远远无法达到；
资源占用：容器规格很小(CPU规格极小、容器内存资源充足)，多数机器上的剩余quota足够。

因此我们就想到使用，增加纵向本地扩容阶段：1. 通过Quota Resize 解决容器资源扩容问题；2.通过框架的多进程并发解决大容器下的业务能力上限问题。

结合3.1核心框架中提到的多进程框架的实现，实际扩容包含两个阶段：

纵向本地扩容阶段：可以满足在高时效业务场景下突发流量到来的极速资源满足速度，通常可以瞬间满足5~10倍的资源。此外，扩容过程中是允许少数实例纵向扩容失败的，通过流量均匀分发的能力，将纵向失败的流量实例流量均摊到成功的实例上。
容器横向伸缩阶段：两种情况会进行横向扩容阶段：
其一，当高峰流量持续时间较长(一般超过10分钟)时，会进行横向扩容实让服务容器分裂(例如：2个实例_10进程 → 20个实例_1进程)；
其二，纵向扩容后仍然不能完全满足吞吐要求(例如100倍的服务吞吐需求)，则会在纵向扩容后瞬间触发横向扩容，不过此时业务完全满足效率退化成分钟级。

以上描述的是扩容过程，缩容过程类似，优先进行本地缩容。这样保证容器的均匀分布，随时都能有本地扩容的能力。

核心实现: 调度核心架构

如下图是我们智能调度简化架构图:

主要分成下面几个阶段:

采集层: 采集数据的基础信息，这里主要需要集中类型的信息，尤其是扩缩容其实主要关注两个队列信息:
数据流的队列信息
流式算子之间的队列信息
决策层: 根据历史调度信息和当前的实际状态信息进行决策，实现多阶段可变步长的扩容:
优先进行本地扩容，根据当前容器的资源使用量最多需要平均可以扩容5→20倍
长时间当本地扩容到(或者接近)极限，则会进行横向扩容，这个资源水平没有特殊限制
多阶段: 本地扩容(纵向) + 横向扩容
可变步长: 数据堆积都有多个阈值，每个阈值关系到不同的步长(默认每个APP至少两个步长)。eg: 政务业务的数据流堆积1000持续超过30s则触发扩容1倍，如果超过10000，则直接扩容到最大实例数
分析层: 在整体资源低于阈值(默认85%)的时候默认是跳过该阶段；在整体资源超过阈值后，为了保证高优先级的资源进行优先级调度使用的，必要的时候会对低优任务进行淘汰
执行层: 根据决策分析层提供的信息执行
本地扩容: 直接调整容器Quota信息的同时基础框架的进程管理启动服务的进程数来实现本地的极速扩容(比横向扩容快一个数量级)
横向扩容: 普通横向调整实例个数，由于涉及到资源调度，数据环境的初始化，需要的时间周期是分钟级
过滤: 扩容生效都有一个时间周期(本地扩容秒级，横向扩容分钟级)，每个决策后都有一个静默期(比如10分钟)从而避免重复决策执行
跳档: 过滤只针对于完全相同的操作拦截，针对于不同步长扩容不拦截，保证业务在流量洪峰下的感知执行速度
执行: 真正执行操作，例如扩缩容操作

关于本地计算扩容: 进程管理的时候每启动一个子进程，实际内存增加约60M，CPU极限增加1核心(10个实例资源只是600M内存，10个逻辑核心)，超过实例 90% 情况都可以实现本地极速扩容。

按需计费的实现考虑到不同业务有不同的调度逻辑和配置场景: 有的业务需要资源预留（保证最低实例数), 则这部分业务有最低资源占有成本；而多数业务没有特定的需求，一般冷启动延迟业务可以接受，则不需要保证最低实例数;有的业务需要时效性要求比较高，扩容敏感度高，缩容敏感度低，而对于普通扩容敏感度，甚至敏感度更低的业务，相同状况下扩容的资源数可能完善不一致;有的业务不需要容器自动适配，而多数业务需要在容器尤其是内存设置不合理的时候主动获取更大的容器。业务实际上的收费就是按照业务不同的调度策略进行计费，真正做到不多不漏，合理计费。

通过智能调度服务实现了核心生产环境多数场景支持秒级自动伸缩，支持0→n的极致扩容。按需计费，整体资源节约87%。

4.2 智能控制: 防止问题升级扩散，全自动实时处理

智能化调度实现了极致化的弹性伸缩，做到了资源的极大节省。我们的整个系统也随着系统云原生化的改造下变得越来越复杂，但是问题的排查成本却越来越高。因此问题的排查通常需要多个方向的同学通力合作(或者依赖个别专家同学的定位)才能处理解决。这不仅仅是对架构人力的巨大浪费，而且干预时间常常不可控，对于线上有很大风险。为了解决这个问题，搜索中台内容生效架构引入了智能控制系统, 快速、准确的发现问题、处理问题并且整个过程是完全自动化的：

快速: 处理速度快，主动发现与消息通知相结合的方式，全面进行问题排查
准确: 历史出现过的问题转化成系统规则，整个过程模拟专家进行处理解决。只要规则合理，没有误操作，没有非预期行为
自动: 处理过程完全无需人工干预，全程自动化处理

智能控制系统总体上是以可观测为基石，以健全的自愈能力为手段，通过智能分析引擎进行实时动态分析决策，决策的结果会影响到观测数据做下一轮的数据分析。它们的相互关系如下。

通过整体系统的执行自愈的连续迭代调整，最终让系统调整到一个健康的状态。

完善可观测系统(基础)

可观测系统并非此次叙述的核心，但是它仍然是智能控制的基础。没有完备的可观测系统建设，一切有效的控制系统都是空谈，如下图就是整体可观测系统的概览:

基础采集层: 为所有的观测系统的数据提供最原始的基础数据采集。从数据类型来分主要是三类:
流式数据: 需要记录每条数据的信息，主要借助于Kafka的数据队列收集
指标数据: 对外汇报每个实例的指标数据，对外exporter汇报数，或者直接原始公司公司内的监控系统进行采集
自定义数据: 这种一般使用脚本以特定化的方式采集，作为基础指标采集的补充
数据处理层: 该层主要是针对于流式原始数据的数据处理，从图中可以看到主要是两部分数据，很多基础数据信息不需要额外聚合
指标聚合层: 主要是提供于 拓扑分析系统，这里基于StatsD和Prometheus的转换接口，实现的 指标动态分桶机制,极少资源完成大量数据信息
数据聚合层: 主要提供于 实时成功率监控系统，这里是基于数据的动态Hash和流式计算完成的
存储层: 该层是可观测系统的 中间核心，这里我们用到的数据存储既有开源的系统(包括ES/Prometheus/Mongo等)，也有公司内的监控系统(以复用为主)。有两个大系统提供原始数据:
一方面，给上层应用系统提供数据展示的原始数据；
另一方面，给智能控制提供决策的原始数据。
展现层: 用户直接访问的前端接口，这里有我们自定义的平台，也有直接借助开源系统Grafana和Skywalking之上进行建设
应用层: 用户或者是架构所需的对外查看的系统，有 6大业务系统，包括:
Trace系统: 包括数据Trace 和日志Trace，确认任意单条数据信息
指标系统: 最关键的基础数据信息，所有架构层和业务层的核心指标都收录于此
健康刻画系统: 通过当前全局的报警信息（报警级别、时间、个数）刻画出整体当前系统的健康程度
拓扑分析系统: 分析业务侧面和架构侧数据流是否存在异常（数据流量变化，异常点分析）
效果监控系统: 从数据生效结果监控，从架构效果端反推业务问题，比如监控关键数据变更的时间戳反推架构系统问题
实时成功率监控: 查看数据流整体端到端的实时成功率信息

通过一整套监控系统建让架构掌握大量实时多维度的数据指标。所有的系统的问题都会反应到一个（或者几个）指标数据的变化中去。一方面，可以作为后续自动控制的数据原材料；另一方面，架构通过将这些指标的分级(高中低)分通路(电话、短信、通信软件消息)的方式保证系统的人工兜底。

健全的自愈能力建设(手段)

完善可观测性提供决策的数据源，它是智能控制的基础。而自愈能力的建设是自动化的控制的重要手段，否则依赖纯人工干预（例如”手动删除一个实例” 或者 “线上修改一个配置”）的操作是没办法实现自动化和快速止损的。自愈能力建设这里重点描述所覆盖的功能集合，不仅仅包含我们传统意义上的容器管理功能(例如：实例重启、迁移等)，还有深入到业务系统架构中的服务管理类和通路控制类的功能：

服务管理类: 主要是基于资源&服务的管理，包括通路切换（主备切换，优先级切换）、数据拦截、数据回灌和服务降级等
通路管理类: 主要是基于提供基础组件的管理功能，包括流量清理、查询拦截(异常查询&慢查询查杀)

自动化问题分析引擎(核心): 规则+Function

自动化问题分析引擎是整个智能控制系统的大脑。它上游接收观测提供的原始数据，进行自动的分析决策后，通过系统提供的自愈能力处理。自动化问题分析引擎的核心思路: 只要历史上出现过的问题，RD同学能找到问题和解决方案，就可以转化为系统规则和后置函数梳理。那当下一次遇到问题则无需人工干预。规则引擎的核心分析过程是2段式的:

阶段1: 传统配置化的规则引擎的配置（上图中右上角黄色部分），配置多个采集指标项的逻辑关系（与或交非），这里主要是针对问题的基础分析功能,判定规则是否触发。
阶段2: 基于这个基础分析的结果，进行后置Function的执行分析，这个主要是针对复杂问题的分析补充，最终执行引擎根据这个返回结果进行函数执行。

下面针对问题分析引擎的执行结果如下:

前提: 开发者需要配置好处理逻辑规则（以及规则依赖的数据项，必填） & 回调函数（选填）。
数据解析器: 数据解析器主要承担的数据的原始抽取的工作，一共分成如下3步；

配置解析: 逻辑执行根据开发者配置的数据信息解析；
数据抽取: 根据解析出来的配置通过数据接口进行获取，可以从统一接口根据配置的信息从不同的介质充抽取所需求的信息；
数据归一化: 将不同介质的原始数据归一化成为统一的数据格式供规则管理器使用。

规则管理器: 规则管理器主要承担核心的逻辑分析工作，一共分成如下几步:

规则解析: 根据开发者配置的规则逻辑，将原始配置信息，解释成原始的规则树；
执行计算: 根据数据解析器提供的数据结果和配置的函数规则分别执行计算。执行计算过程中最重要的就是基础分析器，整体提供了5大基础能力，数十种常见的逻辑计算来辅助规则配置。
规则逻辑运算: 根据上层解析出来的规则树和每个数据项执行完成的计算结果进行逻辑运算，并根据执行的结果确定是否进行高级数据分析器，如果判断结果为真则根据所配置的后置函数进行处理；

高级数据分析器: 如图所示有两种模式，对于简单基础分析可以判断结果的，直接给默认的处理函数进行数据拓传；对于简单逻辑规则无法准确表达的，开发者可以自定义后置分析函数，函数会将原始数据和基础计算的计算结果作为参数传出来，开发者只需要通过处理后的数据描述清楚分析逻辑即可；
动作执行器: 就是这个分析器的真正的执行引擎，根据规则运算的结果中包含的参数进行动态调整。

通过 智能控制系统的建设，月级别分析处理上万的异常问题，自动恢复的比例占总数的 96.72%，所有问题的恢复时间平均在 1.5分钟， 90分位小于 3分钟，核心故障同比减少 60% （由于预处理防止普通问题恶化成严重问题）。

五、总结

整体的工作思路以Serverless为指导思想，通过FaaS化和智能化两个维度的系统化建设，以技术手段系统性实现了降本、增效、提质：

通过 FaaS化的建设，提升基础服务性能的同时全流程服务效率的提高，具体来说包括两部分：
打造新一代的核心框架，提供强大的基础底座让业务核心关注点从原来的云化服务思维聚焦到逻辑实现，业务通过简单复用和编排实现复杂的功能，让业务开发更简单
提供一体化全流程系统建设，让业务从接入、开发、调试测试到最终系统维护全流程的流畅体验，助力业务更高效的交付
通过 智能化建设，在稳定性有巨大提升的同时大幅度降低资源成本和系统的维护成本，具体来说也包含两部分：
通过智能化调度, 实现业务的按需分配(0→n), 秒级应对突发流量, 节约大量的资源成本；
通过智能化控制，实现全系统绝大多数问题问题的自动感知、自动分析、自动处理，提升稳定性的同时降低了系统的维护成本。

在Serverless上线之后，同时FaaS化和智能化的建设，业务真切感受到降本增效的同时稳定性和架构维护成本也显著降低，让架构和业务同学都切实感受到了新研发范式下的技术红利。Serverless 带给我们的是一种新的研发范式，实现了业务创新能力的巨大提升，期待在越来越多的场景中，涌现更多的最佳实践。

推荐阅读：

当技术重构遇上DDD，如何实现业务、技术双赢？

接口文档自动更改？百度程序员开发效率MAX的秘诀

技术揭秘！百度搜索中台低代码的探索与实践

百度智能云实战——静态文件CDN加速

化繁为简--百度智能小程序主数据架构实战总结

百度搜索中台海量数据管理的云原生和智能化实践

百度搜索中“鱼龙混杂”的加盟信息，如何靠AI 解决？

---------- END ----------

百度 Geek 说

百度官方技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢迎各位同学关注

搜索NLP行业模型和轻量化客户定制

Mon, 27 Dec 2021 06:00:16 CST

简介：开放搜索NLP行业模型和轻量化客户定制方案，解决减少客户标注成本、完全无标注或少量简单标注的等问题，让搜索领域扩展更易用。

特邀嘉宾：

徐光伟（昆卡）--阿里巴巴算法专家

搜索NLP算法

搜索链路

这是一个完整的从查询词到搜索结果的链路，其中NLP算法发挥作用的地方主要在第二阶段的查询分析，该阶段包含多个NLP 算法模块，如文本侧的分词、纠错、实体识别、词权重、同义词以及语义向量等。系统是结合文本和语义向量多路召回排序的架构，从而满足不同业务场景的搜索效果需求。当然除了查询分析，在第一阶段的搜索引导以及第四阶段的排序服务中也有很多NLP 算法的应用。

查询分析

NLP 算法主要在这里的几个子模块发挥作用：

分词，精准的分词可以提高检索效率，也会让召回结果更加精准，
拼写纠错，对用户输入的query中出现拼拼写错误可以自动去纠错，提高搜索的体验。
实体识别，可以对query 中的每个词打上对应的实体标签，从而为后续的query改写和排序提供关键的特征。
词权重模型，会对每个词打上高、中、低的档位，在查询结果时去做丢词的重查。
同义词，扩展出相同意思的词来扩大召回范围。
最后是经过完整的查询分析模块之后的一个整体的 query改写，将用户输入的query转换成我们搜索引擎能识别到的查询串。

现在开放搜索不仅支持了阿里自研的搜索引擎，也对开源的ES引擎做了兼容，可以让用户更方便的使用到我们的算法能力。

行业模型

客户痛点

1.通用模型领域适配难

通用模型主要解决新闻资讯行业问题；
在具体行业上效果会大打折扣；

例如:通用领域和电商领域的模型的区别

2.公开行业模型少

云服务产商基本只提供通用模型
公开行业数据集也主要覆盖通用领域

解决难度

构建一个行业搜索NLP 模型的流程：

首先是 标注数据集这一步对于行业知识的要求非常高，同时对于 数据量的要求也需要达到万级别， 标注这样的数据同时也需要数个月的时间。
接着是模型训练，这一步是需要有 专业的算法人员，如果不是对算法不熟悉的话，模型的迭代效率会很低
最后是模型上线这一步需要 工程人员去部署运维，如果涉及到深度模型的一些上线，还会有很多效率优化的工作需要去做。在数据集标注阶段其实就已经存在了很多的挑战。

分词标注难点

1.领域知识要求高

例如：

药物的名称：利多卡因氯己定气雾剂 | 利多卡因氯己定气雾剂
地址：南召县四棵树乡王营村 | 南召县四棵树乡王营村

2.交叉歧义判断难

例如：

洗衣服粉 | 洗衣服粉

实体识别标注难点

1.领域知识要求高

例如：

澳洲爱他美（母婴品牌）金装一段、科比（球鞋系列）4
pytorch实现GAN（算法模型）

解决方法

开放搜索基于阿里巴巴内部搜索的数据积累，结合自动化数据挖掘和自研的算法模型，对行业模型的构建链路做了一个改造。

同样是以分词和NER为例，下面模型图是分词的流程。 我们首先通过自动的新词发现算法去挖掘目标领域的领域新词，得到这些新词之后，我们会在目标领域上去构建一个远程监督的训练数据。

基于这样的远程监督训练数据，我们提出了一个 对抗学习网络的结构模型，结构可以达到降噪的效果，从而去年得到一个我们目标领域的领域模型。

下面的模型图是NER的流程，我们采用了 结合图神经网络的graph NER的模型结构，它可以融合知识库和标注数据。知识库是由刚才分词的链路中新词发现模块自动挖掘出的新词，然后我们做一个自动的实体词打标，从而去构建出领域的知识库。对应的技术论文我们都已经发表在NLP 领域顶会ACL上。

小结一下，通过上面提到的技术方案，以电商行业为例，看一下开放搜索行业模型上达到的效果。

可以看到开放搜索的电商行业增强版都明显比通用版效果会好很多。

这套方案不仅仅适用于电商行业，只要是有数据积累的行业，都可以快速构建出一套行业模型。

开放搜索轻量化客户定制

客户痛点

首先可以看到通用模型直接使用大概能达到一个60分的效果。

刚刚提到的行业模型，适用能力可以达到80分的效果。

但具体到每个客户又存在细分领域的定制问题。一般客户的目标可能是要达到90分。

比如下面的两个例子：

左边的这个“万斯汽水系列”，这其实是一个球鞋的一个具体的品牌和系列名称，虽然开放搜索电商模型已经可以把品牌和普通词识别正确，但是对于汽水这个具体的细分的系列并没有正确的识别好。
下面右边的这个例子是“汉本萃葆蔚饮品”。这里开放搜索的电商模型完全没有识别出其中特有的品牌和它的子系列，客户在我们提供的行业模型基础上如果去做自主的定制优化一样会遇到上面介绍行业模型解决方案时的那些问题，从而最终很难去突破85分，

我们的目标是减少客户的标注成本，完全无标注或者少量简单的标注，让客户的定制会更加易用，从而直接达到一个85分的效果。

解决思路

整体的流程和行业模型构建链路类似，要把这些 能力产品工具化让客户可以自主参与调优。

新建训练模型

下图是我们做的一个工具demo，上面是创模型，创建部分客户可以选择基础的行业模型，然后上传自己的领域无标注的数据就可以自动的开始模型的训练。

2.效果评估

下面是模型训练之后客户可以在我们的系统上面去做一个直观的效果评估，可以看到这里会列出基础的模型和以及自动训练之后的模型的效果的变化，客户也可以去做少量的人工标注来验证模型的效果。

这个链路目前已经在阿里内部使用，近期还会在开放搜索的产品上透出给到客户，原来我们去做一个轻量化的客户定制达到上述效果可能需要一到两个月的时间，还需要去标注1万句以上的这些标注数据。 现在的话基于这套方案只需要一周的时间，完全无标注或者只需要去标注1000个此以内的标注数据就可以达到这样的效果。

轻量化定制效果展示

我们的工具可以自动发现出场景中的这些新词，并对这些新词做实体标签的预测，可以看到括号中的这些新词是在不同的上下文中预测出的，标签的一个分布从而指导我们去判断这个新词它是否是一个合法的新词，以及它属于的实体标签到底是什么，为我们的模型去提供最关键的信息。

地址场景

电商场景

原文链接
本文为阿里云原创内容，未经允许不得转载。

消息称，腾讯和字节的内容即将向搜索开放，百度或成最大赢家？

Tue, 19 Oct 2021 07:58:00 CST

据彭博社报道，工信部正在考虑要求腾讯和字节跳动等媒体公司开放搜索壁垒——即允许用户在本平台上搜索并访问其他平台的内容。

知情人士说，规章设计仍在讨论当中。工信部希望可以通过百度等搜索引擎，让用户直接可以获取到微信上的数亿篇文章。其中一位知情人士说，工信部还在考虑将抖音的短视频也向搜索引擎开放。他们表示，监管机构正在向公司征求反馈意见，目前尚不清楚这一政策是否会实际执行。

如果政策得以实施，这将标志着国家在打破互联网巨头垄断——尤其是在腾讯和阿里——上取得重大进展。监管机构已经警告科技公司开放他们所谓的搜索壁垒，允许与竞争对手服务的链接。这同样也为全球范围内的反垄断进程做出了良好表率。

迫使字节跳动或腾讯允许百度和其他竞争对手在互联网搜索中展示他们的社交媒体内容，这将对互联网巨头的广告板块产生阶段影响。它可以将广告收入从微信或抖音等服务，转移到百度等搜索引擎上。

应此消息，百度在港股股价一度上涨4.3%。腾讯发言人拒绝评论，而字节跳动和百度的发言人则完全没有回应彭博社的评论请求。工信部对此也没有回复。

雷锋网分析，随着打击力度的扩大，反垄断局已向互联网大公司所经营的封闭生态系统宣战。一些公司采用封锁和其他方法来保护各自的领域，这成为了反垄断机构的主要打击对象：比如腾讯微信之于社交媒体，阿里巴巴的淘宝和天猫之于电子商务，以及字节跳动的抖音和今日头条之于视频和新闻。

而以可见的速度，垄断壁垒正在消除。腾讯上个月允许微信用户通过一对一消息链接到抖音视频和淘宝商店等内容，而阿里巴巴在其部分应用程序中添加了微信支付系统。

在先前，国家的互联网治理已经取得了不小的成效。国家先后整治了阿里巴巴和美团的市场滥用，并开展净网行动，同时先前出台的未成年人网游防沉迷新规也同样体现了国家智力互联网领域的决心。

据称，目前的审议主要集中在微信的公众账号上，它允许个人和企业发布从娱乐到新闻等多个领域的的文章内容，而这个庞大的内容库现在屏蔽了百度和字节跳动等搜索引擎。微信上的文章现在只出现在微信的本地搜索功能或搜狗上。

为了与微信竞争，百度于 2016 年推出了自己的内容平台——百家号来填充百度平台上的内容，这也使得百度在BAT的内容竞争上可以不落人后。

限制搜索服务的并非只有腾讯。2008 年，淘宝就屏蔽了百度搜索。据称，此举旨在保护消费者利益。而事实上，这将商家牢牢地绑定在了淘宝上，这也使得阿里从当时开始就主导了网上购物领域。知情人士说，目前尚不清楚工信部是否还打算取消对淘宝列表或其他内容的屏蔽。

【封面图片来源：网站名和讯网，所有者：和讯网】

Bing高级搜索技巧

Sat, 21 Aug 2021 11:41:19 CST

Advanced search keywords

Want to spend less time sorting through irrelevant results? Advanced keywords can give you better search results so that you find only what you want. Use the following keywords to help limit and focus your searches:

Keyword	Definition	Example
contains:	Keeps results focused on sites that have links to the file types that you specify.	To search for websites that contain links to Windows Media Audio (.wma) files, type music contains:wma.
ext:	Returns only webpages with the filename extension that you specify.	To find reports created only in DOCX format, type your subject, followed by ext:docx.
filetype:	Returns only webpages created in the file type that you specify.	To find reports created in PDF format, type your subject, followed by filetype:pdf.
inanchor: or inbody: or intitle:	These keywords return webpages that contain the specified term in the metadata, such as the anchor, body, or title of the site, respectively. Specify only one term per keyword. You can string multiple keyword entries as needed.	To find webpages that contain “msn” in the anchor, and the terms “spaces” and “magog” in the body, type inanchor:msn inbody:spaces inbody:magog.
ip:	Finds sites that are hosted by a specific IP address. The IP address must be a dotted quad address. Type the ip: keyword, followed by the IP address of the website.	Type IP:207.46.249.252.
language:	Returns webpages for a specific language. Specify the language code directly after the language: keyword.	To see webpages only in English about antiques, type "antiques" language:en.
loc: or location:	Returns webpages from a specific country or region. Specify the country or region code directly after the loc: keyword. To focus on two or more languages, use a logical OR to group the languages.	To see webpages about sculpture from the U.S. or Great Britain, type sculpture (loc:US OR loc:GB). For a list of language codes that you can use with Bing, see Country, region, and language codes.
prefer:	Adds emphasis to a search term or another operator to help focus the search results.	To find results about football but that primarily pertain to the organization, type football prefer:organization.
site:	Returns webpages that belong to the specified site. To focus on two or more domains, use a logical OR to group the domains. You can use site: to search for web domains, top level domains, and directories that are not more than two levels deep. You can also search for webpages that contain a specific search word on a site.	To see webpages about heart disease from the BBC or CNN websites, type "heart disease" (site:bbc.co.uk OR site:cnn.com). To find webpages about the PC version of Halo on the Microsoft website, type site:www.microsoft.com/games/pc halo.
feed:	Finds RSS or Atom feeds on a website for the terms you search for.	To find RSS or Atom feeds about football, type feed:football.
hasfeed:	Finds webpages that contain an RSS or Atom feed on a website for the terms you search for.	To find webpages on the New York Times website that contain RSS or Atom feeds, type site:www.nytimes.com hasfeed:football.
url:	Checks whether the listed domain or web address is in the Bing index.	To verify that the Microsoft domain is in the index, type url:microsoft.com.

Don't include a space after the colon in these keywords.
Some features and functionality described here may not be available in your country or region.

阿里一面，给了几条SQL，问需要执行几次树搜索操作？

Sun, 31 Jan 2021 05:20:03 CST

前言

有位朋友去阿里面试，他说面试官给了几条查询SQL，问:需要执行几次树搜索操作？我朋友当时是有点懵的，后来冷静思考，才发现就是考索引的几个基础知识点~~ 本文我们分九个索引知识点，一起来探讨一下。如果有不正确的话，欢迎指出哈，一起学习~

公众号： 捡田螺的小男孩
github地址，感谢每颗star

github.com/whx123/Java…

面试官考点之索引是什么？
面试官考点之索引类型
面试官考点之为什么选择B+树作为索引结构
面试官考点之一次索引搜索过程
面试官考点之覆盖索引
面试官考点之索引失效场景
面试官考点之最左前缀
面试官考点之索引下推
面试官考点之大表添加索引

一、面试官考点之索引是什么？

索引是一种能提高数据库查询效率的数据结构。它可以比作一本字典的目录，可以帮你快速找到对应的记录。
索引一般存储在磁盘的文件中，它是占用物理空间的。
正所谓水能载舟，也能覆舟。适当的索引能提高查询效率，过多的索引会影响数据库表的插入和更新功能。

二、索引有哪些类型类型

数据结构维度

B+树索引：所有数据存储在叶子节点，复杂度为O(logn)，适合范围查询。
哈希索引: 适合等值查询，检索效率高，一次到位。
全文索引：MyISAM和InnoDB中都支持使用全文索引，一般在文本类型char,text,varchar类型上创建。
R-Tree索引: 用来对GIS数据类型创建SPATIAL索引

物理存储维度

聚集索引：聚集索引就是以主键创建的索引，在叶子节点存储的是表中的数据。
非聚集索引：非聚集索引就是以非主键创建的索引，在叶子节点存储的是主键和索引列。

逻辑维度

主键索引：一种特殊的唯一索引，不允许有空值。
普通索引：MySQL中基本索引类型，允许空值和重复值。
联合索引：多个字段创建的索引，使用时遵循最左前缀原则。
唯一索引：索引列中的值必须是唯一的，但是允许为空值。
空间索引：MySQL5.7之后支持空间索引，在空间索引这方面遵循OpenGIS几何数据模型规则。

三、面试官考点之为什么选择B+树作为索引结构

可以从几个维度去看这个问题，查询是否够快，效率是否稳定，存储数据多少，以及查找磁盘次数等等。为什么不是哈希结构？为什么不是二叉树，为什么不是平衡二叉树，为什么不是B树，而偏偏是B+树呢？

我们写业务SQL查询时，大多数情况下，都是范围查询的，如一下SQL

   select * from employee where age between 18 and 28;
复制代码

为什么不使用哈希结构？

我们知道哈希结构，类似k-v结构，也就是，key和value是一对一关系。它用于 等值查询还可以，但是范围查询它是无能为力的哦。

为什么不使用二叉树呢？

先回忆下二叉树相关知识啦~ 所谓 二叉树，特点如下：

每个结点最多两个子树，分别称为左子树和右子树。
左子节点的值小于当前节点的值，当前节点值小于右子节点值
顶端的节点称为跟节点，没有子节点的节点值称为叶子节点。

我们脑海中，很容易就浮现出这种二叉树结构图：

但是呢，有些特殊二叉树，它可能这样的哦：

如果二叉树特殊化为一个链表，相当于全表扫描。那么还要索引干嘛呀？因此，一般二叉树不适合作为索引结构。

为什么不使用平衡二叉树呢？

平衡二叉树特点：它也是一颗二叉查找树，任何节点的两个子树高度最大差为1。所以就不会出现特殊化一个链表的情况啦。

但是呢：

平衡二叉树插入或者更新是，需要左旋右旋维持平衡，维护代价大
如果数量多的话，树的高度会很高。因为数据是存在磁盘的，以它作为索引结构，每次从磁盘读取一个节点，操作IO的次数就多啦。

为什么不使用B树呢？

数据量大的话，平衡二叉树的高度会很高，会增加IO嘛。那为什么不选择同样数据量， 高度更矮的B树呢？

B树相对于平衡二叉树，就可以存储更多的数据，高度更低。但是最后为甚选择B+树呢？因为B+树是B树的升级版：

B+树非叶子节点上是不存储数据的，仅存储键值，而B树节点中不仅存储键值，也会存储数据。innodb中页的默认大小是16KB，如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的IO次数有会再次减少，数据查询的效率也会更快。
B+树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的，链表连着的。那么B+树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。

四、面试官考点之一次B+树索引搜索过程

面试官： 假设有以下表结构，并且有这几条数据

   CREATE TABLE `employee` (
  `id` int(11) NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  `date` datetime DEFAULT NULL,
  `sex` int(1) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_age` (`age`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

insert into employee values(100,'小伦',43,'2021-01-20','0');
insert into employee values(200,'俊杰',48,'2021-01-21','0');
insert into employee values(300,'紫琪',36,'2020-01-21','1');
insert into employee values(400,'立红',32,'2020-01-21','0');
insert into employee values(500,'易迅',37,'2020-01-21','1');
insert into employee values(600,'小军',49,'2021-01-21','0');
insert into employee values(700,'小燕',28,'2021-01-21','1');
复制代码

面试官： 如果执行以下的查询SQL，需要执行几次的树搜索操作？可以画下对应的索引结构图~

   select * from Temployee where age=32;
复制代码

解析： 其实这个，面试官就是考察候选人是否熟悉B+树索引结构图。可以像酱紫回答~

先画出 idx_age索引的索引结构图，大概如下：

再画出id主键索引，我们先画出聚族索引结构图，如下：

因此，这条 SQL 查询语句执行大概流程就是酱紫：

1. 搜索 idx_age索引树，将磁盘块1加载到内存，由于32<37,搜索左路分支，到磁盘寻址磁盘块2。
1. 将磁盘块2加载到内存中，在内存继续遍历，找到age=32的记录，取得id = 400.
1. 拿到id=400后，回到id主键索引树。
1. 搜索 id主键索引树，将磁盘块1加载内存，在内存遍历，找到了400，但是B+树索引非叶子节点是不保存数据的。索引会继续搜索400的右分支，到磁盘寻址磁盘块3.
1. 将磁盘块3加载内存，在内存遍历，找到id=400的记录，拿到R4这一行的数据，好的，大功告成。

因此，这个SQL查询，执行了几次树的搜索操作，是不是一步了然了呀。 特别的，在 idx_age二级索引树找到主键 id后，回到id主键索引搜索的过程,就称为回表。

什么是回表？拿到主键再回到主键索引查询的过程，就叫做回表

五、面试官考点之覆盖索引

面试官： 如果不用 select *, 而是使用 select id,age，以上的题目执行了几次树搜索操作呢？

解析： 这个问题，主要考察候选人的覆盖索引知识点。回到 idx_age索引树，你可以发现查询选项id和age都在叶子节点上了。因此，可以直接提供查询结果啦，根本就不需要再回表了~

覆盖索引：在查询的数据列里面，不需要回表去查，直接从索引列就能取到想要的结果。换句话说，你SQL用到的索引列数据，覆盖了查询结果的列，就算上覆盖索引了。

所以，相对于上个问题，就是省去了回表的树搜索操作。

六、面试官考点之索引失效

面试官： 如果我现在给 name字段加上普通索引，然后用个like模糊搜索，那会执行多少次查询呢？SQL如下：

   select * from employee where name like '%杰伦%';
复制代码

解析： 这里考察的知识点就是，like是否会导致不走索引，看先该SQL的explain执行计划吧。其实like 模糊搜索，会导致不走索引的，如下：

因此，这条SQL最后就全表扫描啦~日常开发中，这几种骚操作都可能会导致索引失效，如下：

查询条件包含or，可能导致索引失效
如何字段类型是字符串，where时一定用引号括起来，否则索引失效
like通配符可能导致索引失效。
联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
在索引列上使用mysql的内置函数，索引失效。
对索引列运算（如，+、-、*、/），索引失效。
索引字段上使用（！= 或者 < >，not in）时，可能会导致索引失效。
索引字段上使用is null， is not null，可能导致索引失效。
左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。
mysql估计使用全表扫描要比使用索引快,则不使用索引。

七、面试官考点联合索引之最左前缀原则

面试官： 如果我现在给name,age字段加上联合索引索引，以下SQL执行多少次树搜索呢？先画下索引树？

   select * from employee where name like '小%' order by age desc;
复制代码

解析： 这里考察联合索引的最左前缀原则以及like是否中索引的知识点。组合索引树示意图大概如下：

联合索引项是先按姓名name从小到大排序，如果名字name相同，则按年龄age从小到大排序。面试官要求查所有名字第一个字是“小”的人，SQL的like '小%'是可以用上 idx_name_age联合索引的。

该查询会沿着idx_name_age索引树，找到第一个字是小的索引值，因此依次找到 小军、小伦、小燕、，分别拿到Id= 600、100、700，然后回三次表，去找对应的记录。这里面的最左前缀 小，就是字符串索引的最左M个字符。实际上，

这个最左前缀可以是联合索引的最左N个字段。比如组合索引（a,b,c）可以相当于建了（a），（a,b）,(a,b,c)三个索引，大大提高了索引复用能力。
最左前缀也可以是字符串索引的最左M个字符。

八、面试官考点之索引下推

面试官： 我们还是居于组合索引 idx_name_age，以下这个SQL执行几次树搜索呢？

   select * from employee where name like '小%' and age=28 and sex='0';
复制代码

解析： 这里考察索引下推的知识点，如果是 Mysql5.6之前，在idx_name_age索引树，找出所有名字第一个字是“小”的人，拿到它们的主键id，然后回表找出数据行，再去对比年龄和性别等其他字段。如图：

有些朋友可能觉得奇怪，（name,age)不是联合索引嘛？为什么选出包含“小”字后，不再顺便看下年龄age再回表呢，不是更高效嘛？所以呀，MySQL 5.6 就引入了 索引下推优化，可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。

因此，MySQL5.6版本之后，选出包含“小”字后，顺表过滤age=28，,所以就只需一次回表。

九、面试官考点之大表添加索引

面试官： 如果一张表数据量级是千万级别以上的，那么，给这张表添加索引，你需要怎么做呢？

解析： 我们需要知道一点，给表添加索引的时候，是会对表加锁的。如果不谨慎操作，有可能出现生产事故的。可以参考以下方法：

1.先创建一张跟原表A数据结构相同的新表B。
2.在新表B添加需要加上的新索引。
3.把原表A数据导到新表B
4.rename新表B为原表的表名A，原表A换别的表名；

总结与练习

本文主要讲解了索引的9大关键知识点，希望对大家有帮助。接下来呢，给大家出一道，有关于我最近业务开发遇到的加索引SQL，看下大家是怎么回答的，有兴趣可以联系我哈~题目如下：

   
select * from A where type ='1' and status ='s' order by create_time desc;
复制代码

假设type有9种类型，区分度性还算可以，status的区分度不高（有3种类型），那么你是如何加索引呢？

是给type加单索引
还是（type，status，create_time）联合索引
还是（type，create_time）联合索引呢？

参看与感谢

搜索系统中的纠错问题

Fri, 12 Feb 2021 23:59:24 CST

纠错是搜索引擎中一个非常有特色的模块，对用户输入的内容进行改写从而让用户得到正确的结果，有的时候也会带有一些惊喜度，所以纠错技术是一个搜索体验的加分项，近期突然对这块有兴趣，所以就了解了一下。 （学习周报本周停，学习内容都在这了）

纠错技术的背景

人非圣贤，孰能无过，别说是搜索的时候，哪怕是我们打字、写作文的时候，都会出现错字，一般的错别字不会对最终目标带来很大影响，且出现频率很低，不拘小节的我们常常会忽略这样的小问题，但是，在搜索场景下，错别字意味着可能就搜不到内容了，对于用户而言，就是需求无法满足，造成了很差的体验，因此在搜索场景中，就很有必要去纠错。

错误是如何产生的

要去纠错，先要去看看错误是怎么产生的。

首先是误操作类型，这种类型可以从输入法角度去看。

拼音输入法。常会出现同音异形字，例如周节伦等。
笔画输入法或者手写输入法。常会出现形似字，例如博和傅。

然后是用户的主观理解，有的时候用户只是听说过而没见过，或者就是理解问题，导致主动地出入了错误的内容，例如飞扬拔（跋）扈，然后有一些名词，例如小说、音乐、电影等，写错字是非常容易的。

当然，也有用户图方便，或者输入问题，导致直接输入拼音或者拼音前缀，或者就是因为记忆的原因，输错了。

当然这里也要补充一些常见的问题举例：

谐音。深圳-森圳。
别字。师傅-师博。
中英文。Taylor swift-泰勒斯威夫特。
近义词。爱情呼叫转移-恋爱呼叫转移。
形近字。高粱-高梁。
全拼。深圳-shenzhen。
拼音前缀。北京-bj。
内容不完整。唐人街探案-唐人。

总之错误千奇百怪。理解错误产生的机理，我们就可以尝试去处理这些问题。

词典与规则方法

词典是搜索系统中非常常用的方法，词典具有高速、高准的优点，如果词典的覆盖度高，甚至可以达到高召回的效果，因此词典基本是搜索系统中的核心存在，我们不应该小看他，而是尽可能挖掘他的潜能。

词典方法，说白了就是对query找对应词典里有没有，如果有就改写过去，这种方法的优点在于速度快，而难点在于怎么去挖掘这个词典。

至于怎么挖掘这个词典，方法有很多底层数据库抽取，用户日志等，都有很多构建起这样的词典，能够大大降低耗时，复杂度至于query和单词长度有关。那么一般都有什么词典呢，我们来一个一个看看。

拼音和拼音前缀词典。先将query或者单词转为拼音，然后通过通过拼音召回对应的结果，完成纠错。
别字词典，记录一些常见的错别字，例如百度的形近词表就很不错（就在百度百科里面）。
其他改写字典。一般基于具体业务来改写，例如用户输入唐人街探案，其实唐人街探案有3部，我们应该给那个，需要基于热度等方面去改写到具体最合适的一部。

词典只是能够匹配到合适的结果，但是我们需要知道的是，改写的内容不能和原来差距太远，否则会出现很多意料之外的结果，因此改写不能大改，只能改微调，否则出来的结果会让用户感到很懵逼。控制的方法主要是 编辑距离。

所谓的编辑距离，就是改写前到改写后，需要经过的操作多少，说人话就是两句话的不同点有几个，精确到字级别。深圳-森圳的编辑距离就是1。通过编辑距离的约束，一般能够让两者的差距不是很大。

我知道很多人热衷于用语义相似度之类的操作，不管别的什么方法，编辑距离一定要约束，用户强调的是直观感受，语义相近与否不是他们第一个关心的，只有当字相近的结果不好的时候考虑语义相近才是用户的实际反映，且错别字带来的语义变化非常大，此处用予以相似度其实不完全合适。

模型类方法

说是词典和规则好处很多，但是在泛化能力上，模型还是很强的。那么在模型视角下，其实会分为下面3个步骤进行分析处理。

错误诊断。即判断有没有错。
修正召回。召回可能的修改项。保证召回率
修正确认。判断最终需要的修改项。保证准确率。

当然，如果模型足够强力，召回和确认两个步骤也可以合并，具体看准招和耗时了。

其实这个思路最广泛的应用就是推荐系统，召回和排序分离，这个我在大概是去年很早的一篇文章里谈到在这个，这是推荐系统里面非常重要的思想，这个思想其实在很多地方可以迁移：

技术向：推荐学习推荐系统（深度思考，不是广告）

至于模型层面，有下面的思路。

kenlm统计语言工具。运用统计学方法进行语言建模从而检测和修正错误。
rnn_attention。RNN加上attention还是一个非常有意思的方法。
rnn_crf模型：说起来你们可能不信，这个思路来自阿里2016参赛中文语法纠错比赛的第一名的方法。
seq2seq_attention模型：比RNN强一些，长文本效果不错，但是容易过拟合。
transformer：线性优秀的序列表征模型，大家懂的。
bert：中文微调，最妙的是mask可协助纠正错别字。
conv_seq2seq模型：基于Facebook出品的fairseq，在NLPCC-2018的中文语法纠错比赛中，是唯一使用单模型并取得第三名的成绩。

小结

怎么说呢，目前我还只是在探索，深度不是很够，后面有所补充，再和大家交流，参考文献放这里吧：

中文文本纠错算法--错别字纠正的二三事：https://zhuanlan.zhihu.com/p/40806718
pycorrector：https://github.com/shibing624/pycorrector
中文文本纠错算法走到多远了？：https://blog.csdn.net/sinat_26917383/article/details/86737361

由于微信平台算法改版，公号内容将不再以时间排序展示，如果大家想第一时间看到我们的推送，强烈建议星标我们和给我们多点点【在看】。星标具体步骤为：

（1）点击页面 最上方"AINLP"，进入公众号主页。

（2）点击 右上角的小点点，在弹出页面点击“ 设为星标”，就可以啦。

感谢支持，比心。

欢迎加入搜索技术交流群
进群请添加AINLP小助手微信 AINLPer（id: ainlper)，备注搜索技术

推荐阅读

这个NLP工具，玩得根本停不下来

征稿启示| 200元稿费+5000DBC（价值20个小时GPU算力）

完结撒花！李宏毅老师深度学习与人类语言处理课程视频及课件（附下载）

从数据到模型，你可能需要1篇详实的pytorch踩坑指南

如何让Bert在finetune小数据集时更“稳”一点

模型压缩实践系列之——bert-of-theseus，一个非常亲民的bert压缩方法

文本自动摘要任务的“不完全”心得总结番外篇——submodular函数优化

Node2Vec 论文+代码笔记

模型压缩实践收尾篇——模型蒸馏以及其他一些技巧实践小结

中文命名实体识别工具（NER）哪家强？

学自然语言处理，其实更应该学好英语

斯坦福大学NLP组Python深度学习自然语言处理工具Stanza试用

关于AINLP

AINLP 是一个有趣有AI的自然语言处理社区，专注于 AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享，主题包括文本摘要、智能问答、聊天机器人、机器翻译、自动生成、知识图谱、预训练模型、推荐系统、计算广告、招聘信息、求职经验分享等，欢迎关注！加技术交流群请添加AINLPer(id：ainlper)，备注工作/研究方向+加群目的。

阅读至此了，分享、点赞、在看三选一吧🙏

大幅降低存储成本，Elasticsearch可搜索快照是如何办到的？

Wed, 16 Dec 2020 19:26:44 CST

Elasticsearch 7.10 版本最近发布，该版本有一个重磅特性：Searchable snapshots （可搜索快照功能），可以大幅度地降低存储成本。那么 Searchable snapshots 的使用方式和实现效果是怎样的呢，下面就让我们来一探究竟吧！

一、功能介绍

在 Searchable snapshots 可搜索快照功能发布之前，通过调用 _snapshot API 对索引打的快照，不管是存储在 S3 还是 HDFS 或者是腾讯云的对象存储 COS上，都是不能够直接进行查询的。

快照只能用于数据的冷备份，如果要查询的话需要先调用 API 把快照恢复到集群中，当快照中的索引初始化完成后，才可以去查询。

而可搜索快照功能就使得存储在远端 S3、HDFS、COS 中的快照能够满足查询的需求了，ES 的数据文件不是只能存储在本地文件系统上，还可以支持存储在远端的 S3、HDFS、COS 等存储介质上，实际上实现了存储与计算的分离。

Searchable snapshots 可搜索快照功能预计会给 ES 带来新的繁荣，因为有非常多的用户使用 ELK 架构构建日志系统。日志的数据量是非常大的，但是查询的频率一般比较低，所以用户的痛点是：在满足基本查询需求的条件下同时降低 ES 的存储成本。

现在基于 Searchable snapshots 可搜索快照功能，可以把大量的比较旧的索引都存储到 S3/COS 上，真正需要查询的时候可以去查询 S3/COS 中的数据。因为 S3/COS 本身成本是非常低的，大约只有 SSD 磁盘的十分之一，所以使用 ES 存储数据的成本大大降低了。

另外一方面，可搜索快照功能也可以提高集群的稳定性，可以仅仅使用一个较小规模的集群支撑最近一段时间热索引的读写即可，老的索引都可以存放在 S3/COS 中，真正需要查询的时候再去查 S3/COS 中的数据，因为集群规模小，不至于出现一个超大规模的集群存储所有的数据，从而导致集群不稳定的现象发生。

不过就当前 7.10 版本的可搜索快照功能的特点来看，没有我们预想的可以完全实现存储计算分离。

因为当把一个存储在 S3/COS 上的快照 mount 到一个集群中时，需要先执行快照恢复，把快照中的文件从 S3/COS 读取到集群的本地磁盘上，快照中的索引先进行初始化，索引所有的数据文件恢复完毕后该索引才变为 green。

看起来和我们手动去从快照中恢复索引没有什么两样，区别在于 Searchable snapshots 可搜索快照功能时，在执行快照恢复的这段过程中索引仍然是可以查询的。如果集群本地磁盘上的索引文件不存在的话就直接去 S3/COS 中去读，只不过读的过程会比较慢。

而为什么需要先把数据文件从 S3/COS 恢复到本地呢？官方的解释是这样可以保证查询性能，在一个可搜索快照中的索引完全初始化完成后，读取该索引和读取普通的索引的性能几乎没有差别。实际上可搜索快照类型的索引在集群的本地磁盘上存放了完整的一份数据文件，只不过命名规则和普通的索引不一样。

因为当前 7.10 版本的可搜索快照功能，数据还需要从 S3/COS 中恢复到集群的本地磁盘上缓存一份，所以该功能真正的用处在于可以节省最多一半的存储空间。可搜索快照类型的索引在集群中默认副本数为 0，数据的可靠性以及弹性完全交由 S3/COS 来保证，不需要额外给索引增加副本，从而可以降低一半的存储成本。

当集群中可搜索快照类型的索引的分片因为节点故障不可用时， ES 会自动地从 S3/COS 中读取分片对应的数据文件进行恢复，从而保证数据的可靠性；如果需要提高可搜索快照类型的索引的副本数量，也是直接从 S3/COS 中读取数据，而不是从本地磁盘上复制主分片的数据文件。

利用当前版本的可搜索快照功能，我们可以对一些老的查询频率非常低的索引，先备份到 S3/COS，之后删除，然后再把备份好的快照 mount 到集群中，使得这些索引下需要的时候仍然可以查询。

在极端情况下，实际上只需要对这些老的查询频率非常低的索引，只进行备份，真正需要查询的时候再 mount 到集群上，当然，需要容忍缓慢的查询过程。

当前 7.10 版本的可搜索快照功能的为 Beta 版，社区里也给出了该功能的路线图，会在将来的版本中实现完全的计算存储分离，直接去访问 S3/COS 中的索引数据完成查询, 而不是像当前这个版本需要先恢复到本地磁盘中。

所以总的来说，当前 7.10 版本的可搜索快照功能，一方面可以降低一半左右的存储空间，大大的节省了成本；另外一方面保证了从快照中恢复到集群上的索引的查询性能，使得应用层不必感知到这种新的存储方式带来的变化。

二、使用方式

可搜索快照的使用方式比较简单，我们可以选择通过手动调用 API 来把远端的快照 mount 到集群中，也可以在 ILM中使用。

1. 手动munt快照

直接调用API:

POST /_snapshot/my_repository/my_snapshot/_mount?wait_for_completion=true { "index": "test", "renamed_index": "test1", "index_settings": { "index.number_of_replicas": 0 }, "ignored_index_settings": [ "index.refresh_interval" ] }

上述操作把快照 my_snapshot 中的 test 索引挂载到集群中，重命名为 test1, 挂载后的索引副本数设置为 0，同时忽略掉旧索引中设置的 index.refresh_interval 参数。

在执行完上述操作后，可以看到集群中出现了一个新的索引 test1, 集群当前状态为 yellow，test 索引的分片执行初始化，初始化完成后，test1 索引状态变为 green。

此时查看新索引 test1 的 settings，发现其和普通的索引有以下不同点：

{ "test1":{ "settings":{ "index": { "blocks":{ "write":"true" }, "recovery":{ "type":"snapshot_prewarm" }, "store":{ "type":"snapshot", "snapshot":{ "snapshot_name":"test", "index_uuid":"p1Opq7gdQz6WTeKgiIEaTw", "index_name":"test-aggregation-2020-11-25-02", "repository_name":"my_repository2", "snapshot_uuid":"Muy7vsiLSWKbQf3mJALfLw" } } } } } }

index.blocks.write 默认为 true，也即可搜索快照索引默认是只读的；index.recovery.type 为 snapshot_prewarm, 意味着数据是从快照中恢复的；index.store.type 为 snapshot，区别于普通索引的 fs 方式。

另外需要注意的是，索引 test1 恢复到 green 后，除了索引的部分元数据和底层的数据文件命名方式与普通的索引不同，索引自身的一些数据结构如 FST 也是常驻内存的，并不会在查询完毕后自动释放掉内存，所以此时已经和普通的索引区别不大了。当然，新索引test1也是可以冻结的，冻结的执行过程和普通的索引相同。

2. 在ILM中使用

在 ILM 索引生命周期管理中也可以使用可搜索快照功能，通过 API 使用该功能的基本用法如下：

PUT _ilm/policy/my_policy { "policy": { "phases": { "cold": { "actions": { "searchable_snapshot" : { "snapshot_repository" : "my_repository", "force_merge_index": true } } } } } }

对于使用上述 ILM 策略的索引，在 cold phase 会首先把该索引备份到指定的快照仓库 my_repository 中，然后再把快照中的索引挂载为一个可搜索快照的索引。

使用过程中需要注意以下几点：

可搜索快照只能在cold phase使用；如果 ILM 策略有配置 delete phase，默认情况下，在 delete phase 会主动删除 cold phase 中的可搜索快照, 因此需要在 delete phase 中显式设置 delete_searchable_snapshot 为 false；默认情况下 force_merge_index 为 true, 也即在索引进入到 cold phase 时，会先把索引 force merge 到 1 个 segment，然后再备份到快照仓库中。此举一方面是为了降低存储到 S3/COS 上的存储成本，同时降低后续从 S3/COS 中拉取数据时的产生的费用，文件越少读取 S3/COS 产生的费用就越低；另外一方面当数据从 S3/COS 恢复到本地后，也可以获得较好的查询性能。

比较遗憾的是，在当前 7.10 版本中，还不支持直接在 kibana 的索引生命周期管理页面中通过操作界面直接使用可搜索快照功能。

三、未来展望

Searchable snapshots 可搜索快照功能，在当前 Beta 版本中，仍然需要把存储在远端 S3/COS 中的数据恢复到本地缓存起来，所以可以节省的存储成本是有限的。所以，官方也给出了可搜索快照功能的路线图：

结合 Data tiers 数据分层功能我们看到，当前 Beta 版的可搜索快照是用在数据分层的 Cold 层，在该层中的索引一般是只读的，但是仍然需要保证一定的查询性能。

所以在 Cold 层可以把数据先从 S3/COS 中恢复到集群的本地磁盘上，做一层缓存，查询索引的时候优先从本地缓存中读取，这样查询性能就有了保证。

但是数据的可靠性或者弹性可以完全由 S3/COS 来保证，因此在 Cold 层中的索引，可以只保留主分片，当主分片所在的节点故障时可以从远端的 S3/COS 中恢复数据，这样存储成本就降低了一半。

而官方未来的规划，是要开发 Frozen 层，在该层中的索引，对查询性能没有较高的要求，因此可以直接去查询 S3/COS 中的数据，而不需要再把数据从 S3/COS 中恢复到本地缓存起来。

因此在 Frozen 层，才真正实现了存储与计算的分离，带来的影响是不可估量的，因为一个集群能够支撑的数据存储量可以无限大，用户的成本可以大大的降低。

然而，在 Frozen 层，直接去查询存储在 S3/COS 上的数据，查询性能就完全取决于 S3/COS 的 API 接口的性能，可能会造成查询过程非常缓慢。

而在早先的版本中，ES 已经实现了异步查询 Async search, 提交查询请求时只返回一个 ID, 后续通过轮询这个 ID 获取到查询结果，在轮询过程中可以获取到查询的部分结果，直至查询结果完全返回。因此 Async search 就解决了在 Frozen 层因为查询数据缓慢带来的的体验效果不好的问题。

所以，在将来 Frozen 层开发完成之后，我们可以借助于完全实现存储于计算分离的可搜索快照功能，根据需要从 S3/COS 中去查询数据，真正做到按需加载。查询完毕后，此次查询而加载的内存数据将会自动释放，不仅节省了大量的存储成本，也因为集群的规模可以变得非常小而使得集群的稳定性大大地提高。

总的来说，不光是 Searchable sanpshots 功能，还有 Data tiers 数据分层功能，都还在逐渐演进的路上，两者结合起来，将会给 Elasticsearch 带来革命性的变革！

头图：Unsplash

作者：高斌龙 - 腾讯云大数据研发工程师

原文：大幅降低存储成本，Elasticsearch可搜索快照是如何办到的？"

来源：云加社区 - 微信公众号 [ID：QcloudCommunity]

转载：著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

分布式搜索引擎Elasticsearch的架构分析

Tue, 08 Dec 2020 01:51:12 CST

一、写在前面

ES（Elasticsearch下文统一称为ES）越来越多的企业在业务场景是使用ES存储自己的非结构化数据，例如电商业务实现商品站内搜索，数据指标分析，日志分析等，ES作为传统关系型数据库的补充，提供了关系型数据库不具备的一些能力。

ES最先进入大众视野的是其能够实现全文搜索的能力，也是由于基于Lucene的实现，内部有一种倒排索引的数据结构。

本文作者将介绍ES的分布式架构，以及ES的存储索引机制，本文不会详细介绍ES的API，会从整体架构层面进行分析，后续作者会有其他文章对ES的使用进行介绍。

二、什么是倒排索引

要讲明白什么是倒排索引，首先我们先梳理下什么索引，比如一本书，书的目录页，有章节，章节名称，我们想看哪个章节，我们通过目录页，查到对应章节和页码，就能定位到具体的章节内容，通过目录页的章节名称查到章节的页码，进而看到章节内容，这个过程就是一个索引的过程，那么什么是倒排索引呢？

比如查询《java编程思想》这本书的文章，翻开书本可以看到目录页，记录这个章节名字和章节地址页码，通过查询章节名字“继承”可以定位到“继承”这篇章节的具体地址，查看到文章的内容，我们可以看到文章内容中包含很多“对象”这个词。

那么如果我们要在这本书中查询所有包含有“对象”这个词的文章，那该怎么办呢？

按照现在的索引方式无疑大海捞针，假设我们有一个“对象”--→文章的映射关系，不就可以了吗？类似这样的反向建立映射关系的就叫倒排索引。

如图1所示，将文章进行分词后得到关键词，在根据关键词建立倒排索引，关键词构建成一个词典，词典中存放着一个个词条（关键词），每个关键词都有一个列表与其对应，这个列表就是倒排表，存放的是章节文档编号和词频等信息，倒排列表中的每个元素就是一个倒排项，最后可以看到，整个倒排索引就像一本新华字典，所有单词的倒排列表往往顺序地存储在磁盘的某个文件里，这个文件被称之为倒排文件。

（图1）

词典和倒排文件是Lucene的两种基本数据结构，但是存储方式不同，词典在内存中存储，倒排文件在磁盘上。本文不会去介绍分词，tf-idf，BM25，向量空间相似度等构建倒排索引和查询倒排索引所用到的技术，读者只需要对倒排索引有个基本的认识即可。

三、ES的集群架构

1. 集群节点

一个ES集群可以有多个节点构成，一个节点就是一个ES服务实例，通过配置集群名称cluster.name加入集群。那么节点是如何通过配置相同的集群名称加入集群的呢？要搞明白这个问题，我们必须先搞清楚ES集群中节点的角色。

ES中节点有角色的区分的，通过配置文件conf/elasticsearch.yml中配置以下配置进行角色的设定。

   node.master: true/false
node.data: true/false
复制代码

集群中单个节点既可以是候选主节点也可以是数据节点，通过上面的配置可以进行两两组合形成四大分类：

（1）仅为候选主节点
（2）既是候选主节点也是数据节点
（3）仅为数据节点
（4）既不是候选主节点也不是数据节点

**候选主节点：**只有是候选主节点才可以参与选举投票，也只有候选主节点可以被选举为主节点。

**主节点：**负责索引的添加、删除，跟踪哪些节点是群集的一部分，对分片进行分配、收集集群中各节点的状态等，稳定的主节点对集群的健康是非常重要。

**数据节点：**负责对数据的增、删、改、查、聚合等操作，数据的查询和存储都是由数据节点负责，对机器的CPU，IO以及内存的要求比较高，一般选择高配置的机器作为数据节点。

此外还有一种节点角色叫做 协调节点，其本身不是通过设置来分配的，用户的请求可以随机发往任何一个节点，并由该节点负责分发请求、收集结果等操作，而不需要主节点转发。这种节点可称之为协调节点，集群中的任何节点都可以充当协调节点的角色。每个节点之间都会保持联系。

（图2）

2. 发现机制

前文说到通过设置一个集群名称，节点就可以加入集群，那么ES是如何做到这一点的呢？

这里就要讲一讲ES特殊的发现机制ZenDiscovery。

ZenDiscovery是ES的内置发现机制，提供单播和多播两种发现方式，主要职责是集群中节点的发现以及选举Master节点。

多播也叫组播，指一个节点可以向多台机器发送请求。生产环境中ES不建议使用这种方式，对于一个大规模的集群，组播会产生大量不必要的通信。

单播，当一个节点加入一个现有集群，或者组建一个新的集群时，请求发送到一台机器。当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系Master节点，并加入集群。

只有在同一台机器上运行的节点才会自动组成集群。ES 默认被配置为使用单播发现，单播列表不需要包含集群中的所有节点，它只是需要足够的节点，当一个新节点联系上其中一个并且通信就可以了。如果你使用 Master 候选节点作为单播列表，你只要列出三个就可以了。

这个配置在 elasticsearch.yml 文件中：

   discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]
复制代码

集群信息收集阶段采用了 Gossip 协议，上面配置的就相当于一个seed nodes，Gossip协议这里就不多做赘述了。

ES官方建议unicast.hosts配置为所有的候选主节点，ZenDiscovery 会每隔ping_interval（配置项）ping一次，每次超时时间是discovery.zen.ping_timeout（配置项），3次(ping_retries配置项)ping失败则认为节点宕机，宕机的情况下会触发failover，会进行分片重分配、复制等操作。

如果宕机的节点不是Master，则Master会更新集群的元信息，Master节点将最新的集群元信息发布出去，给其他节点，其他节点回复Ack，Master节点收到discovery.zen.minimum_master_nodes的值-1个候选主节点的回复，则发送Apply消息给其他节点，集群状态更新完毕。如果宕机的节点是Master，则其他的候选主节点开始Master节点的选举流程。

2.1 选主

Master的选主过程中要确保只有一个master，ES通过一个参数quorum的代表多数派阈值，保证选举出的master被至少quorum个的候选主节点认可，以此来保证只有一个master。

选主的发起由候选主节点发起，当前候选主节点发现自己不是master节点，并且通过ping其他节点发现无法联系到主节点，并且包括自己在内已经有超过minimum_master_nodes个节点无法联系到主节点，那么这个时候则发起选主。

选主流程图

（图3）

选主的时候按照集群节点的参数排序。stateVersion从大到小排序，以便选出集群元信息较新的节点作为Master，id从小到大排序，避免在stateVersion相同时发生分票无法选出 Master。

排序后第一个节点即为Master节点。当一个候选主节点发起一次选举时，它会按照上述排序策略选出一个它认为的Master。

2.2 脑裂

提到分布式系统选主，不可避免的会提到脑裂这样一个现象，什么是脑裂呢？如果集群中选举出多个Master节点，使得数据更新时出现不一致，这种现象称之为脑裂。

简而言之集群中不同的节点对于 Master的选择出现了分歧，出现了多个Master竞争。

一般而言脑裂问题可能有以下几个原因造成：

**网络问题：**集群间的网络延迟导致一些节点访问不到Master，认为Master 挂掉了，而master其实并没有宕机，而选举出了新的Master，并对Master上的分片和副本标红，分配新的主分片。
**节点负载：**主节点的角色既为Master又为Data，访问量较大时可能会导致 ES 停止响应（假死状态）造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。
**内存回收：**主节点的角色既为Master又为Data，当Data节点上的ES进程占用的内存较大，引发JVM的大规模内存回收，造成ES进程失去响应。

如何避免脑裂：我们可以基于上述原因，做出优化措施：

适当调大响应超时时间，减少误判。通过参数 discovery.zen.ping_timeout 设置节点ping超时时间，默认为 3s，可以适当调大。
选举触发，我们需要在候选节点的配置文件中设置参数 discovery.zen.munimum_master_nodes 的值。这个参数表示在选举主节点时需要参与选举的候选主节点的节点数，默认值是 1，官方建议取值(master_eligibel_nodes/2)+1，其中 master_eligibel_nodes 为候选主节点的个数。这样做既能防止脑裂现象的发生，也能最大限度地提升集群的高可用性，因为只要不少于 discovery.zen.munimum_master_nodes 个候选节点存活，选举工作就能正常进行。当小于这个值的时候，无法触发选举行为，集群无法使用，不会造成分片混乱的情况。
角色分离，即是上面我们提到的候选主节点和数据节点进行角色分离，这样可以减轻主节点的负担，防止主节点的假死状态发生，减少对主节点宕机的误判。

四、索引如何写入的

1. 写索引原理

1.1 分片

ES支持PB级全文搜索，通常我们数据量很大的时候，查询性能都会越来越慢，我们能想到的一个方式的将数据分散到不同的地方存储，ES也是如此，ES通过水平拆分的方式将一个索引上的数据拆分出来分配到不同的数据块上，拆分出来的数据库块称之为一个分片Shard，很像MySQL的分库分表。

不同的主分片分布在不同的节点上，那么在多分片的索引中数据应该被写入哪里？肯定不能随机写，否则查询的时候就无法快速检索到对应的数据了，这需要有一个路由策略来确定具体写入哪一个分片中，怎么路由我们下文会介绍。在创建索引的时候需要指定分片的数量，并且分片的数量一旦确定就不能修改。

1.2 副本

副本就是对分片的复制，每个主分片都有一个或多个副本分片，当主分片异常时，副本可以提供数据的查询等操作。主分片和对应的副本分片是不会在同一个节点上的，避免数据的丢失，当一个节点宕机的时候，还可以通过副本查询到数据，副本分片数的最大值是 N-1（其中 N 为节点数）。

对doc的新建、索引和删除请求都是写操作，这些写操作是必须在主分片上完成，然后才能被复制到对应的副本上。ES为了提高写入的能力这个过程是并发写的，同时为了解决并发写的过程中数据冲突的问题，ES通过乐观锁的方式控制，每个文档都有一个 _version号，当文档被修改时版本号递增。

一旦所有的副本分片都报告写成功才会向协调节点报告成功，协调节点向客户端报告成功。

（图4）

1.3 Elasticsearch 的写索引流程

上面提到了写索引是只能写在主分片上，然后同步到副本分片，那么如图4所示，这里有四个主分片分别是S0、S1、S2、S3，一条数据是根据什么策略写到指定的分片上呢？这条索引数据为什么被写到S0上而不写到 S1 或 S2 上？这个过程是根据下面这个公式决定的。

   shard = hash(routing) % number_of_primary_shards
复制代码

以上公式的值是在0到number_of_primary_shards-1之间的余数，也就是数据档所在分片的位置。routing通过Hash函数生成一个数字，然后这个数字再除以number_of_primary_shards（主分片的数量）后得到余数。routing是一个可变值，默认是文档的_id ，也可以设置成一个自定义的值。

在一个写请求被发送到某个节点后，该节点按照前文所述，会充当协调节点，会根据路由公式计算出写哪个分片，当前节点有所有其他节点的分片信息，如果发现对应的分片是在其他节点上，再将请求转发到该分片的主分片节点上。

在ES集群中每个节点都通过上面的公式知道数据的在集群中的存放位置，所以每个节点都有接收读写请求的能力。

那么为什么在创建索引的时候就确定好主分片的数量，并且不可修改？因为如果数量变化了，那么所有之前路由计算的值都会无效，数据也就再也找不到了。

（图5）

如上图5所示，当前一个数据通过路由计算公式得到的值是 shard=hash(routing)%4=0，则具体流程如下：

（1）数据写请求发送到 node1 节点，通过路由计算得到值为1，那么对应的数据会应该在主分片S1上。
（2）node1节点将请求转发到 S1 主分片所在的节点node2，node2 接受请求并写入到磁盘。
（3）并发将数据复制到三个副本分片R1上，其中通过乐观并发控制数据的冲突。一旦所有的副本分片都报告成功，则节点 node2将向node1节点报告成功，然后node1节点向客户端报告成功。

这种模式下，只要有副本在，写入延时最小也是两次单分片的写入耗时总和，效率会较低，但是这样的好处也很明显，避免写入后单个机器硬件故障导致数据丢失，在数据完整性和性能方面，一般都是优先选择数据，除非一些允许丢数据的特殊场景。

在ES里为了减少磁盘IO保证读写性能，一般是每隔一段时间（比如30分钟）才会把数据写入磁盘持久化，对于写入内存，但还未flush到磁盘的数据，如果发生机器宕机或者掉电，那么内存中的数据也会丢失，这时候如何保证？

对于这种问题，ES借鉴数据库中的处理方式，增加CommitLog模块，在ES中叫transLog，在下面的ES存储原理中会介绍。

2. 存储原理

上面介绍了在ES内部的写索引处理流程，数据在写入到分片和副本上后，目前数据在内存中，要确保数据在断电后不丢失，还需要持久化到磁盘上。

我们知道ES是基于Lucene实现的，内部是通过Lucene完成的索引的创建写入和搜索查询，Lucene 工作原理如下图所示，当新添加一片文档时，Lucene进行分词等预处理，然后将文档索引写入内存中，并将本次操作写入事务日志（transLog），transLog类似于mysql的binlog，用于宕机后内存数据的恢复，保存未持久化数据的操作日志。

默认情况下，Lucene每隔1s(refresh_interval配置项)将内存中的数据刷新到文件系统缓存中，称为一个segment（段）。一旦刷入文件系统缓存，segment才可以被用于检索，在这之前是无法被检索的。

因此refresh_interval决定了ES数据的实时性，因此说ES是一个准实时的系统。segment 在磁盘中是不可修改的，因此避免了磁盘的随机写，所有的随机写都在内存中进行。随着时间的推移，segment越来越多，默认情况下，Lucene每隔30min或segment 空间大于512M，将缓存中的segment持久化落盘，称为一个commit point，此时删掉对应的transLog。

当我们在进行写操作的测试的时候，可以通过手动刷新来保障数据能够被及时检索到，但是不要在生产环境下每次索引一个文档都去手动刷新，刷新操作会有一定的性能开销。一般业务场景中并不都需要每秒刷新。

可以通过在 Settings 中调大 refresh_interval = "30s" 的值，来降低每个索引的刷新频率，设值时需要注意后面带上时间单位，否则默认是毫秒。当 refresh_interval=-1 时表示关闭索引的自动刷新。

（图6）

索引文件分段存储并且不可修改，那么新增、更新和删除如何处理呢？

新增，新增很好处理，由于数据是新的，所以只需要对当前文档新增一个段就可以了。
删除，由于不可修改，所以对于删除操作，不会把文档从旧的段中移除而是通过新增一个 .del 文件，文件中会列出这些被删除文档的段信息，这个被标记删除的文档仍然可以被查询匹配到，但它会在最终结果被返回前从结果集中移除。
更新，不能修改旧的段来进行文档的更新，其实更新相当于是删除和新增这两个动作组成。会将旧的文档在 .del 文件中标记删除，然后文档的新版本中被索引到一个新的段。可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就会被移除。

segment被设定为不可修改具有一定的优势也有一定的缺点。

优点：

不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。

一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升.

其它缓存(像 Filter 缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。

写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和需要被缓存到内存的索引的使用量。

缺点：

当对旧数据进行删除时，旧数据不会马上被删除，而是在 .del 文件中被标记为删除。而旧数据只能等到段更新时才能被移除，这样会造成大量的空间浪费。

若有一条数据频繁的更新，每次更新都是新增新的，标记旧的，则会有大量的空间浪费。

每次新增数据时都需要新增一个段来存储数据。当段的数量太多时，对服务器的资源例如文件句柄的消耗会非常大。

在查询的结果中包含所有的结果集，需要排除被标记删除的旧数据，这增加了查询的负担。

2.1 段合并

由于每当刷新一次就会新建一个segment（段），这样会导致短时间内的段数量暴增，而segment数目太多会带来较大的麻烦。大量的segment会影响数据的读性能。每一个segment都会消耗文件句柄、内存和CPU 运行周期。

更重要的是，每个搜索请求都必须轮流检查每个segment然后合并查询结果，所以segment越多，搜索也就越慢。

因此Lucene会按照一定的策略将segment合并，合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档不会被拷贝到新的大segment中。

合并的过程中不会中断索引和搜索，倒排索引的数据结构使得文件的合并是比较容易的。

段合并在进行索引和搜索时会自动进行，合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中，这些段既可以是未提交的也可以是已提交的。

合并结束后老的段会被删除，新的段被刷新到磁盘，同时写入一个包含新段且排除旧的和较小的段的新提交点，新的段被打开，可以用来搜索。段合并的计算量庞大，而且还要吃掉大量磁盘 I/O，并且段合并会拖累写入速率，如果任其发展会影响搜索性能。

ES在默认情况下会对合并流程进行资源限制，所以搜索性能可以得到保证。

（图7）

五、写在最后

作者对ES的架构原理和索引存储和写机制进行介绍，ES的整体架构体系相对比较巧妙，我们在进行系统设计的时候可以借鉴其设计思路，本文只介绍ES整体架构部分，更多的内容，后续作者会在其他文章中继续分享。

作者：vivo官网商城开发团队

FAISS + SBERT实现的十亿级语义相似性搜索

Sat, 14 Nov 2020 10:30:00 CST

译者：AI研习社（ FIONAbiubiu）

双语原文链接： Billion-scale semantic similarity search with FAISS+SBERT

介绍

语义搜索是一种关注句子意义而不是传统的关键词匹配的信息检索系统。尽管有许多文本嵌入可用于此目的，但将其扩展到构建低延迟api以从大量数据集合中获取数据是很少讨论的。在本文中，我将讨论如何使用SOTA语句嵌入（语句转换器）和 FAISS来实现最小语义搜索引擎。

句子Transformers

它是一个框架或一组模型，给出句子或段落的密集向量表示。这些模型是transformer网络（BERT、RoBERTa等），它们专门针对语义文本相似性的任务进行了微调，因为BERT在这些任务中执行得不是很好。下面给出了不同模型在STS基准测试中的性能。

图片来源：句子 transformers

我们可以看到句子transformer模型比其他模型有很大的优势。

但是如果你用代码和 GLUE来看看排行榜，你会看到很多的模型超过90。为什么我们需要句子transformers？

在这些模型中，语义文本相似度被视为一个回归任务。这意味着，每当我们需要计算两个句子之间的相似度得分时，我们需要将它们一起传递到模型中，然后模型输出它们之间的数值分数。虽然这对于基准测试很有效，但是对于实际的用例来说，它的伸缩性很差，原因如下。

1.当你需要搜索大约10k个文档时，你需要进行10k个独立的推理计算，不可能单独计算嵌入量而只计算余弦相似度。见作者的解释。
2.最大序列长度（模型一次可以接受的单词/标记的总数）在两个文档之间共享，这会导致的表示的含义由于分块而被稀释

FAISS

Faiss是一个基于C++的库，由FacebookAI构建，在Python中有完整的包装器，用于索引矢量化数据并对其进行有效的搜索。Faiss基于以下因素提供了不同的索引。

搜索时间
搜索质量
每个索引向量使用的内存
训练时间
无监训练需要外部数据

因此，选择合适的指数将是这些因素之间的权衡。

加载模型并对数据集执行推理

首先，让我们安装并加载所需的库

!pip install faiss-cpu
!pip install -U sentence-transformersimport numpy as np
import torch
import os
import pandas as pd
import faiss
import time
from sentence_transformers import SentenceTransformer

加载一个包含一百万个数据点的数据集

我使用了一个来自Kaggle的数据集，其中包含了17年来出版的新闻标题。

df=pd.read_csv("abcnews-date-text.csv")
data=df.headline_text.to_list()

加载预训练模型并且进行推断

model = SentenceTransformer('distilbert-base-nli-mean-tokens')encoded_data = model.encode(data)

为数据集编制索引

我们可以根据我们的用例通过参考指南来选择不同的索引选项。

让我们定义索引并向其添加数据

index = faiss.IndexIDMap(faiss.IndexFlatIP(768))index.add_with_ids(encoded_data, np.array(range(0, len(data))))

序列化索引

faiss.write_index(index, 'abc_news')

将序列化的索引导出到托管搜索引擎的任何计算机中

反序列化索引

index = faiss.read_index('abc_news')

执行语义相似性搜索

让我们首先为搜索构建一个包装函数

def search(query):
t=time.time()
query_vector = model.encode([query])
k = 5
top_k = index.search(query_vector, k)
print('totaltime: {}'.format(time.time()-t))
return [data[_id] for _id in top_k[1].tolist()[0]]

执行搜索

query=str(input())
results=search(query)
print('results :')
for result in results:
print('\t'

CPU中的结果

现在让我们看看搜索结果和响应时间

只需1.5秒，就可以在仅使用CPU后端的百万文本文档的数据集上执行基于意义的智能搜索。

GPU中的结果

首先让我们关闭CPU版本的Faiss并重启GPU版本

!pip uninstall faiss-cpu
!pip install faiss-gpu

之后执行相同步骤，但是最后将索引移到GPU上。

res = faiss.StandardGpuResources()
gpu_index = faiss.index_cpu_to_gpu(res, 0, index)

现在让我们转移这个搜索方法并用GPU执行这个搜索

很好，你可以在0.02秒内得到结果，使用GPU（在这个实验中使用了Tesla T4），它比CPU后端快75倍

但是为什么我不能仅仅序列化编码数据的NumPy数组而不是索引它们呢？如果我能等几秒钟的话，使用余弦相似性呢？

因为NumPy没有序列化函数，因此唯一的方法是将其转换为JSON，然后保存JSON对象，但是大小将增加五倍。例如，在768维向量空间中编码的一百万个数据点具有正常的索引，大约为3GB，将其转换为JSON将使其成为15GB，而普通机器无法保存它的RAM。因此，每次执行搜索时，我们都要运行一百万次计算推理，这是不实际的。

最后的想法

这是一个基本的实现，在语言模型部分和索引部分仍然需要做很多工作。有不同的索引选项，应该根据用例、数据大小和可用的计算能力选择正确的索引选项。另外，这里使用的句子嵌入只是对一些公共数据集进行了微调，在特定领域的数据集上对它们进行微调可以改进，从而提高搜索结果。

参考文献

[1] Nils Reimers and Iryna Gurevych. “ Making Monolingual Sentence Embeddings Multilingual using Knowledge Distillation .” arXiv (2020): 2004.09813.

[2]Johnson, Jeff and Douze, Matthijs and J{\’e}gou, Herv{\’e} . “ Billion-scale similarity search with GPUs ” arXiv preprint arXiv:1702.08734 .

AI研习社是AI学术青年和AI开发者技术交流的在线社区。我们与高校、学术机构和产业界合作，通过提供学习、实战和求职服务，为AI学术青年和开发者的交流互助和职业发展打造一站式平台，致力成为中国最大的科技创新人才聚集地。

如果，你也是位热爱分享的AI爱好者。欢迎与译站一起，学习新知，分享成长。

网盘资源搜索网站合集

Mon, 26 Oct 2020 11:41:48 CST

百度网盘资源搜索

小马盘搜索： https://www.xiaomapan.com/
- 使用要求：免费
- 网盘搜索自动跳转脚本
酷搜： https://www.kolsou.com/
- 使用要求：免费
轻舟网： https://www.qzhou.com.cn/
- 使用要求：免费
大圣盘： https://www.dashengpan.com/
- 使用要求：扫码关注公众号
- https://greasyfork.org/zh-CN/scripts/398352 之前这个脚本是大力盘的，可以免关注公众号获得百度网盘地址，但是失效了，根据脚本代码，可以在chrome类的浏览器使用 F12 - Console - 输入 __NUXT__.data[0].url
- 罗马盘/大力盘/大圣盘等网站，暴力破解，绕过付费| 备份
- 大圣盘-大力盘-罗马盘绕过限制搜索查看百度网盘资源脚本
大力盘： https://www.dalipan.com/
- 使用要求：扫码关注公众号
- https://greasyfork.org/zh-CN/scripts/398352 之前这个脚本可以免关注公众号获得百度网盘地址，但是失效了，根据脚本代码，可以在chrome类的浏览器使用 F12 - Console - 输入 __NUXT__.data[0].url
- 罗马盘/大力盘/大圣盘等网站，暴力破解，绕过付费| 备份
- 大圣盘-大力盘-罗马盘绕过限制搜索查看百度网盘资源脚本
- 大力盘\小白盘自动跳转脚本
罗马盘： https://www.luomapan.com/
- 使用要求：扫码关注公众号
- https://greasyfork.org/zh-CN/scripts/398352 之前这个脚本是大力盘的，可以免关注公众号获得百度网盘地址，但是失效了，根据脚本代码，可以在chrome类的浏览器使用 F12 - Console - 输入 __NUXT__.data[0].url
- 罗马盘/大力盘/大圣盘等网站，暴力破解，绕过付费| 备份
- 大圣盘-大力盘-罗马盘绕过限制搜索查看百度网盘资源脚本
小鸟盘： https://www.birdiesearch.com/
- 使用要求：购买邀请码5元
猪猪盘： http://www.zhuzhupan.com/
- 使用要求：购买5元一天不限次数
凌风云： https://www.lingfengyun.com/
- 使用要求：购买VIP
去转盘： https://www.quzhuanpan.com/
- 使用要求：扫码关注公众号（每天免费下载3个资源）或者购买VIP（17元=45天）
小白盘： https://www.xiaobaipan.com/
- 使用要求：扫码关注公众号
- 绕过“付费”，破解小白盘| 备份
- 大力盘\小白盘自动跳转脚本
56网盘： https://56wangpan.com/
- 使用要求：在 “查看分享文件/目录” 弹出的对话框，选右下角的 “直接跳转” 可以无需扫码关注公众号免费使用
盘搜搜： https://pansoso.com/
小可搜搜： https://www.xiaokesoso.com/
小昭来啦： https://www.xiaozhaolaila.com/
天天云搜： https://www.ttyunsou.com/
微友搜索： http://www.weiyoou.com/
云盘精灵： https://www.yunpanjingling.com/
- 使用要求：购买云豆（5元=100颗）
盘么么： http://www.panmeme.com/
天天云搜： https://www.ttyunsou.cn/mm/
坑搜盘： http://www.kengso.com/
优质吧： https://uzi8.cn/
fastsoso： https://www.fastsoso.cn/
59盘： http://www.59pan.com/
99搜索： https://www.99baiduyun.com/
盘搜： http://pansou.com/
云铺子： http://www.yunpz.net/
文件搜： http://wjsou.com/
百度云搜索搜： http://www.baiduyunsousou.com/
云搜： http://daysou.com/
网盘传奇： https://jidanso.com/
哎呦喂呀： http://aiyoweia.com/
及搜盘： http://www.jisoupan.com/
特白度： http://www.tebaidu.com/
SOV5搜索： http://sov5.cn/
云盘搜索大师： https://www.xxhh360.com/
搜盘： http://www.soupan.info/
毒盘搜索： https://aizhaomu.com/
VeryPan： http://www.verypan.com/
毒盘资源： http://www.friok.com/
6miu： http://baiduyun.6miu.com/
51搜盘： http://www.51sopan.cn/
热盘搜： http://www.repanso.com/
SOSO云盘： https://www.sosoyunpan.com/
在线工具搜索： https://tool.lu/pansou/
搜云盘： https://soyunpan.com/
Pan58： http://www.pan58.com/

其他网盘资源搜索

蓝奏云

小鸟搜索： https://www.birdiesearch.com/
小七线报： https://www.xqxianbao.com/lzys/
各大搜索引擎搜索：
site: lanzous.com +关键字
两个支持蓝奏云搜索的APP：
蓝瘦和聚应用.

Google Drive

找PP-Google Drive搜索引擎： https://zhao.pp.ua

网盘提取码获取

自动填写网盘密码的浏览器扩展有：
- 集装箱
- 爱搜资源助手
- 百度云分享链接一键登录
它们的数据来源不同，都装上有更大几率获取密码。

网盘下载工具

百度云不限速:
KinhDown： https://www.lanzoux.com/s/KinhDown
亿寻
- 本程序仅为寻人而写，想通过其请大家帮助寻人。如果你对此不认同，请不要使用本程序。
- 可免登录下载百度云文件，速度可达满速，目前使用正常，推荐。
解析网站（暂无可用）
- 直接在该网址后加上分享链接通过IDM下载，速度可观。
雷鸟下载
- 一款基于多资源超线程技术的下载软件，针对各类网盘做了下载优化。
6盘小白羊
- 无需登录，使用我内置6盘账号，直接下载百度分享链接.
共享账号
- 本论坛，某宝，某鱼，某多搜索关键词即可。
直链下载助手
- 免费开源的油猴百度云直链脚本，通过该脚本配合IDM、XDown等下载百度云文件。
速盘
- 免登录，自动查询提取码，极速的度盘下载工具，通过流量收费。
爱奇艺万能播放器
- 点击右上角云盘按钮登录，可享受不限速，使用过多也会凉凉.
官方下载
- 通过观看广告可获取一定的加速、目前客户端提供了闲置宽带加速，请自行选择使用。

致敬之前的项目：

~~pandownload：2020年4月15日，作者因“侵犯百度网盘用户数据隐私”被抓，停止维护。~~
~~PDown：6月13日起停止开发维护、后续项目由他人接手，迫于百度法务压力于6月27日彻底停服。~~

目前百度是针对账号进行限速，当一个非会员账号下载量达到一定阈值就会触发限速。账号被限速之后容易出现下载错误、掉连接数等问题，需要过几天或者开通会员才会恢复。

PanDownload网页复刻版

源码

CloudFlare Workers版： https://github.com/TkzcM/baiduwp
PHP版： https://github.com/yuantuo666/baiduwp-php

网友搭建网站

网友使用上方源码搭建的，如果使用的是百度网盘VIP账号的cookie，可以获取到高速下载地址，因为这类网站容易失效，就不另开帖了，放这里等失效就删掉了

http://8945gs.ga/
https://bdwp.vip/
https://baidupan.storming.ltd/
http://blog.xxatf.top/
https://pan.kdbaidu.com/
http://fxrcxjq.com/bd/
http://pan.0ddt.com
https://pan.biomed.icu/
https://baidu.lenchan.workers.dev/
https://bdpan.effervescence.workers.dev/
https://frosty-mountain-d7c1.of7013nqoa472.workers.dev/
http://bdpan.404lab.top/
http://pandl.club/
http://pandown.club/
https://pan.leasr.tk/
http://www.wouuz.com/onlinedownload/baiduwp.html

百度网盘秒传链接转存

https://rapid.acg.uy/ 使用教程

天翼云盘直链解析

https://api.zzux.net/189/

参考资料

百度网盘搜索资源索引： https://adzhp.cn/wang-pan-sou-suo.html
百度网盘搜索资源索引： https://share.mubu.com/doc/aU2dU_Fkew 密码：es7e

磁力链接BT种子电驴搜索下载网站合集 | 合集网

Mon, 26 Oct 2020 11:39:57 CST

国内磁力搜索

磁力爬永久地址： https://www.cilipa.com（被墙）
- 备用域名： https://www.cilipapa.com
- 地址发布页： https://www.cilipa.net
熊猫磁力： https://xiongmao23.icu/
- 地址发布页： https://xiongmaocl.fun（被墙）
磁力巴士永久地址： http://www.bvbus.com
磁力狗： http://ciligou.app/
- 备用地址： http://0200.org
BT-btt永久地址： https://u3c3.com/ （被墙）
- 备用地址： https://u9c9.com/ https://u7c7.com/
- 地址发布页： https://github.com/u3c3/bt-btt
Push BT平台： http://m.pushbt.top/ 只有用手机浏览器才显示网站内容
- 网址防丢失邮箱pushbtwebsite@gmail.com
BT1207： https://bt1207.fun/
- 备用地址： https://bt1207cl.icu/
SkrBT： https://sktbtcil.buzz/
- 备用地址： https://skrbt.fun/
MAG磁力站永久地址： http: //cili001.com
Sobt永久地址： http://sobt.me/
- 备用地址： http://www.sobt5.pw/
Btdad： http://www.btdad.xyz/
- 备用地址： http://www.btdad.life
雨花阁地址发布页1 ： https://www.yuhuage.club/
- 地址发布页2： https://www.btcherries.xyz/
- 备用地址发布页： https://github.com/yuhuage/dizhi/blob/master/README.md
- 发邮件到dxj880@gmail.com获取最新地址
磁力宝： http://www.clb.biz/
- 备用地址： http://9321.org
巴士资源搜索： http://5338.org
磁力天堂永久地址： https://www.cltt.me
Bthub： https://bthub.site/ （被墙）
- 备用地址： https://bth01278213.monster/
- 地址发布页1 ： https://github.com/fwonggh/Bthub
- 地址发布页2： https://gitlab.com/fwonggh/Bthub/-/blob/master/README.md
btfox： http://btfox0.net
BT精灵： https://btring.com
magnetW： https://github.com/xiandanin/magnetW
- 聚合搜索，目前只更新软件版， win和mac下载
老王磁力： https://laowang.fun/

国外磁力搜索

RARBG： https://rarbgaccess.org/
BTSOW： https://btos.pw/
Data-Iceberg： https://data-iceberg.com/
AIO Search： https://www.aiosearch.com/ 磁力聚合搜索网站
东京图书馆： https://www.tokyotosho.info/
海盗湾： https://thepiratebays.info/ 永久发布页
ØMagnet： https://0mag.net 正经资源搜不到

磁力下载站

MP4吧： http://mp4ba.cc/
- 提供下载方式：磁力链接、BT种子、百度网盘
人人影视： http://www.zmz2019.com/
- 磁力、电驴
美剧天堂： https://www.meijutt.com/
- 磁力、电驴
一站搜： http://videos.yizhansou.com/
- 磁力、电驴
片源网： http://www.pianyuan.la/
- BT、磁力
中国高清网： http://gaoqing.la/
- 磁力

种子下载站

耐卡影音论坛： http://mcar.co/
- BT种子、网盘
BT之家： https://www.88btbtt.com/
- BT种子

电驴下载站

电波字幕组： http://dbfansub.com/
- 电驴、网盘。提供单独字幕下载

公共 BitTorrent Tracker

下载前记得更新下公共 BitTorrent Tracker 列表

使用说明
- https://github.com/XIU2/TrackersListCollection/blob/master/README-ZH.md
Aria2 Tracker
- https://trackerslist.com/all_aria2.txt
BitTorrent Tracker
- https://trackerslist.com/all.txt

如何使用 Everything 同时搜索文件夹名和文件名[技巧]

Sun, 20 Sep 2020 19:59:38 CST

来自问题频道的问题：

我有一个资料的路径如下： E:\工作\工作资料\台账&花名册\02.人员花名册.xlsx

目前我只记得住在一个【台账】文件夹下有一个叫【人员】的东西，请问如何搜索。

虽然，直接搜索人员也肯定可以得到结果，但如果文件数量很多，能缩小搜索范围岂不是更好。

最后 @ Zakary 自己找到了解决方案。

在 Everything 的修饰符页面，提供了一个参数： path: / nopath: 匹配完整路径和文件名或仅文件名。

青小蛙也专门测试了一下，结果如下：

在 Everything 里使用 “ path:台账人员” 和 “ nopath:台账人员” 进行搜索，结果显而易见， path:台账人员 得到了我们需要的结果。

其实青小蛙对于 path 参数的理解还不太清楚，有没有同学来一个简单的解释呢？

ElasticSearch实现基于经纬度的附近搜索

Tue, 04 Aug 2020 12:43:02 CST

ElasticSearch除了支持文本检索外，还支持地理信息检索。它主要支持两种类型的地理查询：一种是地理点(geo_point)，即经纬度查询，另一种是地理形状查询(geo_shape)，即支持点、线、圈、多边形查询等。

ElasticSearch实现经纬度附近搜索

1、创建映射(mapping)

import requests
import json
attractions_url = "http://localhost:9200/attractions?include_type_name=true"
data = {
    "mappings": {
        "hotel": {
            "properties": {
                "name": {
                    "type": "text"
                },
                "location": {
                    "type": "geo_point"
                }
            }
        }
    }
}

json_data = json.loads(json.dumps(data))
r = requests.put(url=attractions_url, json=json_data)
print(r.status_code)
print(r.text)

对于某些特殊的查询，例如矩形范围查询，可以通过分别对lat和lon进行索引以提高查询速度。因为矩形范围的查询完全可以先通过lat过滤，再通过lon过滤。要实现此功能只需在location节点下添加”lat_lon”: true即可。

2、添加数据（插入文档）

import requests
import json
import pandas as pd
f = pd.read_csv("data.csv")
for index, row in df.iterrows():
    url = "http://localhost:9200/attractions/hotel/{0}".format(index)
    data = {"name": str(int(row['hotel_id'])), "location": {"lat": row['lat'], "lon": row['lon']}}
    json_data = json.loads(json.dumps(data))
    r = requests.put(url, json=json_data)

插入文档时，有三种格式的属性可以被映射为 geo_point 类型：

string：格式为lat,lon
double []：格式为[lon, lat]
json：格式为{ “lat”: lat, “lon”: lon}

注意：数组格式是 lon 在前，lat 在后，而字符串格式正好相反。

3、查询

Elasticsearch 的地理位置查询，实际是使用过滤器对所有文档进行过滤。它支持以下四种查询方式：

geo_bounding_box：查询矩形范围内的点
geo_distance：查询中心点距离范围内的点
geo_distance_range：查询中心点最小距离和最大距离之间的点
geo_polygon：查询多边形范围内的点（不推荐使用）

以下为通过中心点距离范围内的示例：

import requests
import json
url = "http://localhost:9200/attractions/hotel/_search"
lat, lon = 34.514020, 113.191598
data = {
    "query": {
        "bool": {
            "must": {
                "match_all": {}
            },
            "filter": {
                "geo_distance": {
                    "distance": "10km",
                    "location": {
                        "lat": lat,
                        "lon": lon
                    }
                }
            }
        }
    }, "sort": [
        {
            "_geo_distance": {
                "location": [
                    {
                        "lat": lat,
                        "lon": lon
                    }
                ],
                "unit": "m",
                "distance_type": "arc",
                "order": "asc",
                "validation_method": "STRICT"
            }
        }
    ]
}
json_data = json.loads(json.dumps(data))
r = requests.get(url, json=json_data)

除了中心点和距离，我们还需要指定计算距离的方式，每种方式对应着不同的精度和计算速度，常用的有三种：

arc：最慢但最精确的是 arc 计算方式，这种方式把世界当作球体来处理。不过这种方式的精度有限，因为这个世界并不是完全的球体。
plane：plane 计算方式把地球当成是平坦的，这种方式快一些但是精度略逊。在赤道附近的位置精度最好，而靠近两极则变差。
sloppy_arc：如此命名，是因为它使用了 Lucene的SloppyMath 类。这是一种用精度换取速度的计算方式，它使用 Haversine formula 来计算距离。它比 arc 计算方式快 4 到 5 倍，并且距离精度达9%。这也是默认的计算方式。

对于大部分应用来说，plane的精度已经足够了，并且速度是最快的，所以推荐使用它。

ElasticSearch按距离打分的配置

ElasticSearch除了按照距离排序外，还支持按距离打分并且与其他评分一起应用。

有三种衰减函数：linear 、 exp 和 gauss （线性、指数和高斯函数），它们可以操作数值、时间以及经纬度地理坐标点这样的字段。所有三个函数都能接受以下参数：

Origin：中心点或字段可能的最佳值，落在原点 origin 上的文档评分 _score 为满分0。
Scale：衰减率，即一个文档从原点 origin 下落时，评分 _score 改变的速度。
Decay：从原点 origin 衰减到 scale 所得的评分 _score ，默认值为5 。
Offset：以原点 origin 为中心点，为其设置一个非零的偏移量 offset 覆盖一个范围，而不只是单个原点。在范围 -offset <= origin <= +offset 内的所有评分 _score 都是0 。

这三个函数的唯一区别就是它们衰减曲线的形状，用图来说明会更为直观：

gauss

$$S(doc) = \exp(-\frac{\max(0,|\text{fieldvalue}_{doc}-\text{origin}|-\text{offset})^2}{2\sigma ^2})$$

其中：

$$\sigma ^2=-\frac{\text{scale}^2}{2\cdot \ln(\text{decay})}$$

exp

$$S(doc) = \exp(\lambda \cdot max(0,|\text{fieldvalue}_{doc}-\text{origin}|-\text{offset}))$$

其中：

$$\lambda = \frac{\ln(\text{scale})}{\text{scale}}$$

linear

$$S(doc) = \max(\frac{s-\max(0,|\text{fieldvalue}_{doc}-\text{origin}|-\text{offset})}{s},0)$$

其中：

$$s = \frac{\text{scale}}{1.0-\text{decay}}$$

参考连接：

IT瘾搜索推荐

网罗天下：超全特殊搜索引擎合集，开启探索新视界！ - 资源 - 虫部落

超谷歌搜索：阿里开源创新大模型搜索引擎 ZeroSearch，成本直降 80% 且能力更强

如何高效搜索 Telegram 信息源？

一、为什么要搜索 Telegram？

二、核心搜索工具介绍

1. Lyzem Telegram Search

2. Google Custom Telegram Search

3. TGStat.ru 国际版搜索

4. TelegramChannels.me

5. Search.buzz.im

三、如何组合使用这些工具？

情报采集链推荐流程：

实例：调查 “Telegram 上的金融诈骗团伙”

四、使用技巧和注意事项

五、总结：Telegram 是 OSINT 的宝藏地

Google搜索引擎架构Caffeine

什么是 Google Caffeine？

Google Caffeine的产生背景

Google Caffeine 的核心特性

Caffeine 的技术优势

Google Caffeine的影响

Google Caffeine后更新

RankBrain（2015 年）

BERT（2019 年）

移动优先索引（Mobile-First Indexing，2016 年启动，2021 年完成）

Page Experience Update（页面体验更新，2021 年）

MUM（Multitask Unified Model，2021 年）

实时搜索与增强数据呈现

神经匹配（Neural Matching，2018 年）

AI 驱动的改进（2023 年及之后）

数据隐私与安全性改进

相关文章:

Google 罕见的披露了给它带来最多广告收入的搜索查询词

Elasticsearch：使用 Elasticsearch 进行语义搜索

什么是语义搜索？

语义搜索的好处

Elastic Search 中的语义搜索

自然语言处理（NLP）

向量搜索

NLP 与向量搜索的工作原理

ELSER

第 1 步：创建具有所需映射的索引

第 2 步：使用推理处理器创建摄取管道

第 3 步：将数据添加到索引

第 4 步：执行语义搜索

第 5 步：将语义搜索与其他查询结合起来

Embedding - 另一种站内搜索方案

ChatGPT 式搜索对 Google 微软而言意味着成本增加 10 倍

ChatGPT会取代搜索引擎吗

ChatGPT的技术原理

chatGPT能否取代Google、百度等传统搜索引擎

Yandex 的搜索引擎使用了 1922 个排名因子

美团外卖搜索基于Elasticsearch的优化实践

1. 前言

2. 背景

3. 挑战及问题

3.1 倒排链查询流程

3.2 倒排链合并流程

4. 技术探索与实践

4.1 倒排链查询优化

4.2 倒排链合并

4.2.1 原生实现

4.2.2 RoaringBitmap

4.2.3 Index Sorting

4.3 基于 RLE 的倒排格式设计

4.3.1 Run-Length Encoding

4.3.2 RLE Container 的实现

4.3.3 SparseRoaringDocIdSet 实现

4.4 功能集成

4.4.1 倒排索引集成

4.4.2 在线检索链路

5. 性能收益

6. 总结与展望

7. 作者简介

8. 参考文献

✨基于Spring-Data-Elasticsearch 优雅的实现 多字段搜索 + 高亮 + 分页 + 数据同步✨

theme: devui-blue highlight: a11y-dark

系列说明

前言

✨基于Spring-Data-Elasticsearch 优雅的实现多字段搜索 + 高亮 + 分页 + 数据同步✨