常用召回算法

Ⅰ 推荐算法如何提前划分制造同类目日志

做推荐算法的质量工作将近一年，这一年尝试了很多东西，踩了不少坑，也对推荐的评测工作稍微有了些自己的心得，现在分享出来，希望能和做这块工作的同学一起交流、探讨，也欢迎多拍砖，多提意见。

推荐系统

目前推荐技术的应用已经非常较普及了，新闻、商品、问答、音乐，几乎都会用到推荐算法来为你呈现内容。下面是淘宝、知乎、微博三个app的推荐模型，可以看到推荐都在非常重要的位置。

在介绍推荐算法评测之前，我先简单说下推荐系统，这里我以商品为例，简单描述下推流程，让大家更明白一些，一般推荐主要包含以下步骤：
召回->打分排序->透出

召回

召回阶段通常的手段是协同过滤比较场景的i2i,u2i等这种x2x（有兴趣可以看下我写的基于itembase的推荐），也有使用embedding的方式通过向量之间的距离进行召回。以i2i为例，假如现在要针对我推荐一个商品，那么首先要找到我感兴趣的物品 ，这些数据是通过我的历史行为来进行获取，比如拿到我最近一段时间内的点击、加购、收藏、购买的物品，将这些商品做为trigger进行召回，协同算法的具体就不再这里叙述了，有兴趣可以看下链接，最终我们按照协同过滤算法算出商品之间的相似分值，然后按照一定数量进行截断，因为这里截断也是依靠分数来进行的，所以一般这一步也称粗排。这样召回截断就完成了。

打分

召回完商品后，我们需要对这些商品进行再一次的精排，这里需要用模型来预估ctr，一般情况下LR、GBDT、FM用的比较多，这里深度网络相对用的少，主要为了考虑到性能，尤其是rt，因为绝大部分的精排都是需要实时预测的，所有对耗时有一定的要求。继续说下模型预测的步骤，首先针对召回的商品进行特征的补充，例如该商品的一级类目、叶子类目（一级类目代表比较，叶子类目代表最细分的类目）、被多少用户购买等，然后再加入人的特征，例如性别、年龄、收入、对类目的偏好等，然后将这些信息做为feature，用模型进行预测，然后根据模型预测的结果进行排序，输出。

模型

打分过程中的模型是需要提前训练和部署，训练集的来源就是用户的实时行为加上用户和商品的特征。feature的构成是用户的特征和商品的特征，label则是用户是否点击了该商品。

质量方案

接下来说下如何保证这块的质量。由于推荐系统最终对用户需要提供实时的服务化，因此免不了有工程端的技术需要一起配合。因此我这块主要分为两个维度来开展，一方面是工程端的质量保证，一方面是算法侧的质量保证。

工程端质量

这一块可以将算法当成一个黑盒子，只把他当成一个有结果返回的接口。针对这方面前人已经有了丰富的经验，我们可以做接口的单元测试和冒烟测试，另外就是压测，在预估的qps下看rt是否满足业务方的要求，load是否过大，超时和错误的比例是否符合一定的预期。这里就不细说了，重点说说第二部分。

算法端质量

这里我再进行细分一下，分为三部分介绍：算法数据、算法模型、算法效果；

算法数据：

大家都知道算法在做训练前数据的处理部分非常的重要，有兴趣可以看下特征工程相关的内容，数据的来源，特征的构造，数据抽取、加工整个的过程都有可能会出现错误，而且数据一般都是存储在分布式系统数据库里，因此需要借助类似hive这样的工具将sql转换成MapRece的任务去进行离线的计算，离线任务的产出通常会耗费不少的时间，而对于一些日更新的模型通过对数据对产出时间有一定的要求。因此数据这块最主要的保证点为：数据本身的质量，和数据的产出时间。数据本身的质量一般可以通过数据大小的整体抖动，以及关键字段是否为空，主键是否重复，做法比较简单可以通过简单sql或者udf来完成，然后借助工程能力做到预警、检查、出报表等。

算法模型：

模型的本身在迭代过程中也是需要关注的，不过通常算法同学的训练优化也是参考这些指标，所以我们也可以把这几个指标做为模型本身好坏的评估。具体为：准确率、召回率、AUC。

算法效果：

那么这个算法推荐出的效果究竟好不好呢，这个是一个非常主观的事情，每个人的感受也不是一样的，但是我们仍然要衡量它的好坏，这里我参考业内学者的推荐书籍以及自己的一些摸索，总结出下面一些方法，供大家参考。

