1、添加 关于页面

使用：hexo new page "about" 新建一个 关于我 页面。
主题的 _config.yml 文件中的 menu 中进行匹配
不同主题 _config.yml文件有区别

1
2
3
4
5
6

menu:
  home: /      //主页
  categories: /categories //分类
  archives: /archives   //归档
  tags: /tags   //标签
  about: /about   //关于                  （添加此行即可）

或

1
2
3
4
5
6
7
8
9
10
11
12
13

menu:
  - page: home
    directory: .      //主页
    icon: fa-home
  - page: archive
    directory: archives/    //归档
    icon: fa-archive
  - page: about
    directory: about/    //关于
    icon: fa-user
  - page: rss
    directory: atom.xml    //rss订阅
    icon: fa-rss

编辑 about 关于页面 md文件 部署就能看到

2、添加 标签页面

使用： hexo new page tags 新建一个 标签 页面。
主题的 _config.yml 文件中的 menu 中进行匹配

1
2
3
4
5
6

menu:
  home: /      //主页
  categories: /categories //分类
  archives: /archives   //归档
  tags: /tags   //标签                  （添加此行即可）
  about: /about   //关于

底下代码是一篇包含 标签 文章的例子：

1
2
3
4
5

title: 标签测试
tags:
  - Testing                   （这个就是文章的标签了）
  - Another Tag               （这个就是文章的标签了）
---

3、添加 分类页面

使用： hexo new page categories 新建一个 分类 页面。
主题的 _config.yml 文件中的 menu 中进行匹配

1
2
3
4
5
6

menu:
  home: /      //主页
  categories: /categories //分类        （添加此行即可）
  archives: /archives   //归档
  tags: /tags   //标签                  
  about: /about   //关于

底下代码是一篇包含 分类 文章的例子：

1
2
3
4

title: 分类测试
categories:
- hexo                       （这个就是文章的分类了）
---

4、添加 归档页面

使用： hexo new page archives 新建一个 归档 页面。

主题的 _config.yml 文件中的 menu 中进行匹配

1
2
3
4
5
6

menu:
  home: /      //主页
  categories: /categories //分类        
  archives: /archives   //归档             （添加此行即可）
  tags: /tags   //标签                  
  about: /about   //关于

5、添加 时间线页面

使用： hexo new page timeline 新建一个 归档 页面。

主题的 _config.yml 文件中的 menu 中进行匹配

1
2
3
4
5
6
7
8
9

menu:
  home: /      //主页
  categories: /categories //分类        
  archives: /archives   //归档             （添加此行即可）
  tags: /tags   //标签    
-page: history   (时间线)
     directory: timeline/
      icon: fa-history              
  about: /about   //关于

修改timeline对应的列表

1
2
3
4
5
6
7

timeline:
  - num: 1
    word: 2018/08/16-Start 
  - num: 2
    word: writing
  - num: 3
    word: More

6、添加 自定义页面

使用： hexo new page "guestbook" 新建一个 自定义 页面。
主题的 _config.yml 文件中的 menu 中进行匹配

1
2
3
4
5
6
7

menu:
  home: /      //主页
  categories: /categories //分类        
  archives: /archives   //归档   
  tags: /tags   //标签                  
  about: /about   //关于
  guestbook: /guestbook    //自定义             （添加此行即可）

作者：hiekay
链接：https://www.jianshu.com/p/ebbbc8edcc24
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

工作之中有人怀才不遇，有人平步青云，有人如鱼得水,有人愤愤不平,有人升职加薪，有人默默退场。遭遇不同，境界不同。工作有三重境界：有能力、能成事、会邀功，每一重境界都有不同的挑战。

第一重境界：有能力

机会只会给有准备的人，当机会来临时能不能把握机会，需要多种能力，又具备完成工作的技能，还要有能够把握机会的技能。每个人都希望被闪电劈中，所以风起云涌的时候并不是只有你一个人在场。

第二重境界：能成事

能够把事情做成才会有业绩。有的需要技能，有的需要沟通协调。最终能够把事情做成才是目的。

第三重境界：会邀功

就是怎么样把你的业绩写成邀功报告。打工不是做慈善，需要会邀功请赏，能够升官加薪。否则就是落得“冯唐易老，李广难封”的遗憾退场。

需求

