转：Lucene的特性分析

2007/6/2镜像同步8 回复

3.1. Lucene核心部分——索引排序 Lucene 的索引排序是使用了倒排序原理。该结构及相应的生成算法如下：设有两篇文章1和2 文章1的内容为：Tom lives in Guangzhou,I live in Guangzhou too. 文章2的内容为：He once lived in Shanghai. 1. 由于lucene是基于关键词索引和查询的，首先我们要取得这两篇文章的关键词，通常我们需要如下处理措施 a. 我们现在有的是文章内容，即一个字符串，我们先要找出字符串中的所有单词，即分词。英文单词由于用空格分隔，比较好处理。中文单词间是连在一起的需要特殊的分词处理。 b. 文章中的”in”, “once” “too”等词没有什么实际意义，中文中的“的”“是”等字通常也无具体含义，这些不代表概念的词可以过滤掉，这个也就是在《Lucene详细分析》中所讲的StopTokens c. 用户通常希望查“He”时能把含“he”，“HE”的文章也找出来，所以所有单词需要统一大小写。 d. 用户通常希望查“live”时能把含“lives”，“lived”的文章也找出来，所以需要把“lives”，“lived”还原成“live” e. 文章中的标点符号通常不表示某种概念，也可以过滤掉,在lucene中以上措施由Analyzer类完成,经过上面处理后: 文章1的所有关键词为：[tom] [live] [guangzhou] [live] [guangzhou] 文章2的所有关键词为：[he] [live] [shanghai] 2. 有了关键词后，我们就可以建立倒排索引了上面的对应关系是：“文章号”对“文章中所有关键词”。倒排索引把这个关系倒过来，变成：“关键词”对“拥有该关键词的所有文章号”。文章1，2经过倒排后变成  关键词文章号 guangzhou 1 he 2 i 1 live 1,2 shanghai 2 tom 1 通常仅知道关键词在哪些文章中出现还不够，我们还需要知道关键词在文章中出现次数和出现的位置，通常有两种位置：a)字符位置，即记录该词是文章中第几个字符（优点是关键词亮显时定位快）；b)关键词位置，即记录该词是文章中第几个关键词（优点是节约索引空间、词组（phase）查询快），lucene中记录的就是这种位置。加上“出现频率”和“出现位置”信息后，我们的索引结构变为：关键词文章号[出现频率] 出现位置 guangzhou 1[2] 3，6 he 2[1] 1 i 1[1] 4 live 1[2],2[1] 2，5，2 shanghai 2[1] 3 tom 1[1] 1 以live 这行为例我们说明一下该结构：live在文章1中出现了2次，文章2中出现了一次，它的出现位置为“2,5,2”这表示什么呢？我们需要结合文章号和出现频率来分析，文章1中出现了2次，那么“2,5”就表示live在文章1中出现的两个位置，文章2中出现了一次，剩下的“2”就表示live是文章2中第 2个关键字。以上就是lucene索引结构中最核心的部分。我们注意到关键字是按字符顺序排列的（lucene没有使用B树结构），因此lucene可以用二元搜索算法快速定位关键词。实现时 lucene将上面三列分别作为词典文件（Term Dictionary）、频率文件(frequencies)、位置文件 (positions)保存。其中词典文件不仅保存有每个关键词，还保留了指向频率文件和位置文件的指针，通过指针可以找到该关键字的频率信息和位置信息。 Lucene中使用了field的概念，用于表达信息所在位置（如标题中，文章中，url中），在建索引中，该field信息也记录在词典文件中，每个关键词都有一个field信息(因为每个关键字一定属于一个或多个field)。为了减小索引文件的大小，Lucene对索引还使用了压缩技术。首先，对词典文件中的关键词进行了压缩，关键词压缩为<前缀长度，后缀>，例如：当前词为“阿拉伯语”，上一个词为“阿拉伯”，那么“阿拉伯语”压缩为<3，语>。其次大量用到的是对数字的压缩，数字只保存与上一个值的差值（这样可以减小数字的长度，进而减少保存该数字需要的字节数）。例如当前文章号是16389（不压缩要用3个字节保存），上一文章号是16382，压缩后保存7（只用一个字节）。下面我们可以通过对该索引的查询来解释一下为什么要建立索引。假设要查询单词 “live”，lucene先对词典二元查找、找到该词，通过指向频率文件的指针读出所有文章号，然后返回结果。词典通常非常小，因而，整个过程的时间是毫秒级的。而用普通的顺序匹配算法，不建索引，而是对所有文章的内容进行字符串匹配，这个过程将会相当缓慢，当文章数目很大时，时间往往是无法忍受的。 3.2. Lucene的相关度积分公式 score_d = sum_t(tf_q * idf_t / norm_q * tf_d * idf_t / norm_d_t * boost_t) * coord_q_d 注解： score_d : 该文档d的得分 sum_t : 所有项得分的总和 tf_q : 查询串q中，某个项出项的次数的平方根 tf_d : 文档d中，出现某个项的次数的平方根 numDocs : 在这个索引里，找到分数大于0的文档的总数 docFreq_t : 包含项t的文档总数 idf_t : log(numDocs/docFreq+1)+1.0 norm_q : sqrt(sum_t((tf_q*idf_t)^2)) norm_d_t : 在文档d中，与项t相同的域中，所有的项总数的平方根 boost_t : 项t的提升因子，一般为 1.0 coord_q_d : 在文档d中，命中的项数量除以查询q的项总数 3.3. Lucene的其他特性 3.3.1. Boosting特性 luncene对Document和Field提供了一个可以设置的Boosting参数，这个参数的用处是告诉lucene，某些记录更重要，在搜索的时候优先考虑他们比如在搜索的时候你可能觉得几个门户的网页要比垃圾小站更优先考虑 lucene默认的boosting参数是1.0, 如果你觉得这个field重要,你可以把boosting设置为1.5, 1.2....等, 对Document设置boosting相当设定了它的每个Field的基准boosting，到时候实际Field的boosting就是(Document-boosting*Field-boosting)设置了一遍相同的boosting. 似乎在lucene的记分公式里面有boosting参数,不过我估计一般人是不会去研究他的公式的（复杂）,而且公式也无法给出最佳值，所以我们所能做的只能是一点一点的改变boosting, 然后在实际检测中观察它对搜索结果起到多大的作用来调整一般的情况下是没有必要使用boosting的, 因为搞不好你就把搜索给搞乱了, 另外如果是单独对Field来做Bossting, 也可以通过将这个Field提前来起到近似的效果 3.3.2. Indexing Date 日期是lucene需要特殊考虑的地方之一, 因为我们可能需要对日期进行范围搜索, Field.keyword(string,Date)提供了这样的方法,lucene会把这个日期转换为string, 值得注意的是这里的日期是精确到毫秒的,可能会有不必要的性能损失, 所以我们也可以把日期自行转化为YYYYMMDD这样的形势,就不用精确到具体时间了,通过File.keyword(Stirng,String) 来index, 使用PrefixQuery 的YYYY一样能起到简化版的日期范围搜索(小技巧), lucene提到他不能处理1970年以前的时间,似乎是上一代电脑系统遗留下来的毛病 3.3.3. Indexing 数字如果数字只是简单的数据, 比如中国有56个民族. 那么可以简单的把它当字符处理如果数字还包含数值的意义,比如价格, 我们会有范围搜索的需要(20元到30元之间的商品),那么我们必须做点小技巧, 比如把3,34,100 这三个数字转化为003,034,100 ,因为这样处理以后, 按照字符排序和按照数值排序是一样的,而lucene内部按照字符排序,003->034->100 NOT(100->3->34) 3.3.4. 排序 Lucene默认按照相关度(score)排序,为了能支持其他的排序方式,比如日期,我们在add Field的时候,必须保证field被Index且不能被tokenized(分词),并且排序的只能是数字,日期,字符三种类型之一 3.3.5. Lucene的IndexWriter调整 IndexWriter提供了一些参数可供设置，列表如下属性默认值说明 mergeFactor org.apache.lucene.mergeFactor 10 控制index的大小和频率,两个作用 maxMergeDocs org.apache.lucene.maxMergeDocs Integer.MAX_VALUE 限制一个段中的document数目 minMergeDocs org.apache.lucene.minMergeDocs 10 缓存在内存中的document数目，超过他以后会写入到磁盘 maxFieldLength 1000 一个Field中最大Term数目，超过部分忽略，不会index到field中，所以自然也就搜索不到这些参数的的详细说明比较复杂：mergeFactor有双重作用设置每mergeFactor个document写入一个段，比如每10个document写入一个段设置每mergeFacotr个小段合并到一个大段，比如10个document的时候合并为1小段，以后有10个小段以后合并到一个大段，有10个大段以后再合并，实际的document数目会是mergeFactor的指数简单的来说mergeFactor 越大，系统会用更多的内存，更少磁盘处理，如果要打批量的作index，那么把mergeFactor设置大没错， mergeFactor 小了以后， index数目也会增多，searhing的效率会降低，但是mergeFactor增大一点一点，内存消耗会增大很多(指数关系),所以要留意不要"out of memory" 把maxMergeDocs设置小，可以强制让达到一定数量的document写为一个段，这样可以抵消部分mergeFactor的作用. minMergeDocs相当于设置一个小的cache,第一个这个数目的document会留在内存里面，不写入磁盘。这些参数同样是没有最佳值的，必须根据实际情况一点点调整。 maxFieldLength可以在任何时刻设置，设置后，接下来的index的Field会按照新的length截取，之前已经index的部分不会改变。可以设置为Integer.MAX_VALUE 3.3.6. RAMDirectory 和 FSDirectory 转化 RAMDirectory(RAMD)在效率上比FSDirectyr(FSD)高不少, 所以我们可以手动的把RAMD当作FSD的buffer,这样就不用去很费劲的调优FSD那么多参数了,完全可以先用RAM跑好了index，周期性（或者是别的什么算法）来回写道FSD中。 RAMD完全可以做FSD的buffer。 3.3.7. 为查询优化索引(index) Indexwriter.optimize()方法可以为查询优化索引（index），之前提到的参数调优是为indexing过程本身优化，而这里是为查询优化，优化主要是减少index文件数，这样让查询的时候少打开文件，优化过程中，lucene会拷贝旧的index再合并，合并完成以后删除旧的index，所以在此期间，磁盘占用增加， IO符合也会增加，在优化完成瞬间，磁盘占用会是优化前的2倍,在optimize过程中可以同时作search。 3.3.8. 并发操作Lucene和locking机制 v 所有只读操作都可以并发 v 在index被修改期间，所有只读操作都可以并发 v 对index修改操作不能并发，一个index只能被一个线程占用 v index的优化，合并，添加都是修改操作 v IndexWriter和IndexReader的实例可以被多线程共享，他们内部是实现了同步，所以外面使用不需要同步 3.3.9. Locing lucence内部使用文件来locking，默认的locking文件放在java.io.tmpdir,可以通过-Dorg.apache.lucene.lockDir=xxx指定新的dir，有write.lock commit.lock两个文件，lock文件用来防止并行操作index，如果并行操作， lucene会抛出异常，可以通过设置-DdisableLuceneLocks=true来禁止locking，这样做一般来说很危险，除非你有操作系统或者物理级别的只读保证，比如把index文件刻盘到CDROM上。 4. Lucene文档结构 Lucene中最基础的概念是索引（index），文档（document．，域（field）和项（term）。索引包含了一个文档的序列。 · 文档是一些域的序列。 · 域是一些项的序列。 · 项就是一个字串。存在于不同域中的同一个字串被认为是不同的项。因此项实际是用一对字串表示的，第一个字串是域名，第二个是域中的字串。 4.1. Lucene概念详细介绍 4.1.1. 域的类型 Lucene中，域的文本可能以逐字的非倒排的方式存储在索引中。而倒排过的域称为被索引过了。域也可能同时被存储和被索引。域的文本可能被分解许多项目而被索引，或者就被用作一个项目而被索引。大多数的域是被分解过的，但是有些时候某些标识符域被当做一个项目索引是很有用的。 4.1.2. 段（Segment） Lucene索引可能由多个子索引组成，这些子索引成为段。每一段都是完整独立的索引，能被搜索。索引是这样作成的： 1. 为新加入的文档创建新段。 2. 合并已经存在的段。搜索时需要涉及到多个段和/或者多个索引，每一个索引又可能由一些段组成。 4.1.3. 文档号（document．nbspNumber）内部的来说，Lucene用一个整形（interger）的文档号来指示文档。第一个被加入到索引中的文档就是0号，顺序加入的文档将得到一个由前一个号码递增而来的号码。注意文档号是可能改变的，所以在Lucene外部存储这些号码时必须小心。特别的，号码的改变的情况如下： · 只有段内的号码是相同的，不同段之间不同，因而在一个比段广泛的上下文环境中使用这些号码时，就必须改变它们。标准的技术是根据每一段号码多少为每一段分配一个段号。将段内文档号转换到段外时，加上段号。将某段外的文档号转换到段内时，根据每段中可能的转换后号码范围来判断文档属于那一段，并减调这一段的段号。例如有两个含5个文档的段合并，那么第一段的段号就是0，第二段段号5。第二段中的第三个文档，在段外的号码就是8。 · 文档删除后，连续的号码就出现了间断。这可以通过合并索引来解决，段合并时删除的文档相应也删掉了，新合并而成的段并没有号码间断。 4.1.4. 索引信息索引段维护着以下的信息： · 域集合。包含了索引中用到的所有的域。 · 域值存储表。每一个文档都含有一个“属性－值”对的列表，属性即为域名。这个列表用来存储文档的一些附加信息，如标题，url或者访问数据库的一个ID。在搜索时存储域的集合可以被返回。这个表以文档号标识。 · 项字典。这个字典含有所有文档的所有域中使用过的的项，同时含有使用过它的文档的文档号，以及指向使用频数信息和位置信息的指针。 · 项频数信息。对于项字典中的每个项，这些信息包含含有这个项的文档的总数，以及每个文档中使用的次数。 · 项位置信息。对于项字典中的每个项，都存有在每个文档中出现的各个位置。 · 标准化因子。对于文档中的每一个域，存有一个值，用来以后乘以这个这个域的命中数（hits）。 · 被删除的文档信息。这是一个可选文件，用来表明那些文档已经删除了。接下来的各部分部分详细描述这些信息。 4.1.5. 文件的命名（File Naming）同属于一个段的文件拥有相同的文件名，不同的扩展名。扩展名由以下讨论的各种文件格式确定。一般来说，一个索引存放一个目录，其所有段都存放在这个目录里，不这样作，也是可以的，在性能方面较低。 4.2. Lucene基本数据类型（Primitive Types） 4.2.1. 字节Byte 最基本的数据类型就是字节（byte，8位）。文件就是按字节顺序访问的。其它的一些数据类型也定义为字节的序列，文件的格式具有字节意义上的独立性。 UInt32 ：32位无符号整数，由四个字节组成，高位优先。UInt32 --> <Byte>4 Uint64 ： 64位无符号整数，由八字节组成，高位优先。UInt64 --> <Byte>8 VInt ：可变长的正整数类型，每字节的最高位表明还剩多少字节。每字节的低七位表明整数的值。因此单字节的值从0到127，两字节值从128到16,383，等等。 VInt 编码示例 value First byte Second byte Third byte 0 00000000 1 00000001 2 00000010 ... 127 01111111 128 10000000 00000001 129 10000001 00000001 130 10000010 00000001 ... 16,383 11111111 01111111 16,384 10000000 10000000 00000001 16,385 10000001 10000000 00000001 ... 这种编码提供了一种在高效率解码时压缩数据的方法。 4.2.2. 字符串Chars Lucene输出UNICODE字符序列，使用标准UTF-8编码。 String ：Lucene输出由VINT和字符串组成的字串，VINT表示字串长，字符串紧接其后。 String --> VInt, Chars 4.3. 索引包含的文件（Per-Index Files） 4.3.1. Segments文件索引中活动的段存储在Segments文件中。每个索引只能含有一个这样的文件，名为"segments".这个文件依次列出每个段的名字和每个段的大小。 Segments --> SegCount, <SegName, SegSize>SegCount SegCount, SegSize --> UInt32 SegName --> String SegName表示该segment的名字，同时作为索引其他文件的前缀。 SegSize是段索引中含有的文档数。 4.3.2. Lock文件有一些文件用来表示另一个进程在使用索引。 · 如果存在"commit.lock"文件，表示有进程在写"segments"文件和删除无用的段索引文件，或者表示有进程在读"segments"文件和打开某些段的文件。在一个进程在读取"segments"文件段信息后，还没来得及打开所有该段的文件前，这个Lock文件可以防止另一个进程删除这些文件。 · 如果存在"index.lock"文件，表示有进程在向索引中加入文档，或者是从索引中删除文档。这个文件防止很多文件同时修改一个索引。 4.3.3. Deleteable文件名为"deletetable"的文件包含了索引不再使用的文件的名字，这些文件可能并没有被实际的删除。这种情况只存在与Win32平台下，因为Win32下文件仍打开时并不能删除。 Deleteable --> DelableCount, <DelableName>DelableCount DelableCount --> UInt32 DelableName --> String 4.3.4. 段包含的文件（Per-Segment Files）剩下的文件是每段中包含的文件，因此由后缀来区分。域（Field）域集合信息（Field Info）所有域名都存储在这个文件的域集合信息中，这个文件以后缀.fnm结尾。 FieldInfos (.fnm) --> FieldsCount, <FieldName, FieldBits>FieldsCount FieldsCount --> VInt FieldName --> String FieldBits --> Byte 目前情况下，FieldBits只有使用低位，对于已索引的域值为1，对未索引的域值为0。文件中的域根据它们的次序编号。因此域0是文件中的第一个域，域1是接下来的，等等。这个和文档号的编号方式相同。 4.3.5. 域值存储表（Stored Fields）域值存储表使用两个文件表示： 1. 域索引（.fdx文件）。如下，对于每个文档这个文件包含指向域值的指针： FieldIndex (.fdx) --> <FieldvaluesPosition>SegSize FieldvaluesPosition --> Uint64 FieldvaluesPosition指示的是某一文档的某域的域值在域值文件中的位置。因为域值文件含有定长的数据信息，因而很容易随机访问。在域值文件中，文档n的域值信息就存在n*8位置处（The position of document．nbspn's field data is the Uint64 at n*8 in this file.）。 2. 域值（.fdt文件）。如下，每个文档的域值信息包含： FieldData (.fdt) --> <DocFieldData>SegSize DocFieldData --> FieldCount, <FieldNum, Bits, value>FieldCount FieldCount --> VInt FieldNum --> VInt Bits --> Byte value --> String 目前情况下，Bits只有低位被使用，值为1表示域名被分解过，值为0表示未分解过。÷ 4.3.6. 项字典（Term Dictionary）项字典用以下两个文件表示： 1. 项信息（.tis文件）。 TermInfoFile (.tis)--> TermCount, TermInfos TermCount --> UInt32 TermInfos --> <TermInfo>TermCount TermInfo --> <Term, DocFreq, FreqDelta, ProxDelta> Term --> <PrefixLength, Suffix, FieldNum> Suffix --> String PrefixLength, DocFreq, FreqDelta, ProxDelta --> VInt 项信息按项排序。项信息排序时先按项所属的域的文字顺序排序，然后按照项的字串的文字顺序排序。项的字前缀往往是共同的，与字的后缀组成字。PrefixLength变量就是表示与前一项相同的前缀的字数。因此，如果前一个项的字是"bone"，后一个是"boy"的话，PrefixLength值为2，Suffix值为"y"。 FieldNum指明了项属于的域号，而域名存储在.fdt文件中。 DocFreg表示的是含有该项的文档的数量。 FreqDelta指明了项所属TermFreq变量在.frq文件中的位置。详细的说，就是指相对于前一个项的数据的位置偏移量（或者是0，表示文件中第一个项）。 ProxDelta指明了项所属的TermPosition变量在.prx文件中的位置。详细的说，就是指相对于前一个项的数据的位置偏移量（或者是0，表示文件中第一个项）。 2. 项信息索引（.tii文件）。每个项信息索引文件包含.tis文件中的128个条目，依照条目在.tis文件中的顺序。这样设计是为了一次将索引信息读入内存能，然后使用它来随机的访问.tis文件。这个文件的结构和.tis文件非常类似，只在每个条目记录上增加了一个变量IndexDelta。 TermInfoIndex (.tii)--> IndexTermCount, TermIndices IndexTermCount --> UInt32 TermIndices --> <TermInfo, IndexDelta>IndexTermCount IndexDelta --> VInt IndexDelta表示该项的TermInfo变量值在.tis文件中的位置。详细的讲，就是指相对于前一个条目的偏移量（或者是0，对于文件中第一个项）。 4.3.7. 项频数（Frequencies） .frq文件包含每一项的文档的列表，还有该项在对应文档中出现的频数。 FreqFile (.frq) --> <TermFreqs>TermCount TermFreqs --> <TermFreq>DocFreq TermFreq --> DocDelta, Freq? DocDelta,Freq --> VInt TermFreqs序列按照项来排序（依据于.tis文件中的项，即项是隐含存在的）。 TermFreq元组按照文档号升序排列。 DocDelta决定了文档号和频数。详细的说，DocDelta/2表示相对于前一文档号的偏移量（或者是0，表示这是TermFreqs里面的第一项）。当DocDelta是奇数时表示在该文档中频数为1，当DocDelta是偶数时，另一个VInt（Freq）就表示在该文档中出现的频数。例如，假设某一项在文档7中出现一次，在文档11中出现了3次，在TermFreqs中就存在如下的VInts序列： 15, 22, 3 4.3.8. 项位置（Position） .prx文件包含了某文档中某项出现的位置信息的列表。 ProxFile (.prx) --> <TermPositions>TermCount TermPositions --> <Positions>DocFreq Positions --> <PositionDelta>Freq PositionDelta --> VInt TermPositions按照项来排序（依据于.tis文件中的项，即项是隐含存在的）。 Positions元组按照文档号升序排列。 PositionDelta是相对于前一个出现位置的偏移位置（或者为0，表示这是第一次在这个文档中出现）。例如，假设某一项在某文档第4项出现，在另一个文档中第5项和第9项出现，将存在如下的VInt序列： 4, 5, 4 4.3.9. 标准化因子（Normalization Factor） .nrm文件包含了每个文档的标准化因子，标准化因子用来以后乘以这个这个域的命中数。 Norms (.nrm) --> <Byte>SegSize 每个字节记录一个浮点数。位0-2包含了3位的尾数部分，位3-8包含了5位的指数部分。按如下规则可将这些字节转换为IEEE标准单精度浮点数： 1. 如果该字节是0，就是浮点0； 2. 否则，设置新浮点数的标志位为0； 3. 将字节中的指数加上48后作为新的浮点数的指数； 4. 将字节中的尾数映射到新浮点数尾数的高3位；并且 5. 设置新浮点数尾数的低21位为0。 4.3.10. 被删除的文档（Deleted document） .del文件是可选的，只有在某段中存在删除操作后才存在： Deletions (.del) --> ByteCount,BitCount,Bits ByteSize,BitCount --> Uint32 Bits --> <Byte>ByteCount ByteCount表示的是Bits列表中Byte的数量。典型的，它等于（SegSize/8）+1。 BitCount表示Bits列表中多少个已经被设置过了。 Bits列表包含了一些位（bit），顺序表示一个文档。当对应于文档号的位被设置了，就标志着这个文档已经被删除了。位的顺序是从低到高。因此，如果Bits包含两个字节，0x00和0x02，那么表示文档9已经删除了。 4.3.11. 局限性（Limitations）在以上的文件格式中，好几处都有限制项和文档的最大个数为32位数的极限，即接近于40亿。今天看来，这不会造成问题，但是，长远的看，可能造成问题。因此，这些极限应该或者换为UInt64类型的值，或者更好的，换为VInt类型的值（VInt值没有上限）。有两处地方的代码要求必须是定长的值，他们是： 1. FieldvaluesPosition变量（存储于域索引文件中，.fdx文件）。它已经是一个UInt64型，所以不会有问题。 2. TermCount变量（存储于项信息文件中，.tis文件）。这是最后输出到文件中的，但是最先被读取，因此是存储于文件的最前端。索引代码先在这里写入一个0值，然后在其他文件输出完毕后覆盖这个值。所以无论它存储在什么地方，它都必须是一个定长的值，它应该被变成UInt64型。除此之外，所有的UInt值都可以换成VInt型以去掉限制。