人工评测：

顾名思义，邀请一帮人来对你的推荐系统的结果进行评测。这里想法来自于我在做翻译评测时期的经验，首先这个成本比较高，另外就是参杂了人的主观性非常的高，翻译的好坏我们可以通过制定一些细致的规则来进行约束，但是推荐的好坏我们却不好制定详细的规则，另外就是推荐之前的用户行为如何模拟，如何让评测者进行感知，这些都是比较难的，并且和基准的对比也不是很好做，所以这里不是很推荐用这个方法，但是还是要提一下。

指标评估：

指标化推荐结果，也就是将推荐的结果用不同的指标来进行说明，通过这些指标，你可以更加的了解你的推荐系统，部分指标不一定越高越好，但是你需要让它保持在一定的范围内。说到具体的例子的时候，我会提一下。下面我们看下这些指标。

覆盖率

定义：
推荐系统能够推荐出来的“商品/类目”占“总商品/类目”集合的比例。假设系统的用户集合为U，推荐系统给每个用户推荐一个长度为N的物品列表R(u) ，总物品为N。那么：
覆盖率 = ΣR(u)N
Σ
R
(
u
)
N

意义：
描述推荐结系统对物品长尾发掘能力；
举个例子，淘宝上商品千千万万，推荐系统能否保证让新的一些商品有足够的机会曝光出去呢？还是有些商品永远都无法得到推荐曝光的机会。这个指标反应的就是这个情况，显然物品的覆盖率是达不到100%的，但是我们可以看类目的覆盖率来进行衡量，假设全网所有的一级大类目一共2千个（和全网上亿的物品相比非常的少），那么推荐系统一天之内推荐出去的商品对应的一级类目，这个就是我们要衡量的标准。如果覆盖率

Ⅱ f-measure的准确率/精确率/召回率

准确率(accuracy),精确率(Precision)和召回率(Recall) 是信息检索，人工智能，和搜索引擎的设计中很重要的几个概念和指标。中文中这几个评价指标翻译各有不同，所以一般情况下推荐使用英文。 先假定一个具体场景作为例子。
假如某个班级有男生80人,女生20人,共计100人.目标是找出所有女生.某人挑选出50个人,其中20人是女生,另外还错误的把30个男生也当作女生挑选出来了.作为评估者的你需要来评估(evaluation)下他的工作
首先我们可以计算准确率(accuracy),其定义是: 对于给定的测试数据集，分类器正确分类的样本数与总样本数之比。也就是损失函数是0-1损失时测试数据集上的准确率 .
这样说听起来有点抽象，简单说就是，前面的场景中，实际情况是那个班级有男的和女的两类，某人(也就是定义中所说的分类器)他又把班级中的人分为男女两类。accuracy需要得到的是此君分正确的人占总人数的比例。很容易，我们可以得到:他把其中70(20女+50男)人判定正确了,而总人数是100人，所以它的accuracy就是70 %(70 / 100).
由准确率，我们的确可以在一些场合，从某种意义上得到一个分类器是否有效，但它并不总是能有效的评价一个分类器的工作。举个例子,google抓取了argcv 100个页面，而它索引中共有10,000,000个页面,随机抽一个页面，分类下,这是不是argcv的页面呢?如果以accuracy来判断我的工作，那我会把所有的页面都判断为不是argcv的页面,因为我这样效率非常高(return false,一句话),而accuracy已经到了99.999%(9,999,900/10,000,000),完爆其它很多分类器辛辛苦苦算的值,而我这个算法显然不是需求期待的,那怎么解决呢?这就是precision,recall和f1-measure出场的时间了.
在说precision,recall和f1-measure之前,我们需要先需要定义TP,FN,FP,TN四种分类情况.
按照前面例子,我们需要从一个班级中的人中寻找所有女生,如果把这个任务当成一个分类器的话,那么女生就是我们需要的,而男生不是,所以我们称女生为正类,而男生为负类. 相关(Relevant),正类无关(NonRelevant),负类被检索到(Retrieved)true positives(TP 正类判定为正类,例子中就是正确的判定这位是女生)false positives(FP 负类判定为正类,存伪,例子中就是分明是男生却判断为女生,当下伪娘横行,这个错常有人犯)未被检索到(Not Retrieved)false negatives(FN 正类判定为负类,去真,例子中就是,分明是女生,这哥们却判断为男生--梁山伯同学犯的错就是这个)true negatives(TN 负类判定为负类,也就是一个男生被判断为男生,像我这样的纯爷们一准儿就会在此处)通过这张表,我们可以很容易得到例子中这几个分类的值:TP=20,FP=30,FN=0,TN=50.
精确率(precision)的公式是 ,它计算的是所有被检索到的item（TP+FP）中,应该被检索到的item（TP）”占的比例。
在例子中就是希望知道此君得到的所有人中,正确的人(也就是女生)占有的比例.所以其precision也就是40%(20女生/(20女生+30误判为女生的男生)).
召回率(recall)的公式是 ,它计算的是所有检索到的item（TP）占所有应该被检索到的item（TP+FN）的比例。
在例子中就是希望知道此君得到的女生占本班中所有女生的比例,所以其recall也就是100%(20女生/(20女生+ 0 误判为男生的女生))
前文中提到F1-measure的计算公式是 其推导其实也很简单。
定义:
，定义为和的调和平均数。
可得:
“精确率”与“召回率”虽然没有必然的关系（从上面公式中可以看到），然而在大规模数据集合中，这两个指标却是相互制约的。
由于“检索策略”并不完美，希望更多相关的文档被检索到时，放宽“检索策略”时，往往也会伴随出现一些不相关的结果，从而使准确率受到影响。
而希望去除检索结果中的不相关文档时，务必要将“检索策略”定的更加严格，这样也会使有一些相关的文档不再能被检索到，从而使召回率受到影响。
凡是涉及到大规模数据集合的检索和选取，都涉及到“召回率”和“精确率”这两个指标。而由于两个指标相互制约，我们通常也会根据需要为“检索策略”选择一个合适的度，不能太严格也不能太松，寻求在召回率和精确率中间的一个平衡点。这个平衡点由具体需求决定。