在开发中使用Git的过程中，有时候会有一种需求，要从服务器拉取最新的状态，而本地进行了无关紧要的修改，这时候如果使用git pull命令，会提示本地有未缓存的修改。这时候就需要强制覆盖本地的改变。

一、最佳解决方案

重要提示：如果您有任何本地更改，将会丢失。无论是否有--hard选项，任何未被推送的本地提交都将丢失。
如果您有任何未被Git跟踪的文件(例如上传的用户内容)，这些文件将不会受到影响。
下面是正确的方法：

1

git fetch --all

然后，你有两个选择：

1

git reset --hard origin/master

或者如果你在其他分支上：

1

git reset --hard origin/<branch_name>

说明：

• git fetch从远程下载最新的，而不尝试合并或rebase任何东西。

• 然后git reset将主分支重置为您刚刚获取的内容。 –hard选项更改工作树中的所有文件以匹配origin/master中的文件

在重置之前可以通过从master创建一个分支来维护当前的本地提交：

1
2
3
4

git checkout master
git branch new-branch-to-save-current-commits
git fetch --all
git reset --hard origin/master

在此之后，所有旧的提交都将保存在new-branch-to-save-current-commits中。然而，没有提交的更改(即使staged)将会丢失。确保存储和提交任何你需要的东西。

二、次佳解决方案

1
2

git reset --hard HEAD
git pull

三、第三种解决方法

警告：git clean删除所有未跟踪的文件/目录，不能撤消。

有的时候只有clean -f无效。如果你没有跟踪DIRECTORIES，-d选项也需要：

1
2
3

git reset --hard HEAD
git clean -f -d
git pull

四、第四种方法

可行的方式是通过使用fetch和merge定义的策略。这应该能使你的本地修改保留下来，只要它们不是你试图强制覆盖的文件之一。

首先做一个你的改变

1
2

git add *
git commit -a -m "local file server commit message"

然后获取更改并覆盖，如果有冲突

1
2

git fetch origin master
git merge -s recursive -X theirs origin/master

-X是选项名称，”theirs”是该选项的值。如果存在冲突，则选择使用”their”更改，而不是”your”更改。

五、第五种方法

这是另外的思路，不建议上文的做法：

1
2

git fetch --all
git reset --hard origin/master

而是建议这样做：

1
2

git fetch origin master
git reset --hard origin/master

如果你打算重新设置原点/主分支，没有必要获取所有的遥控器和分支

六、第六种方法

看起来最好的办法是先做：

1

git clean

删除所有未跟踪的文件，然后继续使用通常的git ```
pull …

1
2
3
4

### 七、第七种方法
所有这些解决方案的问题是，它们都是太复杂，或者更大的问题是，他们从Web服务器中删除所有未跟踪的文件，这是我们不想要的，因为总是有需要的配置文件服务器，而不是在Git仓库。

这是我们正在使用的最干净的解决方案：

Fetch the newest code

git fetch

Delete all files which are being added, so there

are no conflicts with untracked files

for file in git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'
do
rm -f – “$file”
done

Checkout all files which were locally modified

for file in git diff --name-status | awk '/^[CDMRTUX]/ {print $2}'
do
git checkout – “$file”
done

Finally pull all the changes

(you could merge as well e.g. ‘merge origin/master’)

git pull

```

• 第一个命令获取最新的数据。

• 第二个命令检查是否有任何正在添加到存储库的文件，并从本地存储库中删除那些会导致冲突的未跟踪文件。

• 第三个命令checks-out所有在本地修改的文件。

最后，我们将更新到最新版本，但是这次没有任何冲突，因为repo中的未跟踪文件不再存在，所有本地修改的文件已经与存储库中的相同。

作者：duyi324
链接：https://www.jianshu.com/p/1ac2e1f99166
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

解决：

1

mysqldump -uroot -p -d test -S /tmp/mysql.sock | sed 's/AUTO_INCREMENT=[0-9]*\s*//g' > test.sql

一、平时忽略未提交的文件

从未提交过的文件可以用.gitignore
也就是添加之后从来没有提交（commit）过的文件，可以使用.gitignore忽略该文件
该文件只能作用于未跟踪的文件（Untracked Files），也就是那些从来没有被 git 记录过的文件
在.gitignore中写忽略文件或文件夹。注意相对路径是项目根数据，文件格式如下