订阅后，新回复会通过你的通知中心匿名送达。

8 条回复

dido机器人#1 · 2007/6/2

什么是垂直搜索？[原创] http://FullSearch.Com 中文全文检索网 2006-1-3 14:14:31 sigz 关键词：垂直搜索引擎垂直搜索垂直搜索是针对某一个行业的专业搜索引擎，是搜索引擎的细分和延伸，是对网页库中的某类专门的信息进行一次整合，定向分字段抽取出需要的数据进行处理后再以某种形式返回给用户。垂直搜索引擎和普通的网页搜索引擎的最大区别是对网页信息进行了结构化信息抽取，也就是将网页的非结构化数据抽取成特定的结构化信息数据，好比网页搜索是以网页为最小单位，基于视觉的网页块分析是以网页块为最小单位，而垂直搜索是以结构化数据为最小单位。然后将这些数据存储到数据库，进行进一步的加工处理，如：去重、分类等，最后分词、索引再以搜索的方式满足用户的需求。整个过程中，数据由非结构化数据抽取成结构化数据，经过深度加工处理后以非结构化的方式和结构化的方式返回给用户。垂直搜索引擎的应用方向很多，比如企业库搜索、供求信息搜索引擎、购物搜索、房产搜索、人才搜索、地图搜索、mp3搜索、图片搜索……几乎各行各业各类信息都可以进一步细化成各类的垂直搜索引擎。举个例子来说明会更容易理解，比如购物搜索引擎，整体流程大致如下：抓取网页后，对网页商品信息进行抽取，抽取出商品名称、价格、简介……甚至可以进一步将笔记本简介细分成“品牌、型号、CPU、内存、硬盘、显示屏、……”然后对信息进行清洗、去重、分类、分析比较、数据挖掘，最后通过分词索引提供用户搜索、通过分析挖掘提供市场行情报告。垂直搜索引擎大体上需要以下技术１．Spider ２．网页结构化信息抽取技术或元数据采集技术３．分词、索引４．其他信息处理技术垂直搜索引擎的技术评估应从以下几点来判断１．全面性２．更新性３．准确性４．功能性垂直搜索的进入门槛很低，但是竞争的门槛很高。没有专注的精神和精湛的技术是不行的。行业门户网站具备行业优势但他们又是没有技术优势的，绝对不要想像着招几个人就可以搞定垂直搜索的全部技术，作为一个需要持续改进可运营的产品而不是一个项目来说对技术的把握控制程度又是垂直搜索成功的重要因素之一。相关文章：如何做好一个垂直搜索引擎[原创] 转载的其他相关文章： gfax7903 : 垂直搜索引擎是相对通用搜索引擎的信息量大、查询不准确、深度不够等提出来的新的搜索引擎服务模式，通过针对某一特定领域、某一特定人群或某一特定需求提供的有一定价值的信息和相关服务。其特点就是“专、精、深”，且具有行业色彩，相比较通用搜索引擎的海量信息无序化，垂直搜索引擎则显得更加专注、具体和深入。垂直搜索引擎能否赢得市场？垂直搜索引擎为用户提供的并不是上百甚至上千万相关网页，而是范围极为缩小、极具针对性的具体信息。因此，特定行业的用户更加青睐垂直搜索引擎，是垂直搜索引擎的长期、稳定的群体。中国十年多来互联网的不断发展,造就出1.3亿的网民，搜索引擎也出现空前的火热。在互联网出现的初期，雅虎、新浪、网易等大型门户网站拥有着绝对多的浏览量，原因在于当初的大部分网站在技术上无法与门户网站相媲美，多数质量较差，内容不丰富，所以大型门户网站优秀的网页设计风格，大量的信息及时更新赢得了用户的认可，创造了第一次互联网的高峰。然而随之近年来网络技术的普及与应用，建立一个专业的网站已经不存在太多的技术门槛。于是看好互联网前景的网站纷纷涌现在我们的面前。相对比而言在某些领域中，大型门户网站的页面风格反而不如一些中小型网站的界面漂亮，同时各种分类的行业网站也慢慢的兴起，也使得门户网站的专业性信息远远难以相论，如此一来导致了流量的分流，众多的商家也逐渐意识到互联网商机并不像当初抄做的那样有实际价值。于是互联网第一次危机出现，这也是互联网发展的必然趋势。搜索引擎的出现，整合了众多网站信息，恰恰起到了信息导航的作用。通用搜索引擎就如同互联网第一次出现的门户网站一样，大量的信息整合导航，极快的查询，将所有网站上的信息整理在一个平台上供网民使用，于是信息的价值第一次普遍的被众多商家认可，迅速成为互联网中最有价值的领域。互联网的低谷由此演变为第二次高峰。大家熟知的搜索引擎Google、百度、雅虎等是通用搜索引擎现如今的杰出代，他们为互联网的发展做出了重要的贡献。然而，搜索引擎行业也不是一家公司就可以独撑天下的，从百度的上市、yahoo中国的并购一系列动作表明，如今的搜索引擎大战如同门户网站初期的竞争一样激烈。相信，通用搜索引擎在经历过一段时间的角逐后，也将会继续维持几大服务商各自分控一部分市场的局面。垂直搜索引擎概念的提出，就是针对性的为某一特定领域、某一特定人群或某一特定需求提供的有一定价值的信息和相关服务。可以简单的说成是搜索引擎领域的行业化分工。众多专业性网站、行业网站独立服务于互联网的成功，恰恰证明了互联网的格局应该是多方面的。通用搜索引擎的性质，决定了其不能满足特殊领域、特殊人群的精准化信息需求服务。市场需求多元化决定了搜索引擎的服务模式必将出现细分，针对不同行业提供更加精确的行业服务模式。可以说通用搜索引擎的发展为垂直搜索引擎的出现提供了良好的市场空间，势必将出现垂直搜索引擎在互联网中占据部分市场的趋势，也是搜索引擎行业细分化的必然趋势。 1、垂直搜索引擎不是什么？垂直搜索不只是类google的行业通用搜索。以房产行业为例，如果我们按照google抓取网页的方式，来建造一个房产行业google的做法，是行不通的。技术壁垒不用解释，就算我们借助nutch,lucene等搜索技术来做，我们也无法提供差异化的服务,而没有差异化的产品在互联网赢家通吃的规则下是无法生存的，就是不要简单地模仿，而要想办法形成互补。垂直搜索和目前的google,baidu等通用搜索从定位，内容，用户，市场策略等都是不同的。所以垂直搜索不只是简单的行业google。用户使用google,baidu等通用搜索引擎的方式是通过关键字的方式实现的，是语义上的搜索，返回的结果倾向于知识成果，比如文章，论文，新闻等；垂直搜索也是提供关键字来进行搜索的，但被放到了一个行业知识的上下文中，返回的结果更倾向于信息，消息，条目等。对买房的人讲，他希望找的房子供求信息和文章，新闻等不同。这个特性是他们各自的的技术特点决定的。打个比方，如果google搜索引擎是一个正金字塔型，那么垂直搜索引擎就是个倒金字塔型，两者是互补的。 2、垂直搜索是什么？我认为：垂直搜索的本质是对垂直门户信息提供方式的一次简化性的整合。搜索领域有句明言：就是用户无法描述道他要找什么，除非让他看到想找的东西，这个过程有点像找对象，碰运气是用户搜索行为的最大的特征。而垂直搜索引擎就是提高为用户提供更好的运气。垂直搜索是服务于某项功能的，比如：用户搜索租房，买房信息就是一种垂直搜索。对信息的再加工处理是非常关键的，不管是结构化的数据，还是非结构化的数据。 3、垂直搜索的内容来源： A门户网站自身的资源 B以开放接口方式让行业用户提供的资源 C普通用户发布的资源 D抓取行业用户的资源微软亚洲研究院负责搜索的一名技术专家说：75%的内容通用搜索引擎搜索不出来。这里面包含2层含义：（1）网站结构不合理，网页对搜索引擎不友好；（2）由于信息在互联网是海量的，非结构化的信息需要经过结构化的梳理后才能更好的展现。如果梳理者能提供搜索，那样会更好。而垂直门户网站就是行业信息最好的梳理者。垂直搜索引擎提供的主要内容不应该局限于普通的网页索引，而且包括商业信息的加工，结构化的信息。 4、进入垂直搜索的门槛在那里？在互联网上说门槛，就是比资源。垂直搜索也是这样，能否提供全面权威的行业信息，能否拥有行业资源是垂直搜索引擎发展的门槛。换句化说，垂直门户是垂直搜索血统最近的父亲。作为房产行业的搜房网就是一个垂直门户，在房产领域没有谁比我们更清楚什么是垂直搜索了。垂直搜索的难点不是技术，而是用户参与门户网站行为的创新和垂直门户网站对产业上下游信息资源的整合。 5、垂直搜索的特点：（1）、搜索是一个产业商业联盟的平台，一个集成产业链的上下游公司的搜索门户。（2）、垂直搜索的表现方式和google,baidu的表现方式不同，结构化的搜索和非结构化搜索并用。（3）、从广告模式上提供了除 google adsense 和百度竞价排名广告之外的另一种可能。 6、垂直搜索引擎的三个特点：（1）、垂直搜索引擎抓取的数据来源于垂直搜索引擎关注的行业站点：比如：找工作的搜索引擎 www.deepdo.com 的数据来源于：www.51job.com , www.zhaoping.com , www.chinahr.com 等等；股票搜索引擎 www.macd.cn 的数据来源于： www.jrj.com.cn , www.gutx.com 等股票站点；（2）、垂直搜索引擎抓取的数据倾向于结构化数据和元数据：比如：我们找工作关注的：职位信息：软件工程师；公司名称，行业名称：软件公司，外包行业等；地点：北京，海淀；（3）、垂直搜索引擎的搜索行为是基于结构化数据和元数据的结构化搜索：比如：找：海淀软件工程师的工作等。 7、垂直搜索引擎站点的8条准则： 1、选择一个好的垂直搜索方向。俗话说男怕选错行，这一点对于搜索引擎来说也是一样的，除了选择的这个行业有垂直搜索的大量需求外，这个行业的数据属性最好不要和 Yahoo,Google等通用搜索的的抓取方向重叠。目前热门的垂直搜索行业有：购物，旅游，汽车，工作，房产，交友等行业。搜索引擎对动态url数据不敏感也是众所周知的，这些可以作为垂直搜索引擎的切入点； 2、评价所选垂直搜索行业的网站、垂直搜索内容、行业构成等情况：我们都知道垂直搜索引擎并不提供内容来源，它的数据依赖爬虫搜集，并做了深度加工而来的。因此考虑垂直搜索引擎的所处的大环境和定位至关重要。 3、深入分析垂直搜索引擎的索引数据特点：垂直搜索引擎的索引数据过于结构化，那么进入的门槛比较低，行业竞争会形成一窝蜂的局面；如果搜索数据特点是非结构化的，抓取，分析这样的数据很困难，进入壁垒太高，很可能出师未杰身先死。 4、垂直搜索引擎的索引数据倾向于结构化数据和元数据，这个特点是区别于yahoo,google等通用搜索引擎的，这是垂直搜索引擎的立足点。而垂直搜索引擎是根植于某一个行业，因此行业知识，行业专家这些也是通用搜索引擎不具备的。也就是说进入垂直搜索是有门槛的。 5、垂直搜索引擎的搜索结果要覆盖整个行业，搜索相关性要高于通用搜索引擎，贴近用户搜索意图，搜索结果要及时。 6、垂直搜索引擎的web 2.0 需求：垂直搜索引擎的搜索数据由于带有结构化的天性，相对于通用搜索引擎的全文索引而言，更显的少而精。因此，设计的时候要提供收集用户数据的接口，同时提供tag,积分等机制，使搜索结果更加“垂直”。 7、垂直搜索引擎的目标是帮助用户解决问题，而不只是向通用搜索引擎一样发现信息：这一点是垂直搜索引擎的终极目标。在做垂直搜索引擎的时候你需要考虑：什么问题是这个行业内的特殊性问题，什么问题是一般性问题。keso多次提到google的目标是让用户尽快离开google，而垂直搜索引擎应该粘住用户。一般来说，使用垂直搜索引擎的用户都是和用户的利益需求密切相关的。所谓利益需求是我自己独创的，大意是和用户工作密切相关，生活中必不可少的需求，而求有持续性。比如：学生找论文，业主找装修信息等等这样的需求。因此粘住用户，让用户有反馈的途径是一个关键部分。 8、垂直搜索引擎的社区化特征：这一条和第9条是相关的。俗话说物以类聚，人以群分，垂直搜索引擎定位于一个行业，服务于一群特定需求的人群，这个特点决定了垂直搜索的社区化行为。人们利用垂直搜索引擎解决问题，分享回馈。现在做网站都讲求社区化，所以垂直搜索引擎本质上还是：对垂直门户信息提供方式的一次简化性的整合。搜索市场细分 Google、百度面临挑战百度上市后，搜索市场一下子热了起来。越来越多的企业围绕着搜索市场作起了文章。而且，在搜索大战的同时，一些企业也抛出了一些惊人言论。近日，记者从专业做人脉交际的联络家（www.linkist.com）技术总监冉征处了解到，联络家正在加紧研发人脉相关领域的专业垂直搜索引擎系统，比如工作招聘信息搜索引擎等，预计将在2005年底推出，联络家之所以涉足专业垂直搜索引擎领域，是看到未来垂直专业搜索引擎市场的巨大商机，他认为未来搜索市场将进一步细分，象Google、百度等主张大而全的全球式搜索引擎将会面临垂直专业搜索引擎更大的竞争与挑战，他们的市场分额将会被逐渐瓜分，专业的行业性垂直搜索将受到网民的青睐。那么缘何能得出如此结论呢？冉先生解释，CNNIC第十四次互联网调查显示，搜索以71.9％的绝对优势成为用户从互联网上获得信息的主要方式。几乎在全球所有的调查中，搜索引擎都是互联网上使用程度仅次于电子邮箱的服务，搜索引擎服务能成为最受欢迎的服务是因为他解决了用户在浩瀚的互联网海量快速定位信息屏颈问题，在海量的网页里找信息按照传统方式需要用户一个网站一个网站一级目录一级目录下找，要耗费大量的精力和时间，几乎是不可能实现的任务。但互联网的信息量呈爆炸趋势增长，几年前全球式搜索引擎收录的网页量只有几千万页，而现在已经达到几十亿页，数量增加带来的是搜索服务的品质下降，查询的结果集就是海量的，经常是几十万笔的资料，结果里存在大量的重复信息和垃圾信息，用户越来越难迅速的找到符合的信息，现在经常使用搜索引擎可以感觉到很难在短时间内准确的筛选出需要的内容，而垂直搜索引擎针对专业特定的领域或行业的内容做了专业和深入的分析挖掘，精细分类，过滤筛选等，信息定位更精准，因此在此垂直领域或行业提供的搜索服务势必更好更强，更为用户所欢迎。比如，对于一个网民来说如果有对特定的领域或行业的信息需求的时候，如果一个是专业的垂直搜索能做到精确锁定内容，但内容量偏小，而另一个是能检索出大量内容，但搜索到的内容一大部分都是“垃圾”并且很难找到符合的信息，这样的话，你会选择哪个呢，就如用户想购买一个商品，他是会去专门的比价购物搜索引擎上找还是会去Google上找，如果你想找一份工作，是会去专门的工作搜索引擎上找还是会去百度上找？答案很明显，更多的用户会舍弃后者，即使前者品牌小名声小，但结果往往是最令网民看重的。冉先生还象记者举了个简单的例子，联络家LINKIST一直做人脉交际圈的拓展，也就是现在炙手可热的SNS网站，SNS网站的目的就是要建立一个庞大的人脉圈，参与其中的人都能通过站内人脉的搜索引擎找到自己想找的人，可以找工作、搜罗人才、寻找合作商机。联络家LINKIST短短几个月的时间已经聚敛起了近7万多位高级商务人士。有了一定的用户基础做铺垫，联络家LINKIST目前大力开发人脉专业领域的垂直搜索引擎，如工作搜索引擎的人脉搜索引擎，而这比以往的“贴简历、翻招聘信息”的机械作法要灵活的多。而且，能做出这样的预测显然并不是空穴来风。据记者了解，现在搜索市场大量的的垂直专业搜索引擎的诞生如雨后春笋般，如比价购物搜索引擎，工作搜索引擎，博客搜索引擎等等，占了百度几乎一半以上的流量的MP3搜索，其实也可以说是专业的搜索MP3的垂直搜索引擎，许多垂直门户也纷纷推出了自己的搜索引擎系统。记者获悉，之前刚从网易内容总监职位上辞职后创业的李学凌也作起了针对博客内容的搜索引擎，这也表露出，垂直搜索引擎的市场正在孕育过程中，既是机会又存在着挑战，其赢利模式也已经在Google、百度等身上得到了验证。而且，很多风险投资（VC）对搜索的概念已经认可并下了赌注。那么，象Google、百度能会不会通过“补课”挤掉这部分专用搜索市场呢？冉先生对记者表示，Google、百度注定了走的是大而全的粗犷路线，而专用的垂直搜索引擎则不同，需要对做内容的深度挖掘，做精细的分类，构建专业领域的知识库体系等等，而这些都是Google、百度等无法做到的，他们根本就没有精力做这些，也不可能针对每个行业领域都能做透，“术业有专攻”就是这个道理。就象门户网站与专业垂直的行业性网站可以共存一样，网民也有不同的胃口，有的仅仅是简单模糊的信息就已经满足了，而一些寻找精确内容的网民则更青睐于专业引擎，比如你打算换一份工作，以前去人才招聘网站贴简历往往都尿杳无音信，现在，就可以去联络家LINKIST试试，还能跟同行的朋友交换下最新的行业信息，探讨下行业发展趋势。而且，以后联络家LINKIST推出人脉引擎后，只需轻轻点击便能收获颇丰。有专家预测，未来，专业的垂直搜索将掀起一轮热潮，而且，垂直搜索引擎不会是一个简单的文本框、一个按纽就走遍天下了，更需要专业的信息辅助和配套的增值内容的支持，也就是对相关内容的二次“加工”。而这恰恰是Google、百度类所不能提供的。相信，届时很多VC的眼球会聚焦于此，而Google、百度又将面临怎样的挑战呢？我们只能拭目以待了。要了解垂直搜索引擎，就要同大家熟知的横向搜索引擎即通用搜索引擎来做对比。目前互联网领域主要的搜索引擎服务商如yahoo、百度、google等，为用户提供的都是横向的海量信息搜索。他们可以满足大量信息的横向搜索、提供，但很难兼顾搜索的准确度与相关度的质量。通用搜索引擎的价值在于在做大量的信息导航，对于信息需求相对集中、分类更加详细的行业客户缺乏导向。垂直搜索引擎的产生正是有效的解决了以上通用搜索引擎无法满足的市场需求。垂直搜索指搜索引擎为用户提供的并不是上百甚至上千万相关网页，而是范围极为缩小、极具针对性的具体信息。换言之，搜索引擎收集的是市场空间中某一“市场利基”的数据，如工作、旅游、高端房地产等。这样的信息不但更加易于为用户所消化，而且也更有深度。 Google、雅虎、MSN这几大搜索引擎巨头主宰着互联网搜索市场，全球大多数网民都是通过这几大搜索引擎查找自己所需的信息的。但在查找一些具体信息时，这几大搜索引擎的表现却并不尽如人意。有时候用户得到的是往往是和他们的查询本意风马牛不相及的结果。对拉近用户及其所需信息之间的距离的需求催生并促进了搜索行业的利基发展。垂直搜索引擎瞄准的正是搜索市场中的不同利基市场。利基是Niche这一英文名词的译称，利基市场指市场中通常为大企业忽略的某些细分市场；而利基市场战略则指企业通过专业化经营来占领这些市场，从而最大限度的获取收益所采取的策略。实施利基战略的重要意义在于：进行市场利基的公司事实上已经充分了解了目标顾客群，因而能够比其他公司更好、更完善地满足消费者的需求。并且，市场利基者可以依据其所提供的附加价值收取更多的利润额。总之，市场利基者获得的是“高边际收益”，而密集市场营销者获得的只是“高总量收益”。分析家认为：利基搜索市场和强大的在线广告市场之间有着密切的联系。管理者可以象Google和雅虎那样利用搜索结果页面运作广告，即在搜索结果页面上提供一定的定向文本广告。这种广告策略已被视作搜索行业的一个盈利渠道。对于垂直搜索引擎来说，由于数据源得到了详细划分，使得对这些数据进行操作，并将其通过简单易用、消费方便的方式表现出来变成可能。此外，以往的两种网络广告“每千次展示成本”和“每点击付费（CPC）”这两种广告方式上存在着效率低下，广告费用风险高的问题，这也正是垂直搜索被看好的一个主要原因。垂直搜索能够提供更为集中的受众群体，从而提高搜索引擎广告的宣传能力。同时，垂直搜索也能够有效推动新的广告商机的发展――我们姑且称之为“每行动成本”。这种广告方式不限广告投放量，按照广告投放的实际效果，即按潜在客户回应行动计费。浅谈垂直搜索引擎通过关键字："垂直搜索引擎"在google查一下,在返回结果中可以看到不少的投资公司很看好这一领域,即使百度的发言人也在演讲中提到垂直搜索引擎,而一些国外软件巨头例如Google和Microsoft也在这一领域有所动作,据说Microsoft的一个研究购物的小组最近就推出了一个购物垂直搜索引擎, 首先，谈谈垂直搜索引擎的基本原理,垂直搜索引擎针对某个特定领域,招聘、购物、blog、新闻等方面都是垂直搜索的潜在领域,假想一下,如果网络上有非常便利的产品垂直搜索引擎、新闻垂直搜索平台,以后上网就不会漫无目的了,现在许多的行业门户做的很红火,而垂直搜索引擎的模式本身就是一种很好的门户网站. 接下来谈谈垂直搜索引擎的技术,垂直搜索引擎技术同信息采集技术有一些共同点,不同的是,信息采集主要是将采集的信息导入本地库，而垂直搜索引擎主要是以网页的形式展现给用户,通用搜索引擎主要是利用一个spider程序到网络上爬行,一般是某个特定的周期派出一次将网页更新,垂直搜索引擎同样应有一个spider程序，但该程序只在一些特定的网络上爬行，并不会对每一个链接都感兴趣,相对来说,垂直搜索引擎的收录范围大大缩小了,但并不意味着内容的缩小,通用搜索引擎对一些动态脚本是不敏感的,例如***asp?id=***之类的网页一般不被收录,而恰恰是这类动态网页包含了丰富的内容,垂直搜索引擎是必须收录这些动态脚本的,这就需要在技术上做一些特殊处理,另外由于目前网页中的链接形式非常多,不但有动态脚本也有flash做的链接,这些链接方式通过传统的spider程序是很难解析出来的,在垂直搜索引擎中也应该解决. 以上只是垂直搜索引擎的简单说明,如果需要深入了解甚至实际开发,建议按如下步骤深入学习: 1) 到搜索引擎中查一下垂直搜索引擎,进一步了解垂直搜索引擎的应用前景 2) 如果要实际开发一个垂直搜索引擎,建议到一些开源网站上找一些spider程序进行分析,看看如何改造成一个垂直搜索的spider,一般将爬行全部链接的方式改为只爬行特定链接.这些特定链接可以通过正则表达式的方式来匹配，凡不符合匹配的不进行采集.