Ⅲ 想要成为算法工程师都要学哪些技能

需要以下技能：

1、熟练掌握C/C++和python语言编程，熟悉linux开发环境，有扎实的数据结构和算法设计功底；

2、熟悉推荐业务常用理论和算法，在多个领域（如排序模型，召回模型，用户画像，深度学习等）有三年以上实际工作经验；

3、有优秀的逻辑思维能力和数据分析能力，善于分析和解决问题；良好的沟通能力与团队协作能力；

4、有推荐系统，广告系统，搜索引擎等开发经验；熟练掌握机器学习、深度学习的基础理论和方法，并在自然语言处理任务中有实际应用经验者优先；

5、熟练使用一种或几种深度学习框架（如tensorflow、caffe、mxnet、pytorch等），或者熟悉spark、hadoop分布式计算编程者优先。

硬技能：

1. 数学：包括概率论与数理统计、矩阵论、随机过程。

2. 计算机基础：包括操作系统、组成原理、数据结构。

3. 算法能力：包括对领域内主流模型进行优缺点对比、在设定的场景中选择合适的方案等。

想要了解更多关于算法工程师的问题可以咨询一下CDA认证机构，CDA是大数据和人工智能时代面向国际范围全行业的数据分析专业人才职业简称。全球CDA持证者秉承着先进商业数据分析的新理念，遵循着《CDA职业道德和行为准则》新规范，发挥着自身数据专业能力，推动科技创新进步，助力经济持续发展。

Ⅳ 爱奇艺的推送机制是怎样的呢

我们的推荐系统主要分为两个阶段，召回阶段和排序阶段。

召回阶段根据用户的兴趣和历史行为，同千万级的视频库中挑选出一个小的候选集（几百到几千个视频）。这些候选都是用户感兴趣的内容，排序阶段在此基础上进行更精准的计算，能够给每一个视频进行精确打分，进而从成千上万的候选中选出用户最感兴趣的少量高质量内容（十几个视频）。

推荐系统的整体结构如图所示，各个模块的作用如下：

用户画像：包含用户的人群属性、历史行为、兴趣内容和偏好倾向等多维度的分析，是个性化的基石
特征工程：包含了了视频的类别属性，内容分析，人群偏好和统计特征等全方位的描绘和度量，是视频内容和质量分析的基础
召回算法：包含了多个通道的召回模型，比如协同过滤，主题模型，内容召回和SNS等通道，能够从视频库中选出多样性的偏好内容
排序模型：对多个召回通道的内容进行同一个打分排序，选出最优的少量结果。
除了这些之外推荐系统还兼顾了推荐结果的多样性，新鲜度，逼格和惊喜度等多个维度，更能够满足用户多样性的需求。
推荐排序系统架构