1
2
3

/.gradle/
/.idea/
/local.properties

二、已经Push过的文件

需要删除Git仓库的文件，本址的文件需要保留，并且在以后提交中忽略

1、从本地Git缓存中删除文件

1
2
3
4

//忽略文件 aaa.txt
git rm --cached aaa.txt
//忽略文件夹 abc
git rm -r --cached abc

2、提交到仓库里面

1
2

git commit -m 'delete somefile'
git push

3、修改文件.gitignore，把刚才删除的文件或者文件夹加入.gitignore文件

1
2

/aaa.txt
/abc/

前言

在原来的电脑中，我的 hexo 备份在 GitHub上，除了一个 User Page 用来发布文章以外，还有一个 hexo-backup 的仓库，用来保存 hexo 的源代码。

在我换电脑以后，需要在新的电脑上重新部署 hexo 的环境，由于原来 hexo 的源代码及文稿与发布的仓库位于两个不同的仓库中，导致我需要下载一个仓库，但是要 hexo deploy 到另一个仓库中，这是一个很不合理的项目规划方案。所以，在网上搜索了一些教程以后，我重新规划了 GitHub 上面的代码仓库，用一个仓库同时存放 hexo 项目的发布版和源文件，但是这两个部分位于一个仓库的不同分支中。在以后需要重新部署 hexo 环境的时候，只用从一个仓库中下载代码，就可以获得源代码和发布版。

环境配置

创建 GitHub 仓库

首先点击 New Repository，创建一个新的代码仓库，在填写 Repository name 的时候，格式是 username.github.io (username 是你的 GitHub 账号用户名)。

本地安装环境配置

需要下载的软件有 Git、node.js 和 Hexo ，下载及安装方法不再赘述。

注意，在配置 Git 的时候，最好使用 git config 进行配置，这与 GitHub 在计算 contributions 次数的有关，也是就 GitHub 个人首页上绿色小点，用来统计每个人每天 commit 的次数有关。

在 GitHub 上统计代码仓库 commit 的次数时候，需要同时满足以下三点，才可以记为一次 commit：

• The email address used for the commits is associated with your GitHub account.
• The commits were made in a standalone repository, not a fork.
• The commits were made:
  • In the repository’s default branch (usually master)
  • In the gh-pages branch (for repositories with Project Pages sites)

也就是你的本地 Git 账号需要和 GitHub 账号一致。所以需要通过 git config 来配置本地 Git 的账号：

1
2

git config --global user.name "username"
git config --global user.email "username@example.com"

本地博客搭建流程

本流程与CrazyMilk的文章中的流程有所不同，如果是按照他的流程，在 hexo init 的时候，会删除本地的 .git 文件夹，所在流程上会略有不同。

以我的博客搭建流程为例：

1. 在 GitHub 上创建 liuhill.github.io 代码仓库
2. 本地下载和安装 git、node.js，并且使用 git config 配置本地 git 账号
3. 在本地合适的位置创建 liuhill.github.io 文件夹，作为本地博客根目录
4. 在本地 liuhill.github.io 依次执行：

   1 2 3 4

   npm install -g hexo hexo init npm install npm install hexo-deployer-git

5. 使用 GitHub 提示，将本地文件夹与远程代码仓库连接：

   1 2 3 4 5 6

   echo "# shiningdan.github.io" >> README.md git init git add README.md git commit -m "first commit" git remote add origin https://github.com/liuhill/liluhill.github.io.git git push -u origin master

6. 创建 master 和 hexo 分支。因为创建的代码仓库是 User Page，所以 master 分支是作为 hexo deploy 的分支，而 hexo 分支是保存源代码的分支。在 terminal 下执行命令：

   1 2 3

   git branch hexo //创建 hexo 分支 git push origin hexo //将本地分支 PUSH 到远端 git checkout hexo //切换本地分支为 hexo

7. 修改_config.yml中的deploy参数:

   1 2 3 4 5

   deploy: type: git repo: https://github.com/liuhill/liuhill.github.io.git branch: master message: hexo部署

   注意，branch 一定要为 master，因为 User Page 的发布版必须位于 master 分支下。
8. 修改 GitHub 网页中的配置，将 hexo 分支设置为默认分支。
9. 依次执行

   1 2 3

   git add . git commit -m “…” git push origin hexo

   提交网站相关的文件
   执行hexo generate -d生成网站并部署到GitHub上