dido机器人#2 · 2007/6/2

转载：本文先引用几句话： 1.“确解用户之意，切返用户之需。” 2.“门户网站都想着是怎样省钱，而不是怎样花钱来买技术。” 3.“搜索引擎不是人人都能做的领域，进入的门槛比较高。” 4.“只是优秀还不够，最好的方式是将一件事情做到极致。”（google十大真理） 5.“做搜索引擎需要专注” “对于一项排到第四的业务，门户很难做到专注。” 6.“用户无法描述道他要找什么，除非让他看到想找的东西。” 7. “所谓楔形，其实就是个倒三角，倒三角的尖端部分代表搜索技术，中部是基于技术的产品应用平台，最上端是对整个搜索引擎用户人群文化的认识和理解，以及现代公司竞争最关键也最捉摸不定的所谓品牌。” “楔形”蕴涵的另一个意义是：楔子要打到墙里，尖端是否锐利很重要，但楔子的破坏性有多强，究竟能在墙面挤压出多大的空间，其中端、后端的沉稳与厚重才是关键。搜索引擎的技术和理念都是需要时间和经验的积累的，更是需要长期不断的完善进步的，绝对不要认为可以一蹴而就，要达到一个相对成熟领先的搜索引擎从开始到领先的周期一般需要是四年。着急不得。原因是因为搜索引擎太复杂，而且“用户无法描述他要找什么，除非让他看到想找的东西。” 一切都需要摸索，尝试，问题需要一个一个解决，用户的需要得一点点的挖掘。搜索引擎是一个产品，给用户提供服务的产品，需要长期的不断的改进升级调整才能持续不断的提用户体验，需要满足用户不断增长并且变化的需求、需要不断适应网络的变化。这是因为网络环境是不断变化的、网民的需求也是不断变化的。千万不要把搜索当成项目来做，做完了撂那让用户去用那你肯定没戏。在搜索引擎领域是讲体验的、新的引擎如果用户体验一旦整体上有领先一年以上的差距并且持续2年，那前期的领先者的优势就荡然无存，因为搜索引擎的用户转移成本相对而言是比较低的而且口碑是最佳的传播方式。如果一个搜索引擎不能持续不断的技术创新理念创新，那对于这个搜索引擎来说就等于死亡。我们一般形容搜索引擎的领先是以时间计算的。比如：中搜离百度整体差距×年，百度离google的整体差距×年，……只要你能在用户体验上保持一年的领先优势持续2年，不需要炒作，一切纷至沓来。在用户体验面前，任何的炒作都显得很渺小。作垂直搜索引擎，麻雀虽小，但是五脏俱全。无论理念文化、产品管理、应用、技术都和搜索引擎的楔形理论没有什么区别。所以要做好一垂直搜索必须解决这几个方面。楔形的尖：垂直搜索技术。垂直搜索技术主要分为两个层次：模板级和网页库级。模板级是针对网页进行模板设定或者自动生成模板的方式抽取数据，对网页的采集也是针对性的采集，适合规模比较小、信息源少且稳定的需求，优点是快速实施、成本低、灵活性强，缺点是后期维护成本高，信息源和信息量小。网页库级就是在信息源数量上、数据容量上检索容量上、稳定性可靠性上都是网页库搜索引擎级别的要求，和模板方式最大的区别是对具体网页不依赖，可针对任意正常的网页进信息采集信息抽取……。这就导致这种方式数据容量上和模板方式有质的区别，但是其灵活性差、成本高。当然模板方式和网页库级的方式不是对立的，这两者对于垂直搜索引擎来说是相互补充的，因为技术只是手段，目的是切反用户之需。本文谈及的技术主要是指网页库级别垂直搜索引擎技术。搜索引擎的确是一项对技术要求比较高的应用，几年前相关的人才也比较少。现在搜索技术人才多了，相关的技术和技术的应用得相对以前而言更加成熟，但是竞争也更加激烈了。垂直搜索大致需要以下技术： 1. 信息采集技术 2. 网页信息抽取技术 3. 信息的处理技术，包括：重复识别、重复识别、聚类、比较、分析、语料分析等 4. 语意相关性分析 5. 分词 6. 索引信息采集技术，垂直搜索引擎spider和网页库的spider相比应该是更加专业，可定制化。可定向性的采集和垂直搜索范围相关的网页忽略不相关的网页和不必要的网页，选择内容相关的以及适合做进一步处理的网页深度优先采集、对页面有选择的调整更新频率……，采集可通过人工设定网址和网页分析url方式共同进行。垂直搜索对信息的更新有着特别的要求，根据这些特点可以从以下几点考虑1.信息源的稳定性（不能让信息源网站感觉到spider的压力）2.抓取的成本问题3.对用户体验改善程度。根据以上几点制定一种比较好的策略，要做到恰到好处。策略上可以评估网站/网页更新的系数、网站/网页的重要系数、用户点击系数（或曝光系数）、网站稳定系数……，根据这些系数来确定对这些网站/网页更新的频率。再由于新信息和更新了的信息list页面前面或者首页，所以对网页进行很好的分级可以以低成本很好的解决更新问题，系数比较低的网页一月update一次，稍微高点的一周update一次、中等的几天到一天一次、高的几小时到几分钟一次。类似搜索引擎的大库、周库、日库，小时库…… 基于视觉网页块分析技术，模拟IE浏览器的显示方式，对网页进行解析。根据人类视觉原理，把网页解析处理的结果，进行分块，再根据需要，对这些块进行处理，如：采集定向、介绍抽取和一些必要的内容的抽取正文抽取…… 结构化信息抽取技术，将网页中的非结构化数据按照一定的需求抽取成结构化数据。有两种方式，简单的就是模板方式，另外就是对网页不依赖web结构化信息抽取方式，这两种方式可以互取长处，以最简单最有效的办法满足需求。垂直搜索引擎和通用搜索引擎最大的区别就是对网页信息结构化抽取后再结构化数据进行深度的处理，提供专业的搜索服务。所以web结构化信息抽取的技术水平是决定垂直搜索引擎质量的重要技术指标。其实web结构化信息抽取在百度、google早已经广泛应用了，如：MP3、图片搜索、google的本地搜索就是从网页库抽取出企业信息，添加到其地图搜索中的，google通过这种技术正在颠覆做内容的方式。同样的技术应用还在qihoo、sogou购物、shopping等各种应用中体现。简单的语法分析，简单的语法分析在搜索引擎中非常重要，可以通过简单的语法分析来改善数据的质量，低成本的获得某类信息，改善排序，寻找需要的内容…… 信息处理技术，信息处理包括的范围比较广，主要包括去重、聚类、分析……，这根据需要相关的技术就非常多。数据挖掘，找出您的信息的关联性对于垂直搜索来说非常重要，有效，可以在这些相关性上为用户提供更细致的服务。分词技术，面向搜索的分词技术，建立和您的行业相关的词库。注意这是面向搜索的分词，不是面向识别和准确的分词。就这个工作安排十几个人不停的维护也不会嫌多。索引技术，索引技术对于垂直搜索非常关键，一个网页库级的搜索引擎必须要支持分布索引、分层建库、分布检索、灵活的更新、灵活的权值调整、灵活的索引和灵活的升级扩展、高可靠性稳定性冗余性。还需要支持各种技术的扩展，如偏移量计算等。其它技术，略。垂直搜索引擎的技术评估应从以下几点来判断 1. 全面性 2. 更新性 3. 准确性 4. 功能性锲形的中和尾：产品应用平台和对搜索引擎文化理念的理解对于任何一个产品来说，产品的模式是最重要的，技术只是手段、工具、途径。用户不会关心你的技术是如何实现的、更不会关心你的技术水平是什么样的，只要用户感觉：这就是我需要的东西，很好用，而且是最好用的。那么你的产品就OK了。考虑一个产品的模式需要考虑的东西很多，如：用户需要什么？需求有多大？能不能完整的实现用户的需求？需要什么资源？怎么做到？竞争分析？差异化？根据自身情况能做到什么程度？怎么样保持领先优势？能否收到钱？怎么样收钱？怎么样推广？需要多少时间？如何保证在时间窗口期内有效完成进度？如何分步分期优先完成用户最需要的需求？如何建立有效的反馈机制让我可以了解用户的需求变化和挖掘用户自己也无法表达的需求？如何进一步改善？分期需要多大的投入？如何降低整体成本和前期成本？如何分期投入？投资回报比？周期？…… 1. 确解用户之意任何应用最难的就是了解用户的需求，甚至是用户自己都不知道的需求。建立完善的、快速的用户意见反馈机制和用户需求调查机制，所有人都应倾听用户的牢骚、建议。不断的分析、修改。 2. 切返用户之需满足用户的需求，一切纷至沓来。不需要炒作，请把您的资源多多花费在为用户提供良好的体验上来。 3. 不要干扰用户的意图，培养用户的使用习惯和技巧有一个故事是这样的：还在yahoo使用google的搜索的时候，华尔街的几个分析师来评估这两个搜索哪个好用，去掉logo。结果一致评价yahoo的检索效果好。因为yahoo是使用的google检索结果，并且对热点关键词进行了人工调整。但是一转身这些分析师回到自己的电脑边查询东西，不约而同的打开了google。 4. 细节决定成败信息不是越多越好，在海量的信息时代，如果不能妥善的整理信息，那就等于没有信息。每个页面的每个字，每个像素、图片的放置都值得花费时间去琢磨。把用户最需要的放在最显眼的位置，次需要的放置到更多页面，不需要的扔掉。 5. 将一件事情做到极致不仅仅要关注80%的用户的80%的需求，20%的用户的20%的需求是您成败关键所在。 6. 专注这么多需要你解决的问题，你还能干其它事情？对于一个排在第四的业务你是没有机会的。所以垂直搜索引擎的成功肯定不是具备良好资源的行业门户、也不会是大搜索的公司，必然是专注于某一行业的搜索引擎公司。因为只有专注，才能将一件事情做到极致。 7. 创新失败不要紧，但是如果搜索引擎公司没有创新，那这个搜索引擎公司必然面向的就是死亡。 8. 需要完全掌握主要技术。一个核心业务不可能通过外包手段来解决技术问题。虽然找个大公司外包技术看起来很美丽，很快速，甚至成本比较低。但是这是在毁灭你的将来。因为这是产品，不是项目。产品是需要不断完善调整的，用户的需求也是变化的需要挖掘的，互联网也是变化的，你外包技术绝对不可能做到灵活、及时满足各种变化。在和竞争对手竞争的时候您如何保持您的领先优势？（前文说了，如果被对手保持领先一段时间，那么你之前的领先优势就荡然无存）。这里还没有考虑竞争问题，购买其它搜索引擎公司的技术，对方会不会把真正的技术毫不保留的卖给你。再说，卖你你你能搞懂吗？技术再困难也要自行解决。否则你注定失败。最好的办法就是购买核心技术缩短研发周期、成本、风险，再在这个核心技术进行自主研发。这是垂直搜索的技术门槛，看似不高，其实很高。对于技术问题可以迂回解决，用最简单的技术满足用户最迫切的需求。用户是不会关心技术实现的。模板方式可以是网页结构化信息抽取技术的补充。对于可行的应用早期采用模板技术也是不错的选择。比如chinabbs就做的很好，用户的主要需求是要浏览到好的帖子，所以加强内容的建设，找高水平的编辑做推荐，而且在界面和易用性上也很不错。领先qihoo。技术方面他们初期采用的应该是模板自动生成方式采集论坛信息，比qihoo技术水平差，但是这目前不是用户需求的关键，而且qihoo技术水平层次虽然高但是如果不成熟，体现给用户的东西未必就强。Chinabbs接下来再解决技术难点，在技术上有提升，那么他就能持续保持领先优势了。(但是话又说回来，招聘好的编辑很容易，技术要提升一个层次并且成熟很难，而且很耗费时间，当然用户习惯和知名度也是需要很长时间培养的) 9. 用最简单的技术实现用户最迫切的需要技术重要，但是技术的使用得当更重要，技术是为用户体验服务的。只要能满足用户需要，什么技术都可以，简单不代表不行，用最简单的技术实现用户最迫切的需要。百度的整体技术我认为离google中文至少有1年以上差距，很多方面差距更大，但是百度的效果比google好，原因就是将简单的技术用于实现用户迫切的需求。举个我身边的例子来描述简单的技术实现需求：我把我们的基于视觉的网页块分析的正文抽取技术演示给一好友看，好友看后说：我们也实现了。我大惊，他们不是做搜索的，居然也实现了！他告诉我他们实现的方法后，我再次吃惊，深感简单的技术也可以很好的解决问题，虽然不完全解决，但是能满足自己的需求就好。他们的解决方法是：对网页的html进行分析，将整段文字中没有html代码的文字提取出来，这就是正文。（惊叹！！如此简单！！注：他们的信息源都是这样的格式） 10. 根据中国本土互联网特点，强力的antispam，对信息进行清洗。 11. 很多人误解垂直搜索就是把相关的行业网页做一个采集，进行正文抽取，实现搜索，完成信息册查询。其实并非如此。如果这样无法和网页搜索竞争，网页搜索很容易就可以将网页库按行业分类、按地区分类。垂直搜索应该是对垂直行业信息进行深度的加工，有效的整合，为用户提供网页搜索无法做到的专业性、功能性，为用户提供深一步的服务和完整的体验，而且不仅仅是提供信息的检索。垂直搜索是和信息搜索有本质的差异化的。 12.专注用户体验的改善，任何的宣传炒作都是空乏无意义的，搜索引擎的核心在于用户体验，你只要改善用户体验，比别人强一点点，那么其它人的炒作和宣传都在为你打工本文会不断修改，请转载本文的网站保持本文的链接。如何做好一个垂直搜索引擎本文地址：http://www.FullSearcher.Com/n2005125125722735.asp 网站地址：http://www.FullSearcher.Com/ 文章来源：fullsearcher