在召回阶段，多个通道的召回的内容是不具有可比性的，并且因为数据量太大也难以进行更加精确的偏好和质量评估，因此需要在排序阶段对召回结果进行统一的准确的打分排序。

用户对视频的满意度是有很多维度因子来决定的，这些因子在用户满意度中的重要性也各不相同，甚至各个因子之间还有多层依赖关系，人为制定复杂的规则既难以达到好的效果，又不具有可维护性，这就需要借助机器学习的方法，使用机器学习模型来综合多方面的因子进行排序。

Ⅳ 神经网络算法的必要性

这里的distinct表示去重，也可以用group by实现， 两者的区别在于distinct会读取所有的记录，而group by是在分组之后每组只返回一条记录，也就是说后者读取的条数要少很多，效率会更高一些，因此可以将上述代码改为：

create table validate_set as
select
user_id,
wm_concat(',',brand_id) as brand
from(
select user_id,brand_id
from t_alibaba_bigdata_user_brand_total_1
where type = '1' and visit_datetime > '07-15'
group by user_id,brand_id
)a
group by user_id;
训练集和测试集建立好之后，我们可以通过以下命令来计算测试集的推荐数目：

select sum(regexp_count(brand,',')+1) from t_tmall_add_user_brand_predict_dh;
其中REGEXP_COUNT是ODPS的一个自建函数，它的用法如下：

bigint regexp_count(string source, string pattern[, bigint start_position])
表示计算 source 中从 start_position 开始，匹配指定模式pattern 的子串的次数。比如我们有一条输出结果是：100 1,2,3,4，通过计算其中的,数（3）+1=4就计算出推荐的个数了。

UDF计算重复条数

UDF(User-Defined Function)(用户定义函数)，是用户根据实际应用的需要而自行开发的函数。在 Eclipse 中的项目下新建 UDF。填入 Package 名称为：chanvee.udf，和 UDF 类名：CountHits，点击确认。插件会自动帮我们生成chanvee.udf包用于写 UDF 代码，和test.chanvee.udf包用于本地测试。

编辑CountHits.java文件，注意下文的Long不能替换为long类型，否则在ODPS上运行会报Method Not Found错误：

package chanvee.udf
import java.util.Arrays;
import java.util.HashSet;
import java.util.Set;
public class CountHits extends UDF {
public Long evaluate (String a,String b){
if(a == null || b == null) {
return 0L; //异常值
}
Set<String> set1 = new HashSet<String>();
Set<String> set2 = new HashSet<String>();
set1.addAll(Arrays.asList(a.split(",")));
set2.addAll(Arrays.asList(b.split(",")));
Long hits = 0L;
for(String s : set2){
if( set1.contains(s) )
hits++;
}
return hits;
}
}
本段函数的主要工作是在a串和b串去重后，计算它们中重复元素的个数。接下来在本地测试下 UDF 。在test.jark.udf包中有两个文件TestCountHits.java和TestUDFBase.java。由于如果 UDF 的输入参数是多个的话，本地测试默认的分隔符是逗号，与我们brand中的逗号冲突了。所以修改下TestUDFBase.java文件的第15行的分隔符为空格（当然也可以其他符号）：

private final static String ODPS_SEPARATOR = " ";
同时修改第72行，去掉(String)，原因是Long型不能强制转换成String：

return callMeth.invoke(UDFClass, input_parameter.toArray()) + "\n";
在TestCountHits.in文件中输入测试样例：

123456,444,555,666 123456,666,777,888
888,999 111,222
111,111,222,222 111,222,222,333
运行TestCountHits.java后，在TestCountHits.out文件中得到测试结果（样例）：

2
0
2
在确认 UDF 没有问题后，准备上传。将Package chanvee.udf打成 jar 包，命名为chanvee_udf.jar，置于C:/TOOLS下，执行以下命令:

create resource jar C:/TOOLS/chanvee_udf.jar
create function count_hits chanvee.udf.CountHits jark-udf.jar
上述命令作用分别是将用户 jar 包上传到 ODPS 和在 ODPS 上注册函数并命名为count_hits。现在使用ls functions命令就能看到我们刚刚注册的函数了。

现在，我们就能像调用一般内建函数一样调用我们自己的count_hits函数了。计算推荐集和验证集中的重复条数，有下面代码：