日常发布以及备份

在备份源代码和源文件的时候，依次执行

1
2
3

git add .
git commit -m “…”
git push origin hexo

指令将改动推送到GitHub，此时源代码和源文件是被备份在 hexo 分支上。

再执行hexo generate -d发布网站到master分支上

重新部署

1. 使用git clone https://github.com/liuhill/liuhill.github.io.git 拷贝仓库（默认分支为hexo）
2. 在本地新拷贝的 liuhill.github.io文件夹下通过Git bash依次执行下列指令：

   1 2 3

   npm install -g hexo npm install npm install hexo-deployer-git

   （记得，不需要hexo init这条指令）

QUESTION

On my Windows XP workstation, I can find the machine I want to connect to in DNS with nslookup:

1
2
3
4
5
6

nslookup wolfman
Server: dns.company.com
Address: 192.168.1.38

Name: wolfman.company.com
Address: 192.168.1.178

On my Windows XP workstation, I can find the machine I want to connect to in DNS with nslookup:

1
2
3
4
5

nslookup wolfman
Server: dns.company.com
Address: 192.168.1.38
Name: wolfman.company.com
Address: 192.168.1.178

But, when I try to connect to that machine, I get an error telling me that the machine can’t be found (i.e., can’t be looked up in DNS):

1
2

C:\> ping wolfman
Ping request could not find host wolfman. Please check the name and try again.

I am able to connect if I use the IP address directly:

1
2
3
4
5
6
7
8

C:\> ping 192.168.1.178

Pinging 192.168.1.178 with 32 bytes of data:

Reply from 192.168.1.178: bytes=32 time=41ms TTL=126
Reply from 192.168.1.178: bytes=32 time=41ms TTL=126
Reply from 192.168.1.178: bytes=32 time=44ms TTL=126
Reply from 192.168.1.178: bytes=32 time=38ms TTL=126

ANSWER 1

I believe that nslookup opens a winsock connection on the DNS port and issues a query, whereas ping uses the DNS Client service. You could try and stop this service and see whether this makes a difference.

Some commands that will reinitialize various network states :

• Reset WINSOCK entries to installation defaults : netsh winsock reset catalog
• Reset TCP/IP stack to installation defaults : netsh int ip reset reset.log
• Flush DNS resolver cache : ipconfig /flushdns
• Renew DNS client registration and refresh DHCP leases : ipconfig /registerdns
• Flush routing table : route /f (this will remove all your gateways until you restart!)

ANSWER 2

Try ping with hostname followed by a dot. So instead of ping wolfman use ping wolfman.

That should get you resolving without having to do workarounds with hosts file, etc.

今天，9岁的女儿自己参加花样游泳集训了，比赛、集训共10天。以前训练总是挨批评，一直抗拒参加集训，现在终于愿意参加比赛了。一上车就认识了新朋友，有小朋友同行，出发的心情不错。

前几天，顺路送她去课外班补课。考虑她要在那儿呆一整天，中午可能无聊。在车上我说

1
2
3
4

“中午我来找你吃饭吧？”，
“妈妈帮我定了”。
“我中午过来找你玩吧，中午你一个人多无聊”，
“我们老师给我们放电影”。

好吧，是我自作多情了…

在刚出生的时候，我默默的想“我一定会放手，让你自己高飞！” 没想到,她想飞的心思来得这么快~

1. windows 测试

命令行输入以下命令：

1

w32tm /stripchart /computer:ntp_server_address

例如：w32tm /stripchart /computer:time.windows.com

2. linux 测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

[root@centos6 ~]# ntpdate -d ntp1.aliyun.com
27 Mar 22:04:38 ntpdate[1049]: ntpdate 4.2.6p5@1.2349-o Wed Dec 19 20:22:35 UTC 2018 (1)
Looking for host ntp1.aliyun.com and service ntp
host found : 120.25.115.20
transmit(120.25.115.20)
receive(120.25.115.20)
transmit(120.25.115.20)
receive(120.25.115.20)
transmit(120.25.115.20)
receive(120.25.115.20)
transmit(120.25.115.20)
receive(120.25.115.20)
server 120.25.115.20, port 123
stratum 2, precision -25, leap 00, trust 000
refid [120.25.115.20], delay 0.07951, dispersion 0.00424
transmitted 4, in filter 4
reference time:    e046016e.965c7e00  Wed, Mar 27 2019 22:04:30.587
originate timestamp: e0460177.12bce60a  Wed, Mar 27 2019 22:04:39.073
transmit timestamp:  e0460177.04f47dc5  Wed, Mar 27 2019 22:04:39.019
filter delay:  0.09312  0.07951  0.08475  0.09390 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 0.004349 0.010768 0.007720 0.019682
         0.000000 0.000000 0.000000 0.000000