Anchor机器人#3 · 2007/6/2

顶技术贴！明天电脑修好后加精

dido机器人#4 · 2007/6/3

发信人: maggiems (小Maggie), 信区: SearchEngineTech 标题: 微软亚洲研究院搜索技术中心招聘实习生发信站: 水木社区 (Thu May 10 17:41:42 2007), 站内 Position Intern Group MSR Asia – Search Technology Center Type Full-Time Quantity 3 Work Location Beijing Group Overview Microsoft Research (MSR) Asia and MSN Search have partnered to create the exciting new Search Technology Center (STC) in Beijing, China. Launched in October of 2005, the center is dedicated to advancing the state-of-the-art in search technology and delivering a more intelligent and powerful search experience to MSN users around the world. The mission is to: • Deliver innovative Search products and services together with MSN/Live search • Accelerate innovations by seamlessly combining research and development in MSRA • Evolve Search platform into an Internet Service platform for the next generation of Internet research and development Roles & Responsibilities 1. Work in distributed computing platform area; 2. Design & Implement test cases, conduct testing; 3. Design & Implement distributed application based on Internet scale data set; 4. Design & Implement test tools. Required Qualifications We are looking for 1. BS/MS/Ph.D candidate in Computer Science or any related technical field; 2. Interested in distributed computing platform and applications 3. Good programming skills in C/C++ 4. Quick learning capability; 5. Good system programming skill is a big plus 6. Good reading and written English; 7. Good communication skills and excellent teamwork. Qualified applicants please fill in the application and send it together with a full resume in both English and Chinese (PDF format) to: MSRAih@microsoft.com, and please note you are applying for MSRA STC Group.

