“百度发展史”这五个字摊开看就是一部中文互联网信息获取方式的历史。我见过不少人想把它当公司编年史来查资料但真正值得细细拆解的是这家公司在几个关键节点上的技术选型和产品决策从关键词检索到内容生态从搜索广告到信息流推荐再到如今被大模型重写的新一代搜索形态。这篇文章我想从一个从业者的角度把这几个阶段背后的逻辑梳理一遍——它为什么那样选择、当时的行业环境逼着它做什么、这些做法对后来的中文互联网产生了什么影响。不管你是做搜索相关技术、研究互联网产品还是单纯好奇一个搜索框背后有多复杂应该都能在这篇“发展史”里找到自己关心的那一段。1. 搜索技术地基爬虫、索引、排序到底在解决什么问题1.1 数据管线三件套爬虫、索引系统与中文分词聊发展史之前得先把搜索引擎这个“产品”的底层技术拆开。一个搜索框背后是三套核心系统抓取系统、索引系统、排序系统。抓取系统也叫爬虫它的任务是让一个URL出发沿着网页上的链接不断往下爬把网页内容抓下来。早期整个互联网网页数量有限爬虫策略没那么复杂但很快大家就发现一个贪心的爬虫会把服务器带宽吃光还会给目标网站造成不小的压力。所以后来爬虫必须懂“礼貌”robots协议规定了哪些路径不能爬抓取队列里要有优先级调度去重要基于内容哈希而不是简单URL比对。这里面的坑非常多比如两个域名指向同一个服务器、同一篇文章有多个转载版本都会让索引系统存大量重复数据。真正跑过爬虫的人都知道抓取这件事的工程复杂度远大于算法复杂度调度策略、限速规则、异常重试、增量抓取每一环都能写出一篇文章。索引系统是搜索引擎真正“存储”的地方。网页文本是长字符串不可能每次查询都全库扫描于是就有了倒排索引——把文档拆成一个个词再记录每个词出现在哪些文档里。查询“人工智能 搜索引擎”时系统只需要分别找到两个词对应的文档列表求交集就能锁定候选集。这个设计听起来简单但真正落地时要处理的问题很多索引怎么压缩才能塞进内存、词表和文档编号怎么分配才能快速合并、磁盘索引和内存索引怎么分层、更新频率如何控制。可以说整个搜索引擎的响应速度绝大部分取决于索引层的工程水平。说到中文这里有个英文搜索不用头疼的问题分词。英文单词天然有空格分隔中文是连续汉字串“机器学习算法”可以切分成“机器/学习/算法”也可能切错成“机器/学习/算法”的另一种组合切分错误会直接影响召回准确度。所以中文搜索引擎从第一天起就必须做词法分析这也倒逼早期团队在自然语言处理上投入大量精力。到今天分词已经不单纯是“查词典”了新词发现、领域词典、统计模型都参与进来但本质上还是在解决同一个问题让计算机知道一句中文哪里是词的边界。1.2 排序算法的进化从词频统计到链接权重结果集有了接下来的核心问题是这么多网页都包含关键词谁排前面最早的做法很简单词频高、位置靠前就排前面。但很快就发现这有个致命弱点太容易被作弊了只要在页面里堆满关键词排名就会往上蹿。那个年代你甚至能看到网页底部密密麻麻的小字关键词就是为了“骗”过排序系统。这种思路本质上是在用“文档自身信息”做排序只要内容和自己相关不用看外部环境所以只要操纵页面内容就能操纵排名。于是基于链接关系的排序思想出现了一个网页被越多重要网页链接它的重要性就越高。这是搜索引擎历史上很重要的一个思路它把互联网当成一个“引文网络”来处理类似于学术论文引用。一个网页如果被很多高质量页面引用它本身就更可能是高质量的。这个思路后来被中文搜索引擎采用并且做了一系列改进加入时间因子让新内容有机会浮上来引入站点权重让权威站点的内页更容易获得信任再把用户点击行为反馈融入排序用户点了哪个结果、停留多久、是否马上返回都会影响这个结果后续的排名。这段进化给做产品的人一个启发靠“自说自话”做出来的质量判断总是脆弱的真正稳定的判断依据藏在关系里、行为里而不在内容表面。1.3 亲手验证的路径搭一个迷你搜索你会踩到哪些坑说了这么多原理如果你真想理解搜索引擎我建议自己动手搭一个迷你版。不用做得多完善三千行左右的代码就能让你把整条链路跑通。你一定会在实操中遇到这些事爬虫跑了不到十分钟就被对方服务器返回403你要学会设置合理的User-Agent和抓取间隔。抓回来的网页里全是HTML标签去标签、转码、去停用词之后真正能用的文本少得可怜。建立倒排索引的时候你会发现内存根本不够用必须做归并排序把索引写进磁盘。排序模型调来调去最后发现你得先处理垃圾内容不然后面的算法都是白搭。这个过程做一遍你会发现搜索技术并不是什么神秘黑盒它是一套非常朴素的工程系统。理解了这套系统你再看今天的大模型搜索、智能体搜索就能清楚它们到底改变了哪一层、没有改变哪一层。2. 内容生态决策搜索公司为什么要下场“做内容”2.1 搜索的“供给侧困境”搜索引擎本质上是一个连接用户需求和内容供给的中介。但做中介最怕的是什么供给端不在自己手里。在早期搜索结果指向的是门户新闻、论坛帖子和个人网站。质量参差不齐不说最大的问题是很多长尾搜索词根本没有内容可以匹配。你搜一个很冷门的问题可能什么都找不到用户带着疑问来带着失望走。这种体验对整个搜索引擎的口碑是一种慢性伤害因为搜索引擎的“答案质量”不只取决于排序算法还取决于你有没有足够多、足够新、足够优质的内容可以去排。这里有一个很有意思的行业细节搜索团队经常会在后台看到大量搜索词指向“零结果页面”。用户明明在找某个东西但全网就是没有对应内容。这些零结果搜索词就是最真实的需求信号。与其等着内容生产者慢慢生长出来不如自己下场把内容供给补上。这和今天很多平台自己投资做自制内容、自制剧是一个道理光做渠道不够关键位置上的供给必须自己掌控。2.2 贴吧、知道、百科的分工在内容生态的布局上当时围绕搜索框构建了一整套自有内容产品分别是贴吧、知道、百科。这三样东西表面看都是“社区”但仔细看会发现它们各自解决完全不同的需求贴吧解决的是“兴趣聚合”。它的产品形态是“按关键词建吧”用户可以直接为一个兴趣、一个话题、甚至一个模因建立讨论区。贴吧的产品逻辑对搜索引擎非常友好因为“吧”天然就用搜索词命名用户搜一个词搜出来的不只是一个网页而是一个持续有人活跃的社区。兴趣类需求的用户粘性非常高这也让贴吧成了很多小众爱好的聚集地。知道解决的是“个性化提问”。它的价值在于覆盖了搜索结果里没有现成答案的长尾需求。百科解决不了的问题、贴吧没人讨论过的问题用户都可以直接在知道上提问等回答。问答产品看起来简单但它是搜索生态里很重要的补充因为它把“没有答案”变成了“有答案的可能”。百科解决的是“权威知识入门”。它的定位是给常见概念提供一个相对可靠的基础解释。百科类产品最大的特点是结构化每个词条都按照定义、历史、分类、争议等章节来组织这种结构恰好是搜索引擎最乐意展示的内容因为它能让用户快速判断这个页面是否匹配自己的需求。2.3 冷启动与运营细节内容产品从0到1是出了名的难尤其是知识社区这类UGC产品。这三类产品当时能跑通关键不是“搞个产品挂上去”就完事而是靠一套非常重的冷启动运营打法。百科类产品冷启动阶段要像编辑词典一样先把最常用的几千个概念词条打底做出来保证用户随便搜一个常见词都能看到像样的词条。这些词条一开始不是用户写的是早期团队或核心志愿者一条条创建的。打底完成后再开放编辑权限让大众参与同时安排审核机制防止明显错误信息扩散。没有这层“打底”直接开放编辑大概率换来的是空词条和一堆低质内容。问答类产品更依赖“答主”供给。早期的冷启动几乎都是运营自己提问、自己回答把整个搜索路径跑通让用户感觉“这地方真的有人回答问题”再逐步引入真正的用户问答。这个过程看起来很笨但非常关键一个空荡荡的社区是留不住任何用户的。后来问答类产品普遍采用“邀请回答”“大V激励”等方式本质上都是在解决同一个冷启动难题先让内容密度达到用户愿意停留的阈值。从产品决策角度看当时做这些内容产品不是拍脑袋砸钱而是从搜索数据里看到了需求空缺。大量搜索词都指向空结果页这些词就是最直接的产品方向。用数据驱动内容建设这件事放到今天依然是内容平台冷启动的最有效路径。3. 商业系统暗线竞价广告背后的排序与定价逻辑3.1 搜索广告是“意图生意”搜索引擎的商业化是整个行业发展史上避不开的话题。搜索广告和展示广告最大的不同在于用户是带着意图来的。用户搜“装修”当然比一篇文章里夹带的装修banner更有商业价值。所以搜索广告本质上是“意图生意”。理解这种商业模式要先看用户心理。搜索用户和刷信息流的用户处在完全不同的心态里搜索是主动表达需求信息流是被动接收内容。主动表达的意图有多值钱一个用户在搜索框里输入“北京市海淀区装修公司哪家好”这条query背后是一个明确消费意愿、有预算、有地理范围的需求。广告系统如果能精准匹配这样的需求转化率会远高于普通展示广告。但意图也分强弱。品牌词搜“某品牌官网”的意图很明确就是找某个具体对象通用词搜“装修公司”的意图比较宽用户还在比较选项长尾疑问词搜“装修预算怎么定”的意图更强且更接近决策前夜。搜索广告系统要做的就是把不同强弱的高业价值查询词和合适的广告主匹配起来。3.2 排序公式与计费机制搜索竞价广告的排序公式并不是简单的谁出价高谁排前面。如果只看价格广告主可以通过无限抬价霸占位置但广告质量差点击少平台营收也上不来。所以主流的搜索广告排序采用“出价 × 预估点击率 × 质量分”综合打分的方式。拆开来看这三部分出价代表广告主愿意支付的最高价格预估点击率是由历史点击数据训练模型预测出来的反映用户点击这条广告的可能性质量分衡量广告与搜索词的相关性以及落地页体验。三者的乘积决定广告的排序位置。这个公式的巧妙之处在于它把“用户反馈”也放进了排序因子。一个广告即使出价很高如果用户就是不点位置也会往下掉这就倒逼广告主认真优化创意和落地页而不是只靠砸钱。广告点击背后的计费逻辑也很关键。搜索广告大多采用“广义第二高价”机制意思是广告实际付出的价格不是自己的出价而是刚好赢过下一位所需的价格加一点点。举一个具体例子假设你出价10元排序在你下一位的广告主出价8元你实际只需要付8元多一点。这个机制的聪明处在于广告主不用反复调低出价去试探底线平台也能避免出价虚高导致的恶性抬价。如果你在投放后台看到一个词点击成本比自己出价低一截不要意外很可能就是因为有你下一位的对手在“兜底”。3.3 广告与自然结果的边界问题写这一段可能会有人问搜索引擎靠广告赚钱会不会伤害用户体验这个问题其实从一开始就存在。任何搜索引擎在商业化时都面临同一个课题广告与自然结果的边界在哪里、用户如何分得清哪些是广告、广告相关度不足时要不要强行展示。我的看法是这个矛盾永远不会消失但技术可以在两者之间找平衡。主流的做法包括用历史数据回归决策广告位的数量和位置不同词性的查询展示不同密度的广告广告与查询相关性低于阈值时直接不展示宁缺毋滥广告区域必须有明确的视觉区隔用户能一眼识别。这些决策都可以被量化测试AB实验是基本手段判断标准就看长线用户留存和广告主ROI是不是双增。还要补充一点搜索广告的意图理解也在持续进化。移动时代后用户可能在搜索框里输入品牌词、比较词、售后词广告系统开始按意图分类来分配预算。比如“哪个牌子好”是比较意图适合展示多个品牌的对比广告“怎么退货”是售后意图更适合展示官方客服入口而不是销售广告。意图识别越精准广告系统才能既保证收入用户体验又不至于恶化。4. 移动时代重构从“人找信息”到“信息找人”4.1 搜索入口被拆解的原因PC时代搜索是网民进入互联网的“第一站”无论你想干什么第一步都是先打开搜索框。这种入口级地位让搜索引擎在整个PC互联网时代拥有非常强的内容分发权力。但移动互联网把这一切拆掉了。手机桌面上的App们接管了用户的信息消费入口。聊天、短视频、新闻资讯、电商每个超级App都在自己的围墙里提供搜索或者干脆用推荐流替代搜索。用户的搜索行为开始分化想买东西直接去电商平台搜想刷内容直接打开短视频App想问问题直接在社区里发帖。这些平台内部都有自己的搜索结果用户对“全网搜索”这个概念的依赖度自然就降下来了。这里有一个结构性原因PC时代的信息是开放的网页搜索引擎可以去爬移动时代的内容都封在App的服务端里对外不开放接口。搜索引擎默认变成了“爬不到内容的空壳”能搜到的只有那些还在坚持做PC页面的站点。一边是用户不来了一边是内容也爬不到了这种双削弱才是搜索公司必须转型的根本原因。4.2 信息流推荐系统的核心组件面对移动端流量被分流的现实搜索公司必须回答一个问题用户不来搜索框找信息你怎么把信息送到用户面前答案是信息流推荐。传统搜索是“人找信息”用户输入词、系统给结果信息流是“信息找人”系统根据用户画像和兴趣模型在用户刷手机的碎片时间里不断推荐内容。这个逻辑逆转本质上是从被动响应query到主动预测兴趣的转变。做推荐的难度不比搜索低甚至更难因为搜索有明确的query做约束推荐完全没有。推荐系统的基础设施可以拆成几块内容理解负责给每篇文章、每条视频打标签建立类目、实体、话题、风格等多个维度的结构化描述用户画像是通过点击、时长、点赞、评论等行为构建兴趣向量回答“这个用户是什么样的人”的问题召回与排序是先用各种策略从海量内容中召回候选集再用模型精准打分排序还有探索与利用机制既要推荐用户已经表现出兴趣的内容也要留一部分流量推荐新品种否则用户兴趣圈会越缩越窄。这套体系做下来信息流平台的用户时长和广告库存都被大大充实了。从商业上讲推荐流消化内容的速度极快广告插入的场景极为丰富这是搜索框做不到的。所以“搜索信息流”双引擎的模式本质上是用推荐来填补搜索之外的用户时长空白把“用完即走”变成“没事也来刷刷”。4.3 小程序与内容围墙新的生态博弈移动时代还有一个棘手的问题大量内容被封存在超级App里搜索引擎爬不到。为了突围搜索公司做了类似小程序、托管页这样的解决方案把开发者和内容提供者接入自己的生态让内容可以在搜索结果里内嵌呈现。这个思路本质上是“用流量换内容”你接入我的生态我给你全链路流量和完整用户服务但你的内容不再提供给外部搜索引擎。这形成了今天很多内容平台都面临的“围墙花园”问题互联网从一个开放互连的网络慢慢退化成若干个封闭群岛。每个岛上都有人、有内容、有交易闭环但岛与岛之间不互通。开发者为什么愿意入驻因为在围墙内能直接触达大量用户省去了独立推广的成本。对用户来说好处是搜索结果可以直接完成服务坏处是信息选择面被平台圈住了你看到的只是平台愿意让你看到的内容。这个生态博弈到今天还在继续。这提醒我们搜索引擎的本质价值从来不只是技术而是它对开放互联网内容的索引能力。一旦内容供给从开放走向封闭搜索引擎的价值就要打折扣。移动时代的这场较量本质上是“开放索引”和“封闭生态”两种信息分发哲学之间的较量。5. AI重写搜索大模型时代的底层逻辑与产品形态5.1 搜索公司做AI的三重优势人工智能并不是搜索公司的新跨界而是老本行。搜索从第一天起就在做自然语言理解、语义匹配、用户意图预测这些本质上都是AI问题。大模型的出现更是给搜索公司提供了一条比传统检索式系统更顺畅的路径。从算力、数据、场景三个维度看搜索公司和大模型高度匹配。数据方面多年海量查询日志和点击行为是训练语言模型理解“用户在问什么”的天然语料。用户怎么组织问题、什么问题搜不到、点了哪些结果、结果满不满意这些信息对训练对话模型尤其有价值。算力方面大规模搜索引擎本身就需要庞大的分布式计算集群相比从零开始攒算力的团队搜索公司的集群规模和调度经验是现成的。场景方面用户每天产生大量新问题搜索结果可以被实时点击反馈验证模型好不好用立刻就知道。这三点放在一起结论很清楚搜索公司做AI模型训练数据和产品反馈之间能形成闭环。这个闭环是很多纯算法团队很难复制的。5.2 RAG让模型“先查再答”的工程架构生成式AI搜索和经典检索式搜索不是互相替代而是可以融合成一条新管线。现在大家常说的检索增强生成RAG简单说就是用户提问后系统先通过传统搜索引擎召回一批相关资料再把资料和问题一起交给大模型生成答案。相比直接让大模型凭记忆回答RAG有明显的工程优势。第一知识更前沿模型训练数据有截止日期但检索到的网页内容是实时的新发布的事件、新出的政策、刚上市的产品都能覆盖。第二减少幻觉回答有了资料作为依据模型只能基于给它的材料推理胡说八道的概率大大降低。第三可追踪可信赖答案可以附上引用来源用户能自己点开核对这在医疗、金融、法律等信息敏感性高的场景里尤其重要。这也是为什么很多新一代搜索产品都采用“先检索、后生成”的架构。它既保留了大模型强大的自然语言理解和生成能力又保留了检索系统的实时性和可验证性。你甚至可以这样理解大模型负责“组织语言、串联逻辑”检索系统负责“找材料、给论据”两者配合比任何一个单独上场都可靠。工程上RAG里的检索部分可以直接复用成熟的索引和召回系统这让传统搜索团队的技术积累并没有白费。5.3 智能体搜索从工具变成执行层大模型改变的不仅是搜索结果还改变了搜索这个交互接口。过去任何问题都只能用“关键词点击”来完成寻找现在用户可以直接用一句自然语言描述需求系统通过多轮对话追问细节再调动多个工具完成任务。这种形态行业里习惯称为智能体。它能订票、能比较商品、能规划行程搜索将不再只是一个信息查询工具而是变成“帮你完成任务”的执行层。从技术链路看一个完整的智能体需要四步意图理解搞清楚用户真正想要什么任务规划把大目标拆成子任务工具调用对接外部系统和数据源结果验证检查输出是不是真的解决了问题。每一步都依赖大模型的推理能力也需要传统系统的计算结果来兜底。搜索公司做智能体有一个天然的场景优势。用户来搜索就是带着任务来的他天然愿意接受一个能帮他做完事的产品。做出来之后用户每一次提问、每一次工具的调用、每一个结果的反馈又都会成为模型迭代的数据。我还是想说那句话互联网公司做AI最稀缺的不是模型本身而是场景和数据闭环。搜索场景的数据是大量持续产生的模型可以不断从用户反馈里学习什么样的答案更让人满意这几乎是天然的训练场。6. 从这段发展史里沉淀下来的几点经验6.1 生态护城河的优先级这段发展史里有一个反复出现的模式单纯的技术优势带来的领先往往需要靠生态布局来固化。搜索算法可以抄袭、可以追赶但多年积累的内容资产和用户社区很难在一夜之间复制。这也解释了为什么很多技术公司在站稳一个赛道后会疯狂做周边产品核心逻辑不是多元化而是用生态给技术盖一层护城河。同理大模型时代模型参数可能会很快被追平但围绕搜索场景积累下来的用户习惯、内容生态、反馈数据是后来者很难短期复制的。6.2 用户要的是“答案”而不是“搜索框”站在今天回看用户并不在乎背后是搜索框还是对话框他们在乎的是问题有没有被解决、答案是不是准确。这也是为什么信息流、推荐、大模型生成的演化方向都不是“让搜索框更好用”而是“绕过搜索框直接给答案”。做产品的人如果能意识到这一点很多战略上的纠结会少很多。不要在形式上死守一个UI形态要盯着用户本质诉求去演化交互方式搜索如此很多互联网产品也是如此。6.3 数据闭环是AI时代产品竞争的真壁垒我自己做产品这几年越来越觉得大模型本身会逐步变成公共基础设施真正的差别在于谁能把场景和数据闭环跑得更快。搜索场景天然具备这种闭环用户提问、系统回答、用户反馈、模型迭代。这个循环跑得越久系统对真实需求的理解就越深产品就越难被替代。所以很多AI产品经理之间经常互相提醒不要和对手比参数大小要比谁更快构建场景、更快跑通数据反馈闭环。算法可以追赶数据飞轮转起来之后很难被打破。6.4 最后的个人体会回看这段“发展史”我最大的感受是技术浪潮会一浪接一浪地更替但“高效准确地匹配信息和需求”这个本质需求从来不会变。谁能用更自然的方式更精准地满足它谁就能在新时代重新建立自己的入口。搜索是如此推荐是如此AI对话也是如此。对做产品、做技术的同行来说与其焦虑下一个风口在哪里不如持续追问在当前的技术条件下用户获得答案的路径还能不能更短一点、更准一点、更顺一点。这件事想透了方向就不会跑偏。
“百度发展史”这五个字摊开看就是一部中文互联网信息获取方式的历史。我见过不少人想把它当公司编年史来查资料但真正值得细细拆解的是这家公司在几个关键节点上的技术选型和产品决策从关键词检索到内容生态从搜索广告到信息流推荐再到如今被大模型重写的新一代搜索形态。这篇文章我想从一个从业者的角度把这几个阶段背后的逻辑梳理一遍——它为什么那样选择、当时的行业环境逼着它做什么、这些做法对后来的中文互联网产生了什么影响。不管你是做搜索相关技术、研究互联网产品还是单纯好奇一个搜索框背后有多复杂应该都能在这篇“发展史”里找到自己关心的那一段。1. 搜索技术地基爬虫、索引、排序到底在解决什么问题1.1 数据管线三件套爬虫、索引系统与中文分词聊发展史之前得先把搜索引擎这个“产品”的底层技术拆开。一个搜索框背后是三套核心系统抓取系统、索引系统、排序系统。抓取系统也叫爬虫它的任务是让一个URL出发沿着网页上的链接不断往下爬把网页内容抓下来。早期整个互联网网页数量有限爬虫策略没那么复杂但很快大家就发现一个贪心的爬虫会把服务器带宽吃光还会给目标网站造成不小的压力。所以后来爬虫必须懂“礼貌”robots协议规定了哪些路径不能爬抓取队列里要有优先级调度去重要基于内容哈希而不是简单URL比对。这里面的坑非常多比如两个域名指向同一个服务器、同一篇文章有多个转载版本都会让索引系统存大量重复数据。真正跑过爬虫的人都知道抓取这件事的工程复杂度远大于算法复杂度调度策略、限速规则、异常重试、增量抓取每一环都能写出一篇文章。索引系统是搜索引擎真正“存储”的地方。网页文本是长字符串不可能每次查询都全库扫描于是就有了倒排索引——把文档拆成一个个词再记录每个词出现在哪些文档里。查询“人工智能 搜索引擎”时系统只需要分别找到两个词对应的文档列表求交集就能锁定候选集。这个设计听起来简单但真正落地时要处理的问题很多索引怎么压缩才能塞进内存、词表和文档编号怎么分配才能快速合并、磁盘索引和内存索引怎么分层、更新频率如何控制。可以说整个搜索引擎的响应速度绝大部分取决于索引层的工程水平。说到中文这里有个英文搜索不用头疼的问题分词。英文单词天然有空格分隔中文是连续汉字串“机器学习算法”可以切分成“机器/学习/算法”也可能切错成“机器/学习/算法”的另一种组合切分错误会直接影响召回准确度。所以中文搜索引擎从第一天起就必须做词法分析这也倒逼早期团队在自然语言处理上投入大量精力。到今天分词已经不单纯是“查词典”了新词发现、领域词典、统计模型都参与进来但本质上还是在解决同一个问题让计算机知道一句中文哪里是词的边界。1.2 排序算法的进化从词频统计到链接权重结果集有了接下来的核心问题是这么多网页都包含关键词谁排前面最早的做法很简单词频高、位置靠前就排前面。但很快就发现这有个致命弱点太容易被作弊了只要在页面里堆满关键词排名就会往上蹿。那个年代你甚至能看到网页底部密密麻麻的小字关键词就是为了“骗”过排序系统。这种思路本质上是在用“文档自身信息”做排序只要内容和自己相关不用看外部环境所以只要操纵页面内容就能操纵排名。于是基于链接关系的排序思想出现了一个网页被越多重要网页链接它的重要性就越高。这是搜索引擎历史上很重要的一个思路它把互联网当成一个“引文网络”来处理类似于学术论文引用。一个网页如果被很多高质量页面引用它本身就更可能是高质量的。这个思路后来被中文搜索引擎采用并且做了一系列改进加入时间因子让新内容有机会浮上来引入站点权重让权威站点的内页更容易获得信任再把用户点击行为反馈融入排序用户点了哪个结果、停留多久、是否马上返回都会影响这个结果后续的排名。这段进化给做产品的人一个启发靠“自说自话”做出来的质量判断总是脆弱的真正稳定的判断依据藏在关系里、行为里而不在内容表面。1.3 亲手验证的路径搭一个迷你搜索你会踩到哪些坑说了这么多原理如果你真想理解搜索引擎我建议自己动手搭一个迷你版。不用做得多完善三千行左右的代码就能让你把整条链路跑通。你一定会在实操中遇到这些事爬虫跑了不到十分钟就被对方服务器返回403你要学会设置合理的User-Agent和抓取间隔。抓回来的网页里全是HTML标签去标签、转码、去停用词之后真正能用的文本少得可怜。建立倒排索引的时候你会发现内存根本不够用必须做归并排序把索引写进磁盘。排序模型调来调去最后发现你得先处理垃圾内容不然后面的算法都是白搭。这个过程做一遍你会发现搜索技术并不是什么神秘黑盒它是一套非常朴素的工程系统。理解了这套系统你再看今天的大模型搜索、智能体搜索就能清楚它们到底改变了哪一层、没有改变哪一层。2. 内容生态决策搜索公司为什么要下场“做内容”2.1 搜索的“供给侧困境”搜索引擎本质上是一个连接用户需求和内容供给的中介。但做中介最怕的是什么供给端不在自己手里。在早期搜索结果指向的是门户新闻、论坛帖子和个人网站。质量参差不齐不说最大的问题是很多长尾搜索词根本没有内容可以匹配。你搜一个很冷门的问题可能什么都找不到用户带着疑问来带着失望走。这种体验对整个搜索引擎的口碑是一种慢性伤害因为搜索引擎的“答案质量”不只取决于排序算法还取决于你有没有足够多、足够新、足够优质的内容可以去排。这里有一个很有意思的行业细节搜索团队经常会在后台看到大量搜索词指向“零结果页面”。用户明明在找某个东西但全网就是没有对应内容。这些零结果搜索词就是最真实的需求信号。与其等着内容生产者慢慢生长出来不如自己下场把内容供给补上。这和今天很多平台自己投资做自制内容、自制剧是一个道理光做渠道不够关键位置上的供给必须自己掌控。2.2 贴吧、知道、百科的分工在内容生态的布局上当时围绕搜索框构建了一整套自有内容产品分别是贴吧、知道、百科。这三样东西表面看都是“社区”但仔细看会发现它们各自解决完全不同的需求贴吧解决的是“兴趣聚合”。它的产品形态是“按关键词建吧”用户可以直接为一个兴趣、一个话题、甚至一个模因建立讨论区。贴吧的产品逻辑对搜索引擎非常友好因为“吧”天然就用搜索词命名用户搜一个词搜出来的不只是一个网页而是一个持续有人活跃的社区。兴趣类需求的用户粘性非常高这也让贴吧成了很多小众爱好的聚集地。知道解决的是“个性化提问”。它的价值在于覆盖了搜索结果里没有现成答案的长尾需求。百科解决不了的问题、贴吧没人讨论过的问题用户都可以直接在知道上提问等回答。问答产品看起来简单但它是搜索生态里很重要的补充因为它把“没有答案”变成了“有答案的可能”。百科解决的是“权威知识入门”。它的定位是给常见概念提供一个相对可靠的基础解释。百科类产品最大的特点是结构化每个词条都按照定义、历史、分类、争议等章节来组织这种结构恰好是搜索引擎最乐意展示的内容因为它能让用户快速判断这个页面是否匹配自己的需求。2.3 冷启动与运营细节内容产品从0到1是出了名的难尤其是知识社区这类UGC产品。这三类产品当时能跑通关键不是“搞个产品挂上去”就完事而是靠一套非常重的冷启动运营打法。百科类产品冷启动阶段要像编辑词典一样先把最常用的几千个概念词条打底做出来保证用户随便搜一个常见词都能看到像样的词条。这些词条一开始不是用户写的是早期团队或核心志愿者一条条创建的。打底完成后再开放编辑权限让大众参与同时安排审核机制防止明显错误信息扩散。没有这层“打底”直接开放编辑大概率换来的是空词条和一堆低质内容。问答类产品更依赖“答主”供给。早期的冷启动几乎都是运营自己提问、自己回答把整个搜索路径跑通让用户感觉“这地方真的有人回答问题”再逐步引入真正的用户问答。这个过程看起来很笨但非常关键一个空荡荡的社区是留不住任何用户的。后来问答类产品普遍采用“邀请回答”“大V激励”等方式本质上都是在解决同一个冷启动难题先让内容密度达到用户愿意停留的阈值。从产品决策角度看当时做这些内容产品不是拍脑袋砸钱而是从搜索数据里看到了需求空缺。大量搜索词都指向空结果页这些词就是最直接的产品方向。用数据驱动内容建设这件事放到今天依然是内容平台冷启动的最有效路径。3. 商业系统暗线竞价广告背后的排序与定价逻辑3.1 搜索广告是“意图生意”搜索引擎的商业化是整个行业发展史上避不开的话题。搜索广告和展示广告最大的不同在于用户是带着意图来的。用户搜“装修”当然比一篇文章里夹带的装修banner更有商业价值。所以搜索广告本质上是“意图生意”。理解这种商业模式要先看用户心理。搜索用户和刷信息流的用户处在完全不同的心态里搜索是主动表达需求信息流是被动接收内容。主动表达的意图有多值钱一个用户在搜索框里输入“北京市海淀区装修公司哪家好”这条query背后是一个明确消费意愿、有预算、有地理范围的需求。广告系统如果能精准匹配这样的需求转化率会远高于普通展示广告。但意图也分强弱。品牌词搜“某品牌官网”的意图很明确就是找某个具体对象通用词搜“装修公司”的意图比较宽用户还在比较选项长尾疑问词搜“装修预算怎么定”的意图更强且更接近决策前夜。搜索广告系统要做的就是把不同强弱的高业价值查询词和合适的广告主匹配起来。3.2 排序公式与计费机制搜索竞价广告的排序公式并不是简单的谁出价高谁排前面。如果只看价格广告主可以通过无限抬价霸占位置但广告质量差点击少平台营收也上不来。所以主流的搜索广告排序采用“出价 × 预估点击率 × 质量分”综合打分的方式。拆开来看这三部分出价代表广告主愿意支付的最高价格预估点击率是由历史点击数据训练模型预测出来的反映用户点击这条广告的可能性质量分衡量广告与搜索词的相关性以及落地页体验。三者的乘积决定广告的排序位置。这个公式的巧妙之处在于它把“用户反馈”也放进了排序因子。一个广告即使出价很高如果用户就是不点位置也会往下掉这就倒逼广告主认真优化创意和落地页而不是只靠砸钱。广告点击背后的计费逻辑也很关键。搜索广告大多采用“广义第二高价”机制意思是广告实际付出的价格不是自己的出价而是刚好赢过下一位所需的价格加一点点。举一个具体例子假设你出价10元排序在你下一位的广告主出价8元你实际只需要付8元多一点。这个机制的聪明处在于广告主不用反复调低出价去试探底线平台也能避免出价虚高导致的恶性抬价。如果你在投放后台看到一个词点击成本比自己出价低一截不要意外很可能就是因为有你下一位的对手在“兜底”。3.3 广告与自然结果的边界问题写这一段可能会有人问搜索引擎靠广告赚钱会不会伤害用户体验这个问题其实从一开始就存在。任何搜索引擎在商业化时都面临同一个课题广告与自然结果的边界在哪里、用户如何分得清哪些是广告、广告相关度不足时要不要强行展示。我的看法是这个矛盾永远不会消失但技术可以在两者之间找平衡。主流的做法包括用历史数据回归决策广告位的数量和位置不同词性的查询展示不同密度的广告广告与查询相关性低于阈值时直接不展示宁缺毋滥广告区域必须有明确的视觉区隔用户能一眼识别。这些决策都可以被量化测试AB实验是基本手段判断标准就看长线用户留存和广告主ROI是不是双增。还要补充一点搜索广告的意图理解也在持续进化。移动时代后用户可能在搜索框里输入品牌词、比较词、售后词广告系统开始按意图分类来分配预算。比如“哪个牌子好”是比较意图适合展示多个品牌的对比广告“怎么退货”是售后意图更适合展示官方客服入口而不是销售广告。意图识别越精准广告系统才能既保证收入用户体验又不至于恶化。4. 移动时代重构从“人找信息”到“信息找人”4.1 搜索入口被拆解的原因PC时代搜索是网民进入互联网的“第一站”无论你想干什么第一步都是先打开搜索框。这种入口级地位让搜索引擎在整个PC互联网时代拥有非常强的内容分发权力。但移动互联网把这一切拆掉了。手机桌面上的App们接管了用户的信息消费入口。聊天、短视频、新闻资讯、电商每个超级App都在自己的围墙里提供搜索或者干脆用推荐流替代搜索。用户的搜索行为开始分化想买东西直接去电商平台搜想刷内容直接打开短视频App想问问题直接在社区里发帖。这些平台内部都有自己的搜索结果用户对“全网搜索”这个概念的依赖度自然就降下来了。这里有一个结构性原因PC时代的信息是开放的网页搜索引擎可以去爬移动时代的内容都封在App的服务端里对外不开放接口。搜索引擎默认变成了“爬不到内容的空壳”能搜到的只有那些还在坚持做PC页面的站点。一边是用户不来了一边是内容也爬不到了这种双削弱才是搜索公司必须转型的根本原因。4.2 信息流推荐系统的核心组件面对移动端流量被分流的现实搜索公司必须回答一个问题用户不来搜索框找信息你怎么把信息送到用户面前答案是信息流推荐。传统搜索是“人找信息”用户输入词、系统给结果信息流是“信息找人”系统根据用户画像和兴趣模型在用户刷手机的碎片时间里不断推荐内容。这个逻辑逆转本质上是从被动响应query到主动预测兴趣的转变。做推荐的难度不比搜索低甚至更难因为搜索有明确的query做约束推荐完全没有。推荐系统的基础设施可以拆成几块内容理解负责给每篇文章、每条视频打标签建立类目、实体、话题、风格等多个维度的结构化描述用户画像是通过点击、时长、点赞、评论等行为构建兴趣向量回答“这个用户是什么样的人”的问题召回与排序是先用各种策略从海量内容中召回候选集再用模型精准打分排序还有探索与利用机制既要推荐用户已经表现出兴趣的内容也要留一部分流量推荐新品种否则用户兴趣圈会越缩越窄。这套体系做下来信息流平台的用户时长和广告库存都被大大充实了。从商业上讲推荐流消化内容的速度极快广告插入的场景极为丰富这是搜索框做不到的。所以“搜索信息流”双引擎的模式本质上是用推荐来填补搜索之外的用户时长空白把“用完即走”变成“没事也来刷刷”。4.3 小程序与内容围墙新的生态博弈移动时代还有一个棘手的问题大量内容被封存在超级App里搜索引擎爬不到。为了突围搜索公司做了类似小程序、托管页这样的解决方案把开发者和内容提供者接入自己的生态让内容可以在搜索结果里内嵌呈现。这个思路本质上是“用流量换内容”你接入我的生态我给你全链路流量和完整用户服务但你的内容不再提供给外部搜索引擎。这形成了今天很多内容平台都面临的“围墙花园”问题互联网从一个开放互连的网络慢慢退化成若干个封闭群岛。每个岛上都有人、有内容、有交易闭环但岛与岛之间不互通。开发者为什么愿意入驻因为在围墙内能直接触达大量用户省去了独立推广的成本。对用户来说好处是搜索结果可以直接完成服务坏处是信息选择面被平台圈住了你看到的只是平台愿意让你看到的内容。这个生态博弈到今天还在继续。这提醒我们搜索引擎的本质价值从来不只是技术而是它对开放互联网内容的索引能力。一旦内容供给从开放走向封闭搜索引擎的价值就要打折扣。移动时代的这场较量本质上是“开放索引”和“封闭生态”两种信息分发哲学之间的较量。5. AI重写搜索大模型时代的底层逻辑与产品形态5.1 搜索公司做AI的三重优势人工智能并不是搜索公司的新跨界而是老本行。搜索从第一天起就在做自然语言理解、语义匹配、用户意图预测这些本质上都是AI问题。大模型的出现更是给搜索公司提供了一条比传统检索式系统更顺畅的路径。从算力、数据、场景三个维度看搜索公司和大模型高度匹配。数据方面多年海量查询日志和点击行为是训练语言模型理解“用户在问什么”的天然语料。用户怎么组织问题、什么问题搜不到、点了哪些结果、结果满不满意这些信息对训练对话模型尤其有价值。算力方面大规模搜索引擎本身就需要庞大的分布式计算集群相比从零开始攒算力的团队搜索公司的集群规模和调度经验是现成的。场景方面用户每天产生大量新问题搜索结果可以被实时点击反馈验证模型好不好用立刻就知道。这三点放在一起结论很清楚搜索公司做AI模型训练数据和产品反馈之间能形成闭环。这个闭环是很多纯算法团队很难复制的。5.2 RAG让模型“先查再答”的工程架构生成式AI搜索和经典检索式搜索不是互相替代而是可以融合成一条新管线。现在大家常说的检索增强生成RAG简单说就是用户提问后系统先通过传统搜索引擎召回一批相关资料再把资料和问题一起交给大模型生成答案。相比直接让大模型凭记忆回答RAG有明显的工程优势。第一知识更前沿模型训练数据有截止日期但检索到的网页内容是实时的新发布的事件、新出的政策、刚上市的产品都能覆盖。第二减少幻觉回答有了资料作为依据模型只能基于给它的材料推理胡说八道的概率大大降低。第三可追踪可信赖答案可以附上引用来源用户能自己点开核对这在医疗、金融、法律等信息敏感性高的场景里尤其重要。这也是为什么很多新一代搜索产品都采用“先检索、后生成”的架构。它既保留了大模型强大的自然语言理解和生成能力又保留了检索系统的实时性和可验证性。你甚至可以这样理解大模型负责“组织语言、串联逻辑”检索系统负责“找材料、给论据”两者配合比任何一个单独上场都可靠。工程上RAG里的检索部分可以直接复用成熟的索引和召回系统这让传统搜索团队的技术积累并没有白费。5.3 智能体搜索从工具变成执行层大模型改变的不仅是搜索结果还改变了搜索这个交互接口。过去任何问题都只能用“关键词点击”来完成寻找现在用户可以直接用一句自然语言描述需求系统通过多轮对话追问细节再调动多个工具完成任务。这种形态行业里习惯称为智能体。它能订票、能比较商品、能规划行程搜索将不再只是一个信息查询工具而是变成“帮你完成任务”的执行层。从技术链路看一个完整的智能体需要四步意图理解搞清楚用户真正想要什么任务规划把大目标拆成子任务工具调用对接外部系统和数据源结果验证检查输出是不是真的解决了问题。每一步都依赖大模型的推理能力也需要传统系统的计算结果来兜底。搜索公司做智能体有一个天然的场景优势。用户来搜索就是带着任务来的他天然愿意接受一个能帮他做完事的产品。做出来之后用户每一次提问、每一次工具的调用、每一个结果的反馈又都会成为模型迭代的数据。我还是想说那句话互联网公司做AI最稀缺的不是模型本身而是场景和数据闭环。搜索场景的数据是大量持续产生的模型可以不断从用户反馈里学习什么样的答案更让人满意这几乎是天然的训练场。6. 从这段发展史里沉淀下来的几点经验6.1 生态护城河的优先级这段发展史里有一个反复出现的模式单纯的技术优势带来的领先往往需要靠生态布局来固化。搜索算法可以抄袭、可以追赶但多年积累的内容资产和用户社区很难在一夜之间复制。这也解释了为什么很多技术公司在站稳一个赛道后会疯狂做周边产品核心逻辑不是多元化而是用生态给技术盖一层护城河。同理大模型时代模型参数可能会很快被追平但围绕搜索场景积累下来的用户习惯、内容生态、反馈数据是后来者很难短期复制的。6.2 用户要的是“答案”而不是“搜索框”站在今天回看用户并不在乎背后是搜索框还是对话框他们在乎的是问题有没有被解决、答案是不是准确。这也是为什么信息流、推荐、大模型生成的演化方向都不是“让搜索框更好用”而是“绕过搜索框直接给答案”。做产品的人如果能意识到这一点很多战略上的纠结会少很多。不要在形式上死守一个UI形态要盯着用户本质诉求去演化交互方式搜索如此很多互联网产品也是如此。6.3 数据闭环是AI时代产品竞争的真壁垒我自己做产品这几年越来越觉得大模型本身会逐步变成公共基础设施真正的差别在于谁能把场景和数据闭环跑得更快。搜索场景天然具备这种闭环用户提问、系统回答、用户反馈、模型迭代。这个循环跑得越久系统对真实需求的理解就越深产品就越难被替代。所以很多AI产品经理之间经常互相提醒不要和对手比参数大小要比谁更快构建场景、更快跑通数据反馈闭环。算法可以追赶数据飞轮转起来之后很难被打破。6.4 最后的个人体会回看这段“发展史”我最大的感受是技术浪潮会一浪接一浪地更替但“高效准确地匹配信息和需求”这个本质需求从来不会变。谁能用更自然的方式更精准地满足它谁就能在新时代重新建立自己的入口。搜索是如此推荐是如此AI对话也是如此。对做产品、做技术的同行来说与其焦虑下一个风口在哪里不如持续追问在当前的技术条件下用户获得答案的路径还能不能更短一点、更准一点、更顺一点。这件事想透了方向就不会跑偏。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