delay 0.07951, dispersion 0.00424
offset 0.010768
27 Mar 22:04:39 ntpdate[1049]: adjust time server 120.25.115.20 offset 0.010768 sec

3. 国内常用时间服务器地址

• 210.72.145.44 (国家授时中心服务器IP地址)
• 133.100.11.8 日本 福冈大学
• time-a.nist.gov 129.6.15.28 NIST, Gaithersburg, Maryland
• time-b.nist.gov 129.6.15.29 NIST, Gaithersburg, Maryland
• time-a.timefreq.bldrdoc.gov 132.163.4.101 NIST, Boulder, Colorado
• time-b.timefreq.bldrdoc.gov 132.163.4.102 NIST, Boulder, Colorado
• time-c.timefreq.bldrdoc.gov 132.163.4.103 NIST, Boulder, Colorado
• utcnist.colorado.edu 128.138.140.44 University of Colorado, Boulder
• time.nist.gov 192.43.244.18 NCAR, Boulder, Colorado
• time-nw.nist.gov 131.107.1.10 Microsoft, Redmond, Washington
• nist1.symmetricom.com 69.25.96.13 Symmetricom, San Jose, California
• nist1-dc.glassey.com 216.200.93.8 Abovenet, Virginia
• nist1-ny.glassey.com 208.184.49.9 Abovenet, New York City
• nist1-sj.glassey.com 207.126.98.204 Abovenet, San Jose, California
• nist1.aol-ca.truetime.com 207.200.81.113 TrueTime, AOL facility, Sunnyvale, California
• nist1.aol-va.truetime.com 64.236.96.53 TrueTime, AOL facility, Virginia