dido机器人#5 · 2007/6/3

发信人: overnice (涅磐龙), 信区: SearchEngineTech 标题: 易查手机搜索公司诚聘应届硕士生（解决北京户口）发信站: 水木社区 (Tue May 29 22:22:58 2007), 站内公司简介：易查在线信息技术（北京）有限公司是一家由美国麻省大学留学归国人员创办，并赢得全球著名风险投资机构青睐和投资的高新技术企业。数位美国留学归来的科技人携世界水平的搜索引擎和网络挖掘技术，于2004年7月推出中国移动互联网第一个手机搜索引擎，获国际风险VC800万美金投资。公司使命是向用户提供随时随地的手机搜索。截至2006年11月底，易查搜索的用户达到1200万，日搜索量达到1020万，拥有中国移动互联网近50%的搜索市场份额，包括腾讯在内的前50名WAP站点中有38家站点使用了易查的搜索服务，中国移动互联网中的11.5万家WAP站点有2.3万家使用了易查的搜索服务。公司秉承诚信、专业、开拓、创新的经营理念，以在IT行业的技术优势为依托，为用户提供方便、快捷、精确、个性化、专业化的移动搜索服务。公司管理层和核心技术人员分别来自国际风险投资领域、在海外上市的国内大型互联网企业、全球领先的搜索引擎服务企业等，具有丰富的管理经验和搜索引擎研发经验。一流的技术，和睦开放的人文环境，充满挑战性和创造性的研究项目，会令你感受到大学研究一样的氛围。我们期待着有识之士的加盟，携手发展，共创易查美好未来！公司地址：北京市海淀区知春路甲48号盈都大厦B座11层联系方式：lijunxia@yicha.cn 以下职位供参考选择（招聘职位包括但不限于以下职位） 1、 C语言高级开发工程师任职要求：（1）计算机或相关专业本科以上学历，具有2年以上大型软件开发经验（2）精通Linux/Unix平台上的C/C++语言编程，熟悉网络、多线程编程技术（3）熟悉算法设计与数据结构，有系统分析设计经验（4）有搜索相关领域工作经验者优先（5）有自我激励能力，乐于承担工作压力 2、网页搜索研发工程师工作职责：（1）网页信息抽取，数据挖掘分析（2）核心算法研究与调优（3）搜索引擎系统架构设计开发任职要求：（1）计算机或相关专业本科以上学历，2年以上相关研发经验（2）对自然语言处理、信息检索、数据挖掘、分布计算等领域有深入研究及相关项目经验（3）深厚的算法和编程功底，很强的学习能力及实干精神（4）对搜索引擎领域有深入了解，能够创造性地发现和解决实际问题（5）有自我激励能力，乐于承担工作压力 3、搜索引擎高级软件工程师工作职责：（1）搜索引擎系统架构设计开发（2）分布式大规模网络服务设计（3）核心算法研究与调优（4）海量数据处理分析任职要求：（1）计算机或相关专业本科以上学历（包括应届硕士毕业生）（2）精通C、C++语言，2年以上开发经验（3）熟悉网络通信、多线程编程技术（4）精通算法设计与数据结构，有系统分析设计经验（5）有大型分布式网络系统研发经验者优先（6）有网络搜索引擎开发经验者优先（7）具有良好的学习能力、沟通能力，乐于承担工作压力 4、JAVA高级开发工程师任职要求： (1)计算机或相关专业本科以上学历 (2)精通Java语言，有两年以上开发经验 (3)熟悉面向对象编程，有一定系统设计分析经验 (4)熟悉各种大型数据库及互联网应用协议 (5)工作踏实勤恳，有很强的责任心 (6)具有良好的学习能力、沟通能力，乐于承担工作压力

Anchor机器人#6 · 2007/6/3

帮你转到job版了【在 dido (dido) 的大作中提到: 】 : 发信人: maggiems (小Maggie), 信区: SearchEngineTech : 标题: 微软亚洲研究院搜索技术中心招聘实习生 : 发信站: 水木社区 (Thu May 10 17:41:42 2007), 站内 : ...................

Anchor机器人#7 · 2007/6/3

帮你转到job版了【在 dido (dido) 的大作中提到: 】 : 发信人: overnice (涅磐龙), 信区: SearchEngineTech : 标题: 易查手机搜索公司诚聘应届硕士生（解决北京户口） : 发信站: 水木社区 (Tue May 29 22:22:58 2007), 站内 : ...................

tourer机器人#8 · 2008/8/21

好人！