select sum(count_hits(a.brand,b.brand)) hits from t_tmall_add_user_brand_predict_dh a
join validate_set b on a.user_id = b.user_id;
上面演示了一般 UDF 的创建使用过程，其他类似的 UDF 都可以参考以上过程构建。UDF 是 SQL 的一大工具 ，很多规则算法都可以用过 UDF 方便地实现。

计算评估值

我们知道准确率的计算公式：precision=hitspnums, 其中 pnum 代表推荐的条数。
召回率的计算公式：recall=hitsrnums, 其中 rnum 为验证的条数。
F1：
F1=2∗hitspnum+rnum
为了计算方便，我们用full outer join连接验证集和推荐集，并将计算出的 hits、pnums、rnums 放到临时表里:

select sum(count_hits(p.brand,r.brand) hits,
sum(regexp_count(p.brand,',')+1) pnums,
sum(regexp_count(r.brand,',')+1) rnums
from t_tmall_add_user_brand_predict_dh p
full outer join validate_set r on p.user_id = r.user_id
有了这三个值后，就可以用上面的公式轻松计算出评测值了。

select (hits/pnums) precision, (hits/rnums) recall,(2*hits/(pnums+rnums)) F1
from (
select hits , pnums , rnums
from ...
)a;
综合一下，有如下代码：

create table evaluation as
select (hits/pnums) precision , (hits/rnums) recall , (2*hits/(pnums+rnums)) F1 ,
hits , pnums , rnums , getdate() eval_time
from (
select sum(count_hits(p.brand,v.brand) hits,
sum(regexp_count(p.brand,',')+1) pnums,
sum(regexp_count(v.brand,',')+1) rnums
from t_tmall_add_user_brand_predict_dh p
full outer join validate_set r on p.user_id = r.user_id
)a;
我们将评测值写到了evaluation表中，可供组员查看分析。运行一次上面代码后，若以后再进行评测，可以将第一行改成insert into/overwrite table evaluation后直接运行，这样可以与上次的结果进行比较。
现在已有的模型算法就可以在本地测试调优后，再上传到线上进行评估了。

Ⅵ 求C++代码 如何对文本进行预处理,去除停用词、DF特征选择和TF-IDF加权的工作

新的1年开始，祝好事接2连3，心情4季如春，生活5颜6色，7彩缤纷，偶尔8点小财，烦恼抛到9霄云外！请接受我10心10意的祝福。祝新春快乐！

Ⅶ python 命名实体识别怎么计算准确率 召回率

目前算法方面主流就是CRF了
效率一般
2类(不包括非专名)
几W
query/s
4类
就下降到1W-2W
query/s了
更多类别的就更少了
当然这个是优化过的crf++了
而且命名实体识别
算法不是对所有类别的都合适
比如音乐和电影
CRF的效果就不好
但是人名
地名
机构名还不错
所以工程上即使用CRF
也会使用词典+消歧的策略
！

Ⅷ 如何提高机器学习算法的召回率

最近在做文本分类，遇到了一些问题，想问问大家有没有好的方法。为了节省时间，我只采取了部分数据来跑算法（全部数据跑了之后的结果和这个差不多）
训练集：4837 documents
测试集：2074 documents
样本比例：正样本：负样本 = 1：3
预测结果中，有的算法在正样本中预测的精确率还行（0.95-1.00之间），但是召回率非常差，通常只有0.01和0.02左右，KNeighbors和DecisionTree的精确率和召回率都是0，只有NaiveBayes和BernoulliNB的PR和Recall比较平均，但是也没有到0.8。
问题：我查了一下那些召回率较低（0.01）的算法，475个样本中（正样本），实际上只有5个被预测正确了的，但是具体原因没有查出来。
我想请问一下：1.召回率低是因为样本极度不平衡造成的吗？（虽然我认为1：3的比例不算极度不平衡。）2.在这种样本不平衡的问题上，有没有什么好的方法可以提高召回率？我试过SMOTE方法（过采样和欠采样都有试过），但对于我的数据集并没有什么好的效果，不止到有没有有什么好的方法可以解决这个问题？谢谢！
添加评论
分享

查看全部 11 个回答

0赞同反对，不会显示你的姓名
Elvin 全是细枝末节，做一个乐于分享的人
两个问题一并回答一下，根据你的描述，我觉得问题应该不是出在正负样本比上，1比3这个比例不但不是非常不均衡，相反在我看来已经是非常均衡了。以前做比赛有处理过正负比1比10000的数据，我觉得这才叫不平衡，才需要使用类似上采样，下采样，以及SMOTE算法（都用过），而且这样的情况下recall，F1等指标的提升是显着的。我觉得正负比例在1：1至1：100间差别都不会太大，需要根据具体问题做离线交叉验证去找到最好的比例。

所以我建议你不用再纠结正负样本比的问题，可以再回头看一看你的数据集，一方面看一看代码是否有误？数据集是否太小？（总觉得你的数据集太小，而且测试集相对于训练集太大）另外训练集，测试集的划分是否正确？或者重新划分一下训练测试集做一下交叉验证看一看各项指标再具体研究。

Ⅸ 召回率的计算方法

召回率和精度示意图
假定：从一个大规模数据集合中检索文档的时，可把文档分成四组：
- 系统检索到的相关文档（A）
- 系统检索到的不相关文档（B）
- 相关但是系统没有检索到的文档（C）
- 不相关且没有被系统检索到的文档（D）
则：
- 召回率R：用检索到相关文档数作为分子，所有相关文档总数作为分母，即R = A / ( A + C )
- 精度P：用检索到相关文档数作为分子，所有检索到的文档总数作为分母．即P = A / ( A + B ).
举例来说：
一个数据库有500个文档，其中有50个文档符合定义的问题。系统检索到75个文档，但是只有45个符合定义的问题。
召回率R=45/50=90%
精度P=45/75=60%
本例中，系统检索是比较有效的，召回率为90%。但是结果有很大的噪音，有近一半的检索结果是不相关。研究表明：在不牺牲精度的情况下，获得一个高召回率是很困难的

Ⅹ 论淘宝搜索推荐算法排序机制及2021年搜索的方向。

[写在前面]淘宝搜索引擎至今反复多次，搜索顺序也从最初的统计模型升级到机械学习模型，到2010年为止没有标签没有基础标签，随着计算能力的提高，2010年后开始挖掘用户的基础标签，从3年到2013年开始使用大规模的机械学习和实时特征
但你有没有想过为什么2016-2017年的两年是各种各样的黑搜索盛行的一年，为什么今天几乎消失了？
最根本的原因是从统计算法模型到机械学习模型的转型期。
说白了，这时不收割就没有收割的机会。因为统计模型即将退出历史舞台。
因此，各路大神各自扩大了统计模型算法中的影响因素。统计算法无论在哪里，点击率和坑产都很容易搜索。
那两年成了中小卖家的狂欢盛宴，很多大神的烟火也是旺盛的。
今天推荐算法的第三代使用后，加上疫情的影响进行了鲜明的比较，真的很感慨。
淘宝真的没有流量了吗？电器商务真的做不到吗？还是大家的思维没有改变，停留在2016-2017年的黑搜宴会上不想醒来？
2017年、2018年、2019年是淘宝推荐算法反复最快的3年，每年的算法升级都不同，整体上到2019年9月为止统计算法模型的影响因素还很大，从2019年下半年开始第三代推荐算法后，全面的真正意义进入了以机械学习模型为中心的推荐算法时代。
各路大神也无法验证，加上百年疫情的影响，很多大神的隐蔽布也泄露了。
基本上以统计模型为主，训练基本上没有声音，典型的是坑产游戏。
如果现在还能看到的话，基本上可以判断他不是在训练，而是在制作印刷用纸，一定会推荐使用资源，资源是多么安全。
刷子的生产增加真的没有效果吗？不是我以前的文章说:不是不行，而是从坑产的角度思考，而是从改变竞争环境的角度思考，用补充书改变竞争环境，改变场地，有新的天地，任何手段都要为商业本质服务。
正文
概述统计算法模型时代。
统计模型时代搜索引擎的排名是最原始的排名思考，如果你的类别不错，关键词比较正确，就能得到很大的流量，当时产品需求少，只要上下架的优化就能使产品上升。
到2016年为止没有坑产游戏吗？黑色搜索的效果不好吗？其实，什么时候坑产是最核心的机密，谁来教大家，什么时候教的最多的是类别优化，关键词优化，大部分优化都围绕关键词，电器商的老人想起了你什么时候得到关键词的人得到了世界。
有人告诉我做坑产，关键词找到生意也来了。什么时候知道坑产也没有人给你刷子，大规模的补充书也出现在黑色搜索盛行的时期。
为什么关键词者得天下？
搜索关键词是用户目前意图最直观的表达，也是用户表达意图最直接的方式。
搜索的用户购物意图最强，成交意愿也最强，现在搜索也是转化率最高的流量来源。
统计时代关键词背后直接依赖的是类别商品，只要制作类别和关键词分词即可，哪个时代最出现的黑马通常是类别机会、关键词机会、黑科学技术机会。
最基本的是商业本质，什么时候产品需求少，没有很多现在的类别，自己找类别，现在想想什么概念。
记得什么时候类别错了，搜索也可以来。如果你的商品点击反馈好的话，错误的类别没有什么影响，现在试试吧
搜索类是搜索的基础。
什么时候能称霸，背后有商业逻辑，用户行为数据好就行了。
但无论如何发展检索都离不开关键词。例如，上述关键词是用户表达意图的最直接的方法，是当前消费者的检索行为和购买行为发生了根本性的变化。
检索依然根据消费者的行为数据和关键词来判断需求，这就是机械学习模型时代。
机器学习模式时代-推荐搜索算法。
现在的商品体积和消费者购物行为的丰富性，统计算法不能满足检索的本质要求。
所以现在搜索引擎开始发展深度学习模式更精细的建模-推荐搜索算法，搜索排名更智能。
在此重点讨论推荐检索算法，
2017、2018、2019是推荐检索算法真正意义发展的3年，3年3个系统版本每年更换一次，很多电器商人都不知道头脑。
推荐检索算法和统计算法模型的最大区别在于，Query的处理能力和算法有召回机制
简单表示推荐算法的程序:
1:对检索关键词进行分词、重写的处理进行类别预判
2:根据用户信息，即用户以前的行为数据记录和预测的性别、年龄、购买力、店铺喜好、品牌喜好、实时行动作等信息存档
3:根据检索用户信息，根据检索用户以前的行为数据检索引擎和预测的性别、年龄、购买力、店铺喜好、品牌喜好、实时行动作为等信息存档3:根据检索用户信息的检索用户信息
也就是说，在第一关召回阶段基本上与统计模型时代的最佳化途径相同，核心是标题分词和类别，现在最大的区别是根据用户信息推荐最佳化，这是标签和正确人群标签图像最佳化的基本意义。
为什么现在一直在谈论标签，谈论人标签图像？入池实际上是为了匹配真正的消费者用户信息，通过直通车测试来判断人群也是为了通过性别、年龄和购买力来优化匹配真正的消费者。
召回机制:
通过构建子单元索引方式加快商品检索，不必经历平台上亿级的所有商品。该索引是搜索引擎中的倒置索引，利用倒置索引初始筛选商品的过程是召回阶段。
在这个阶段，不会进行复杂的计算，主要是根据现在的搜索条件进行商品候选集的快速圈定。
之后再进行粗排和精排，计算的复杂程度越来越高，计算的商品集合逐渐减少，最后完成整个排序过程。
主要召回路径分为
1:语言召回
2:向量召回
这些都是商业秘密不方便的说明，有兴趣的是学习我们的在线会员课程标签重叠游戏6是基于语言和向量召回的基础逻辑实战落地的课程。
下一阶段进入粗行列，粗行列受这些因素的影响:
粗行列作为召回后的第一个门槛，希望用户体验以时间低的模型快速排序和筛选商品，第一关系将过滤到不适合本次检索词要求的商品
为了实现这个目的，首先要明确影响粗排名得分的因素
1:类别匹配得分和文本匹配得分，
2:商品信息质量(商品发布时间、商品等级、商品等级)
3:商品组合得分
点击得分
交易得分卖方服务商业得分
在粗排列框架下，系统粗排列算法根据商品类别的预测得分进行得分
点击得分交易得分
交易得分卖方服务商业得分粗排列框架下，系统粗排列的大排列
最后是精排，检索顺序的主要目标是高相关性、高个性化的正确性。
每个用户的喜好不同，系统会根据每个用户的Query结合用户信息进行召回。然后通过粗排后，商品数量从万级下降到千级。
千级商品经排后直接向用户展示，搜索过程中商品集合的思考和具体变化如下图

前面的召回、粗排主要解决主题相关性，通过主题相关性的限制，首先缩小商品集合和我们的在线会员课程标签
精排阶段系是真正系统推荐算法发挥真正威力时，应根据用户行为反馈迅速进行机械学习建模，判断用户真实性、准确性和可持续控制性。
为什么现在的游戏和黑色技术暂时出现，核心是系统算法模型机械学习模型，系统分析用户有问题，不正确，不稳定，维持性差，可以迅速调整。
也就是说，即使发现脆弱性，研究快速有效的方法，系统也会根据你精排阶段的用户行为迅速分析学习建模，发现模型有问题，你的玩法就结束了。
猜机器学习建模的速度有多快？
想玩黑色的东西早点死去吧。
现在使用的检索顺序模型主要是
CTR模型和CVR模型，具体模型过于复杂也不需要深入，但影响这两种模型的最基本因素是用户行为数据
真的不能假的，假的也不能假的算法模型越来越智能化，算法越来越强，只有回归商业本质才能真正解决算法模型背后真正想解决的问题，算法基于商业逻辑。
2021年搜索向哪个方向发生变化:
2020年电器商人和蚂蚁是不平凡的一年。2020年也是蚂蚁从神坛上拉下来的元年，现在蚂蚁有各种各样的黑色。
基于中小卖家的走势无疑是阿里必须正面面对的现实。
如何让中小卖家回流或留在平台上，搜索该怎么做？
检索一定是基于三方的考虑，买方、卖方和平台本身，现在市场上又开始提倡坑产搜索逻辑，坑产妖风又开始，根据推荐搜索算法逻辑来谈这个问题。
为什么坑产思维是不死的小强，每次危机都会跳出来。
以统计模型为中心的坑产时代是淘宝从2003年到2015年一直使用的搜索算法模型长达13年。
同时也是淘宝和中国网分红的野蛮生长期，统计算法模式让太多电商赚钱。除了
之外，十年的奴役思维已经习惯了，在电器商圈，坑产游戏一定有人相信，其他人不一定被认可。所以，我们夹着尾巴发展的原因，时间真的可以证明一切，不用多说，做自己。
习惯性思维加上特殊时期的赚钱蝴蝶效应，使许多电器商人活在历史的长梦中。正确地说，统计算法模型的真正废除是在2019年下半年。
同学说坑产永远有效，我也这么想。
永远有效的是起爆模型坑产权重驱动和统计算法模型中的坑产排名不同。
起爆模型的坑产要素永远有效，这永远不会改变。
但是，如何有效地加上这个起爆模型的坑产权重，并不像模仿购物的意图那么简单。
坑产游戏在2021年绝对不行。淘宝不会把现在的算法系统换成15年前的。
基于三方利益:
购买者体验
卖方利益
平台的发展
搜索肯定会向高精度和高控制性发展。以标签为中心的用户标签图像仍然是影响流量精度的基本因素。
必须从标签的角度考虑和优化种子组的图像。
通过种子组的图像向相似人扩展到叶类人，业界喜好人最后向相关人扩展也是扩大流量的过程渠道。
基于推荐搜索算法逻辑:
精密排列阶段算法更强，精度更高，转化率更高，持续稳定性更强。
基于中小卖方流通的现状，优化精排阶段并非中小卖方能够简单接触。
推荐算法从搜索排名阶段出现在哪个阶段？
个人判断
一是召回阶段
二是粗排阶段
上述提到召回阶段的算法简单复盖商品为万级，排序规则也比较简单，中小卖方在召回阶段提高精度尤为重要。
在这个万级商品库中，如上下架的权重上升，中小卖方有机会上升到主页，从子单元的索引召回中寻找机会。
或者根据中小卖方的新产品和中小卖方的店铺水平进行特别优先搜索推荐，使中小卖方的新产品在低销售状态下显示，可以实现锦囊算法。
中小卖方有机会搜索主页，不调用用户信息直接打开主页的展示权可能是中小卖方最大的支持。
根据召回阶段的用户行为数据，在粗排阶段以比例融入用户信息，即标签的影响。
在初始召回阶段，类别和分词权重，看业者主图场景反应背后的人们反馈，用系统引导，给中小卖方真正参考的流量方向和成交方向。
谁疯狂地印刷用纸直接关闭黑屋，理解印刷用纸优化竞争场景，从优化人群的角度出发，适当放宽处罚。
通过召回阶段，得到的用户信息会影响粗体结果。在这个阶段，用户信息的权重比例不应该太大，流量卡也不应该太死。
在各检索顺序阶段用户信息，即用户标签对检索的影响权重的问题。
这个方向我的个人观点是可能的。