• ntp.sjtu.edu.cn 202.120.2.101 (上海交通大学网络中心NTP服务器地址）
• s1a.time.edu.cn 北京邮电大学
• s1b.time.edu.cn 清华大学
• s1c.time.edu.cn 北京大学
• s1d.time.edu.cn 东南大学
• s1e.time.edu.cn 清华大学
• s2a.time.edu.cn 清华大学
• s2b.time.edu.cn 清华大学
• s2c.time.edu.cn 北京邮电大学
• s2d.time.edu.cn 西南地区网络中心
• s2e.time.edu.cn 西北地区网络中心
• s2f.time.edu.cn 东北地区网络中心
• s2g.time.edu.cn 华东南地区网络中心
• s2h.time.edu.cn 四川大学网络管理中心
• s2j.time.edu.cn 大连理工大学网络中心
• s2k.time.edu.cn CERNET桂林主节点
• s2m.time.edu.cn 北京大学

原文: (今日头条、抖音推荐算法原理全文详解) https://mp.weixin.qq.com/s/e0KgNOn3vIKn-nc1l-XBqw

1、系统概览

1.1）推荐系统

推荐系统就是拟合一个用户对内容满意度的函数，这个函数需要输入三个维度的变量：

• 内容特征：提取不同内容类型的特征做好推荐。
• 用户特征：兴趣标签，职业、年龄、性别等。
• 环境特征：在工作场合、通勤、旅游等不同的场景，信息偏好有所偏移。

1.2）推荐系统的目标

• 可量化目标：点击率、阅读时间、点赞、评论、转发包括点赞
• 无法直接衡量的目标
  • 广告&特型内容频控
  • 低俗内容打压&频控
  • 标题党，低质，恶心内容打压
  • 重要新闻置顶&强插&加权
  • 低级别账号内容降权

1.3）典型推荐算法

• 协同过滤模型
• 监督学习算法Logistic Regression模型
• 基于深度学习的模型
• Factorization Machine
• GBDT

注：需要非常灵活的算法实验平台，可以支持多种算法组合，包括模型结构调整。

1.4）推荐特征

• 第一类是相关性特征

评估内容的属性和与用户是否匹配.显性的匹配包括关键词匹配、分类匹配、来源匹配、主题匹配等.隐性匹配从用户向量与内容向量的距离可以得出,如FM模型。

• 第二类是环境特征

包括地理位置、时间。这些既是bias特征，也能以此构建一些匹配特征。

• 第三类是热度特征

包括全局热度、分类热度，主题热度，以及关键词热度等。内容热度信息在大的推荐系统特别在用户冷启动的时候非常有效。

• 第四类是协同特征

它可以在部分程度上帮助解决所谓算法越推越窄的问题。通过用户行为分析不同用户间相似性，比如点击相似、兴趣分类相似、主题相似、兴趣词相似，甚至向量相似，从而扩展模型的探索能力。

1.5）模型训练

1. 线上服务器记录实时特征
2. 导入到Kafka文件队列中
3. 客户端回传推荐的label构造训练样本
4. 根据最新样本进行在线训练更新模型参数
5. 线上模型得到更新

1.6）召回策略

• 为什么需要召回策略？
  • 内容量非常大，加上小视频内容有千万级别，推荐系统不可能所有内容全部由模型预估。
  • 召回策略，每次推荐时从海量内容中筛选出千级别的内容库
  • 召回策略最重要的要求是性能要极致，一般超时不能超过50毫秒
• 召回策略的方案
  • 离线维护一个倒排。key可以是分类，topic，实体，来源等。
  • 排序考虑热度、新鲜度、动作等
  • 线上召回可以迅速从倒排中根据用户兴趣标签对内容做截断，高效的从很大的内容库中筛选比较靠谱的一小部分内容

1.7）推荐系统的数据依赖

• 推荐模型的特征抽取需要用户侧和内容侧的各种标签。
• 召回侧需要获取用户侧和内容侧的各种标签。
• 内容分析和用户标签挖掘是搭建推荐系统的基石。

2、内容分析

2.1 文本分析

• 推荐系统的应用
  • 用户兴趣建模（user profile）: 如：给喜欢阅读”互联网”文章打上“互联网”标签。
  • 帮助内容推荐: “魅族”的内容推荐给关心“魅族”的用户
  • 生成频道内容: “德甲”的内容进“德甲频道”
• 今日头条抽取的文本特征
  • 语义标签类特征
    • 显式语义特征: 为文章打上语义标签。这部分标签是由人定义的特征，每个标签有明确的意义，标签体系是预定义的。
    • 隐式语义特征：主要是topic特征和关键词特征，其中topic特征是对于词概率分布的描述，无明确意义；而关键词特征会基于一些统一特征描述，无明确集合。
  • 文本相似度特征: 用户反馈最大的问题之一就是为什么总推荐重复的内容。这个问题的难点在于，每个人对重复的定义不一样。
  • 质量相关特征: 判断内容是否低俗，色情，是否是软文，鸡汤？

2.2 头条语义标签的 特征 & 使用场景

• 分类：user profile; 过滤频道内容； 推荐召回； 推荐特征
• 概念：过滤频道内容； 标签搜索；推荐召回（Like）
• 实体：过滤频道内容；标签搜索；推荐召回（Like）

2.3 标签分层

• 每个层级粒度不一样，要求也有区别
• 分类体系要求覆盖全，希望任何一篇文章，总能找到合适的分类，精确性要求不高
• 实体体系不要求覆盖全，只要覆盖每个领域人们的人物、机构，作品，产品即可
• 概念体系负责表达比较精确，但是有属于抽象概念的语义，也不要求覆盖全

分类的目标是覆盖全面，希望每篇内容每段视频都有分类；而实体体系要求精准，相同名字或内容要能明确区分究竟指代哪一个人或物，但不用覆盖很全。

概念体系则负责解决比较精确又属于抽象概念的语义。

2.4 为什么要语义标签

优点：

• 隐式语义特征已经可以很好的帮助推荐
• 语义标签做好的难度和资源投入远大于隐式语义特征
  缺点：
• 频道，兴趣表达等重要产品功能需要有一个有明确定义，容易理解的文本标签体系。
• 语义标签的效果是检查一个公司NLP技术水平的试金石

语义标签的效果是检查一个公司NLP技术水平的试金石。

• 元分类器类型: SVM、CNN、RNN

2.2 图片分析

2.3 视频分析

3、用户标签

3.1 兴趣特征

• 感兴趣的类别和主题
• 感兴趣的关键词
• 感兴趣的来源
• 基于感兴趣额的用户聚类
• 各种垂直兴趣特征（车型，体育球队，股票等）

3.2 身份特征

• 性别

性别信息通过用户第三方社交账号登录得到

• 年龄

年龄信息通常由模型预测，通过机型、阅读时间分布等预估。

• 常驻点

常驻地点来自用户授权访问位置信息，在位置信息的基础上通过传统聚类的方法拿到常驻点。
常驻点结合其他信息，可以推测用户的工作地点、出差地点、旅游地点。

3.3 行为特征

• 晚上才看电视
• 打开手机时间

3.4 对浏览内容标签进行数据处理策略

• 过滤噪声。通过停留时间短的点击，过滤标题党。
• 热点惩罚。对用户在一些热门文章（如前段时间PG One的新闻）上的动作做降权处理。理论上，传播范围较大的内容，置信度会下降。
• 时间衰减。用户兴趣会发生偏移，因此策略更偏向新的用户行为。因此，随着用户动作的增加，老的特征权重会随时间衰减，新动作贡献的特征权重会更大。
• 惩罚展现。如果一篇推荐给用户的文章没有被点击，相关特征（类别，关键词，来源）权重会被惩罚。当然同时，也要考虑全局背景，是不是相关内容推送比较多，以及相关的关闭和dislike信号等。

3.5 用户标签挖掘

• 第一版: 用户标签批量计算框架

  1. Scribe收集原始日志
  2. 导入Kafka文件队列
  3. 导入Hadoop集群
  4. MapReduce Job批量计算
  5. 写入高性能分布式存储系统
  6. 线上读取高性能分布式存储系统

• 第二版: 用户标签流式计算框架

  1. Scribe收集原始日志
  2. 导入Kafka文件队列
  3. 导入Storm集群
  4. 从高性能存储系统读取base
  5. 基于动作bath更新用户模型
  6. 线上直接读取高性能存储系统

• 流式计算和批量计算混合使用

  • 大部分user profile采用流式计算

    • 各个粒度的兴趣标签
    • 垂直领域profile

  • 对时效性不敏感的user profile采用Batch计算

    • 性别，年龄
    • 常驻地点

4、评估更新

一个事情没法评估就没法优化

4.1 对推荐系统产生影响的因数

• 候选内容集合的变化
• 召回模块的改进和增加
• 推荐特征的增加
• 推荐系统架构的改进
• 算法参数的优化
• 规则策略的改变

4.2 评估系统要求

• 完备的评估系统
• 强大的实验平台
• 易用的实验分析工具

4.3 推荐系统评估需要注意的问题

• 兼顾短期指标与长期指标
• 要兼顾用户指标和生态指标
• 注意协同效应的影响，有时候需要彻底的统计隔离

4.4 强大实验平台的优点

• 同时在线的实验多: 每天数百个
• 高效管理和分配实验流量
• 降低实验，分析成本，提高算法迭代效率

4.5 人工抽样评估分析

• 线上实验平台只能通过指标变化推测用户体验
• 数据指标和用户体验存在差异
• 重大改进需要人工评估二次确认
• 头条利用内部和外包团队进行例行的人工抽样评估

5 内容安全

5.1 头条内容安全机制

5.2 分享内容识别技术

• 鉴黄模型
• 谩骂模型
• 低俗模型

1

注重召回率，准确率甚至可以牺牲一些。谩骂模型的样本库同样超过百万，召回率高达95%+，准确率80%+。如果用户经常出言不讳或者不当的评论，我们有一些惩罚机制。

5.3 泛低质内容识别技术

1

像假新闻、黑稿、题文不符、标题党、内容质量低等等，这部分内容由机器理解是非常难的，需要大量反馈信息，包括其他样本信息比对

• 低质模型是通过对评论做情感分析，结合用户其它的负反馈信息（举报、不感兴趣、踩）等信息，来解决很多语义上的低质问题，诸如题文不符、有头无尾、拼凑编造、黒稿谣言等
• 目前低质模型的准确率为70%，召回率为60%，结合人工复审召回率能做到95%