具体实施方式
为更好地理解本发明实施例所解决的问题,考虑使用WAP电话的简单例子,如图1所示。为了访问当日的当地影院节目表(都柏林Stillorgan的Ormonda影院),用户必须采用以下序列的动作:
图1(a):在主菜单上滚动并选择[Entertainment(娱乐)]选项(选项7)。
图1(b):在娱乐菜单上滚动并选择[Cinema(影院)]选项(选项4)。
图1(c):在影院菜单上滚动并选择[Cinema Times(影院时代)]选项(选项1)。
图1(d):滚动并选择[Dublin(都柏林)](选项9)。
图1(e):最后,选择[Ormonde](选项8)。
这显示了在当前WAP门户上的典型用户会话,而且即使该用户可能经常查询Ormonde影院节目表,该WAP门户也不能修改其结构以更好地服务该特定用户。
参看图2,已知用户偏好使用其WAP电话作为来自Ormonde的影院节目表的来源,现在要描述的实施例将[Ormonde]菜单选项提升到该WAP菜单结构中更高的位置上—例如在图2(a)中,顶级[娱乐]选项从位置7提升到头3个顶级位置内(即用户看到的第一屏),在图2(b)中,[Ormonde]选项提升到娱乐菜单的顶部。在该例中,我们还看到用户对电影的偏好反映在将来自该WAP站点的电视节目表部分的[TV Movies(电视电影)]提升选项上。当然,也可能向用户提供对其他有关站点部分更直接的访问,如剩余的影院与电视选项。
图3为融入WAP门户的本发明的第一实施例的系统结构的方框图。大家将理解没有显示该门户的全部体系结构,只显示了解释本实施例必须的部分。该实施例包括多个不同的软件组件,包括菜单管理器10与包括个性化引擎14与定制引擎16的菜单服务器12。
菜单管理器10是面向用户的应用,被设计来允许非技术人员18迅速开发、配置并部署被完全个性化了的信息服务,不管该服务基于WAP或万维网。个性化引擎14为控制个性化菜单页的生成与建立用户行为特征集的子系统。客户端20一般为标准万维网或WAP浏览器。定制引擎16为向最终用户22提供客户端应用以允许用户完全定制该门户的部分以修改或超越自动个性化的子系统。客户端24一般为标准万维网浏览器。
一般地,以下列方式使用菜单管理器10。首先,管理员18使用菜单管理器的快速原型功能(将参照图4描述),为其门户创建并定义核心内容与缺省结构。该核心内容存储在内容数据库26内。然后,仍然使用菜单管理器10,管理员定义基本个性化属性,包括在每一级上看到的菜单选项数目,以及该门户对个性化的敏感度(将参照图5描述)。然后,部署最后的门户,并使其可被最终用户22使用。
一旦公布了该门户,则用户可以通过与定制引擎16交互(将参照图6描述),手工定制该门户结构。简要而言,这使用户能够预先选取门户站点的特定菜单选项,并将这些选项提升到该站点菜单结构中的较高位置。例如,电影迷可以指定指向其当地影院的菜单链接应包含在顶级菜单之中,而不是隐藏在低一些的菜单中。另外,定制引擎使用户能够去除该门户站点的与用户需求无关的部分,并且还使用户能够指定该站点的特定区域不应该受自动个性化影响。一般而言,通过标准万维网浏览器24,使用户可以使用该个性化引擎,而且该个性化引擎包括直观的图形用户界面,以使用户作出这些定制修改。
一旦公布了该门户,则个性化引擎14开始监视并跟踪每一单个用户的活动,并根据每一用户的浏览历史,主动修改该用户的浏览体验。这意味着每次用户通过其浏览器请求新页时,将基于已由该门户管理员所建议的缺省选项,以及基于由个性化引擎14所推荐的建议选项,实时地计算将在该页上显示的菜单(导航)选项。在实践中,(对用户)受欢迎的菜单选项被提升到分级式菜单结构中的较高位置,从而对当前用户该门户站点的这些区域将更便于访问。
更详细地考虑上述每一组件,菜单管理器10为面向用户的应用,具有直观的GUI界面,使非专业人员能够迅速地设计并部署复杂信息门户。用户使用拖放功能,能够容易地定义菜单与内容页。菜单管理器将自动生成并公布构成最终门户站点的源文件(.wnl,.html,.xml),而且可以在几个小时内开发并测试大型门户。
图4展示了使用中的菜单管理器的屏幕显示样例。主界面被分为3个主要部分:站点结构30、页属性32与错误报告34。站点结构部分30使管理员能够使用直观的基于树的表示法与拖放风格的界面,定义该门户站点的菜单结构,其允许将单个的页增加、删除或转移到该站点的不同区域。
图4示出构造一个具体门户站点,该站点的根系于称为“e-merger home”的主页上。管理员已经定义了多个包含第一与第二级链接的不同的页。例如“e-merger home”主页包括指向标题为“E-mail+Org”的菜单页的链接,该页还包含指向称为“Messenger”,“WAP Mail”等等的信息页的链接。
当管理员定义基本站点结构时,他也可以在部分32中指定每一页的详细的属性,包括:
Title name:出现在菜单管理器中的页标题。
Screen label:为公布该门户后,如果屏幕标签不同于标题名称,则在客户端浏览器上出现的页标题。标题名称经常不适合用于屏幕标签,尤其是如果标题名称从某内部页编码方案推出,而一般为这种情况。
Promotion name:管理员可以为页指定分离的提升名称,如果该页已经被从其缺省菜单位置提升出来,则使用该提升名称。这使管理员能够为页提供附加的上下文信息,不如此,这些信息在提升时将丢失。例如,考虑来自门户的电视部分的一页,具有屏幕标签“Top Pics”。该页被设计来列出一给定天的顶部电视节目,但只有在该页保持为来自电视页的链接时,这一点才清楚。如果该“Top Pics”页受用户欢迎,则该页将被提升到更高的级别上,而其意义将不再清楚。为解决此问题,管理员可以指定提升名称,例如“TV:Top Pics”。
Body:该属性使管理员能够为当前页指定呈现模板,以控制如何向最终用户呈现该页。
URL:该页的URL。
Advert:管理员可以包含指向广告插件的链接,该广告插件将包含于该页(对万维网内容)或包含在该页之前(WAP内容)。这一点的具体好处是它使广告信息可以被定向,即因为管理员可以将特定的广告与有关的菜单关联,所以这些广告将更频繁地被感兴趣的用户看到,因为这些用户将在其个性化菜单中提升这些菜单。例如,RyanAir可能购买一门户的旅行部分的广告空间,这是通过以下完成的:将他们的广告标语置于顶级旅行菜单,该标语一般引向整套的有关旅行的服务。问题是RyanAir希望定向到对旅行感兴趣的人,因为这些人更有可能购买机票。一般地,RyanAir广告与旅行菜单会被静态地放在站点内。然而,既然该站点被个性化了,对旅行感兴趣的用户将会看到提升到菜单等级内较高位置的旅行部分,并且更有可能进入该站点的旅行部分并看到RyanAir广告。查看这条广告的相关用户对无关用户的比值将大大增加。另外,管理员可以为每一页指定特定的关键性个性化属性,以控制在什么时间与如何个性化该页。例如,图5(a)示出创建新菜单页,图5(b)示出创建新链接页,图5(c)示出为这些页设置不同的个性化属性。图5(a)与5(b)所示的“新页”窗口通过点击图4的菜单管理器窗口中适当的按扭来打开,而图5(c)的“属性”窗口通过点击图5(a)或5(b)中的“高级”按扭来打开。具体地,可以设置以下个性化属性:
Max Links:在相关页上所能出现的链接的最大数目(显然这不适用于链接页)。这表明进行个性化的人对一给定页可以提出多少个性化建议。例如,如果该页的最大链接设置为8,但管理员已经指定了5个链接,则进行个性化的人只能推荐3个额外的链接。当然,如果5个管理员链接中的任意一个本身已经被提升,则可以再作额外的个性化建议。该属性对开发以下门户尤其重要:该门户将使用屏幕受限的设备(如移动电话)进行查看,这是因为这使管理员能够对每一页保证最大的页大小。
Hit Threshold:该点击阈值为一数字,用来指定页在被考虑提升之前所必须接到的点击的最小数目。其好处是它使管理员能够限制在用户活动的早期阶段中不必要的提升/降低,此时还没有收集到足够的统计量,以保证可靠的个性化。一般该点击阈值在0与10之间(0表示该页总是可以用于提升/降低)。
No Promote:通过设定此不提升属性,管理员可以指定相关页不应作为个性化的一部分而得到提升。
Copy Promote对Move Promote:如果为给定页设置了拷贝提升,则当该页被提升时,此页不从其原来菜单位置上消失。例如,在前面的例子中,我们考虑了从电视菜单中提升“Top Pics”。如果为“Top Pics”设置了拷贝提升,则电视菜单仍包含指向“TV Pics”的链接。如果设置了移动提升,则在该例中,提升后“Top Pics”将不再是来自电视菜单的链接。
Promotion:提升属性使管理员能够指定页可以被提升的距离。例如,将提升设置为1指相关页只能提升到与其父辈菜单页同级的级别上。将提升设置为4指如果合适该页可以提升4个级别。
概括而言,菜单管理器10允许管理员迅速开发并配置个性化门户。该应用包括全项目管理功能,使管理员能够开发并管理多个门户。它还包括导入功能,使管理员能够导入现存的门户结构,该门户用不同的门户搭建包设计。该特征使管理员能够容易地将现有的非个性化的门户重新部署为完全个性化的门户,而不必重新输入门户内容。最后,一旦设计了门户,则管理员能够编译并公布最终内容代码。
定制引擎16的任务是向最终用户提供功能,以手工定制门户的菜单结构。
定制引擎能够生成门户结构的图形化表示,以由最终用户使用标准浏览器客户端操纵。生成该结构以反映用户正在使用该门户时所看到的结构;即,它考虑了以下因素:基本的门户结构(由管理员所定义),加任何先前的定制(由用户所指定),加任何当前的个性化建议(由个性化引擎14所提供)。
基本定制操作使用户能够请求将给定页从其在该站点的缺省位置移动到新的位置,如选择新的父辈菜单页所指示的。所有最终用户的定制都作为用户特征集结构的部分被存储在图3中的特征集数据库28中。另外,所有的定制必须符合管理员在设计该门户时所指定的配置设置。例如,如果移动违反了页内所允许的最大提升级别数目,则用户不能将该页移动到菜单中。还有,管理员可以指定特定的页是不可定制的,在这种情况下,这些页不能被重新放置。
图6(a)示出客户端的屏幕显示,其描绘了主门户站点的部分。图6(b)示出一弹出窗口,当用户在门户页(此处为“FLC Competition”)上选择时,启动该弹出窗口。该弹出窗口使用户可以改变此页的当前位置。该页的当前位置(其缺省位置)为“New+Cool”菜单。用户可以从该弹出窗口中的选择列表中为该页选择新的位置。例如,选择“e-merge home”将导致“FLCCompetition”链接显示在“e-merge home”页中。可替换地,用户可能希望将该链接从他/她的门户视图中去除,通过从选择列表中选择“Trash”选项,可以达到这一目的。
个性化引擎14为菜单服务器12的核心。表面上,个性化引擎以与任何一般的万维网服务器或WAP服务器同样的方式运行:接收并处理客户端对页的请求,并递送被请求的页。然而,该个性化服务器还能够监视在线的用户行为并能修改门户菜单结构的结构以最好地适应已了解的单个用户的偏好。即,个性化引擎能够重组内容门户,以使与用户有关的页出现在更靠近主页的地方,但不用破坏门户自身的一致性。简要而言,个性化引擎负责以下功能:
跟踪并构造在线用户行为特征集。这指监视用户请求了那些页(其选择了那些链接)并将该信息存储在用户的特征集中,其中,用户的特征集可以用作预测的根据。
将在线行为与用户所指定的定制结合,以产生统一用户特征集。
在每次请求的基础上,为每一用户单独地调整门户的菜单结构,以考虑其特征集中的偏好。即,当用户请求给定页时,通过结合有关该页缺省结构的信息与已了解的有关用户偏好与用户定制的信息,个性化引擎动态地为该页选择链接,从而为该页选择一组最佳的链接。
个性化引擎将一种用来存储与跟踪用户行为的新有效方法与一种用来预测用户偏好的算法相结合,所述算法基于先前的浏览行为以用户可能希望下一步去哪来预测用户偏好。
基本的特征集数据结构为命中表,下面将更详细描述的图7至10示出该命中表的范例。该命中表将父结点(菜单页)联系到子结点(菜单页或链接页)以及用户对每一子结点的选择次数。例如,在图9的右手侧,可以看到菜单页A已被访问20次,从页A到B的链接已被访问了17次,从B到E的链接3次,等等。
实际上,该实施例使用了两张表:静态命中表,相对于缺省门户结构地初始化;以及用户命中表,记录用户在该门户上的具体的历史。前者在图7至10中的左手侧示出,后者在右手侧示出。
静态表由菜单管理器10定义,以反映由门户管理员/设计者所指定的门户结构。它使门户能够在早期传送标准的菜单结构,但一旦累积了用户历史,这最终将被个性化菜单所超越。在静态命中表中设定的命中值使之能够控制个性化的延迟—低值意味着个性化很快起作用,而高值使系统对用户活动较不敏感。在效果上,静态命中表为初次新用户的假定的访问记录。随着用户浏览该门户,用户的选择被用来更新用户命中表,该命中表作为用户特征集的部分存储。
个性化引擎14自动地辨别并提供作为所选择的菜单页m的菜单选项的用户可能希望从该菜单页达到的前k个最可能的链接,即具有最大P(n|m)值的k个页,该P(n|m)值基于在静态与用户命中表中的当前值,并受制于站点管理员(例如最大链接数、命中阈值、无提升等等)或用户(如不可定制页)所施加的所有限制。表达式P(n|m)指已知用户当前在菜单m中,该用户最终选择链接n的概率。这是动态完成的,即当用户选择该菜单页时实时完成,而不时预先计算的。因此,个性化引擎不必基于用户先前的浏览历史预先计算整个菜单结构,而只需计算用户在选择菜单页时所希望访问的该菜单的有关部分。
当用户选择新菜单m时,个性化引擎定位从m的最可能的k个链接,并使用这些来构造m。根据用户的浏览历史,这些最可能的k个链接对不同的用户将不同。一般地,该k个链接中的一些由门户管理员指定为从m的链接,而其他已从较低级别提升而来。为了计算最可能的k个链接,个性化引擎使用静态与用户命中表,为在过去作为m的后代而出现的链接中的每一个计算P(n|m)。
为计算P(X1|X2),其中X1为X2的子结点(即X1为X2中的链接),将X1作为X2的子结点所得到的命中数目(其静态与用户命中表值之和)除以X2所得到的命中数目。
一般地,如果希望计算P(X1|Xn),其中X1与Xn根据父子关系连接(X1,X2,...Xn),从而X2为X1的父结点,X3为X2的父结点,等等。
则P(X1|Xn)=P(X1|X2)×P(X2|X3)×...×P(Xn-1|Xn)
另外,假设X1还作为X3,...Xn中的一个或更多个的子结点发生,则根据同样的方法计算P(X1|Xp),其中Xp为X3,...Xn中的一个,其以X1为子结点,并将这些概率相加,以计算总的概率P(X1|Xn)。
可以以正常方式计算每一子结点的概率,以显而易见的方式从一级一级累进(carry)概率(当子结点变为父结点时)。
关键是知道何时终止这一过程。理论上,似乎为了正确辨别菜单m的最可能的k个链接,该算法必须检查曾作为m后代出现的每一结点。在大菜单结构中,这样的代价将变得很大。然而,一种更有效的技术是可能的,其基于以下结论:
对n的所有子结点,P(n|m)>=P(child(n)|m)。
即,结点n的子结点相对于结点m的概率都低于n的概率。计算了与特定级别上的链接相关的概率之后,只需穿过已经取得比目前最可能的第k个链接的概率更高的概率的链接达到下一级别。
这意味着通过对根系于m的菜单树进行深度受限的广度优先搜索,就能为菜单m与用户u找到最可能的k个结点。命中表提供了进行这一搜索所需的树结构信息。即,
Children(m)=StaticHitTable(m)∪UserHitTable(m,u)
其中StaticHitTable(m)指静态表中m索引下的结点,UserHitTable(m,u)为用户命中表中为用户u的m索引下的结点。
通过一简单菜单结构描述个性化如何随时间进展,下列的例子详细描述了个性化过程。假定命中阈值为3并且每个页将构造为只包含2个链接。
1.新用户
图7示出了对首次用户的情况。因为还没有点击任何结点(页),所以用户命中表为空。
考虑对首次用户构造菜单页A。命中表表明结点A有两个直接子结点B与C:
P(B|A)=(20+0)/(40+0)=20/40=0.5
P(C|A)=(20+0)/(40+0)=20/40=0.5
此时不需要进一步处理,因为B与C都没有达到其命中阈值3(其用户命中表项为空,表明二者的命中值为0)。因此,将在页A中使用链接B与C,并根据其概率进行排序(在等概率的情况下,参照静态表中的命中值计算排序)。
2.极早阶段用户
现在考虑图8所示的情况。同一用户已经使用该门户很短一段时间,因此累积了一些初始用户命中值。再次考虑菜单页A的构造。相对于A为B与C计算概率如下:
P(B|A)=(20+3)/(40+5)=23/45=0.511
P(C|A)=(20+2)/(40+5)=22/45=0.488
此时,B得到3次用户命中,达到了命中阈值。另外,因为我们正在查看辨别每一菜单页的两个链接,所以只需扩展其概率大于目前所发现的第二个最佳结点概率的结点。这是因为,根据定义,菜单m中的菜单选项n的子结点或后代结点不可能比n的概率更高。在本例中,目前所发现的第二最佳结点概率为0.488。因为B的概率更大(0.511),并且因为B已经达到其命中阈值,所以需要扩展B以计算其子结点的概率。然而,应注意B的子结点没有一个达到其命中阈值,因此他们不能用于提升。因此,在菜单A中再次呈现链接B与C,由于其概率较高,所以B出现在C之前。
3.早期阶段用户
图9示出该用户的情况,仍在极早阶段,但已经收集了足够的使用信息以开始寻求某些个性化效果。
再次考虑菜单页A的构造。相对于A为B与C计算概率如下:
P(B|A)=(20+17)/(40+20)=37/60=0.616
P(C|A)=(20+3)/(40+10)=23/60=0.383
此时,B与C都达到了其命中阈值。因为我们正在查看辨别菜单页A的两个链接,所以需要扩展其概率大于目前所发现的第二个最佳结点概率的结点(即C的概率,为0.383)。因此只需扩展结点B(其概率为0.616)。
扩展B,计算其子结点相对于A的概率:
P(D|A)=P(D|B)×(P(B|A)=(10+14)/(20+17)×0.616
=24/37(0.616)=0.399
P(E|A)=P(E|B)×(P(B|A)=(10+3)/(20+17)×(0.616
=13/37(0.616)=0.216
此时,发现结点D的概率已足够高,使其进入所有的顶级两个结点,超过了结点C。因此在本阶段,构造菜单页A以包含指向B于D的链接,因此D从菜单B提升到菜单A;再一次B首先呈现,D第二。
应该注意在现阶段,进一步的规则可能确定实际上在菜单A中选择并向用户呈现那些结点。例如网络管理员可能不希望删除静态结点,因为害怕用户可能无法方法这些菜单选项。这被视为后处理任务,对个性化人员的操作无影响,因此在此处不成问题。
4.成熟用户
最后,看一看对成熟用户的情况,其中已经随时间发生了提升并且用户也对该提升作出了反应。图10示出以下情况:用户已经收益于D提升到菜单A,并且已经在该链接提升后位置上对其点击5次,如用户命中表所示。注意在图7至10中,用户命中表只是用户活动的记录—其不代表相关时间上实际的菜单结构。例如,在图10中,人们可能倾向将用户命中表解释为表示菜单页A具有三项,B、C于D。但情况并非如此。
计算图10的菜单A,得到以下A的子结点概率(注意现在D是A的可能的子结点):
P(B|A)=(20+17)/(40+25)=37/65=0.569
P(C|A)=(20+3)/(40+25)=23/65=0.353
P(D|A)=(0+5)/(40+25)=5/65=0.076
进一步扩展B,这是因为B是其概率超过目前所发现的最差的可接受概率(0.353,对C的概率)的唯一结点。
扩展B,计算其子结点相对于A的概率:
P(D|A)=P(D|B)×(P(B|A)+0.076
=(10+14)/(20+17)×(0.569)+0.076
=24/37(0.569)+0.076=0.444
P(E|A)=P(E|B)×(P(B|A)=(10+3)/(20+17)×(0.569)
=13/37(0.569)=0.199
此处应注意的重要事项是:在为D计算概率时,通过增加适当的概率,考虑了其相对于B(其静态父结点)的概率与相对于A(其提升后父结点)的概率。
一般地,当随时间提升或降低结点时,这些结点将在用户命中表中生成多个项,而在计算概率时,总是在一给定结点的多个先辈项上为其求概率和—先辈指只计算在菜单结构中比当前计算点更高的结点的项的概率的和。因此,当相对于A为D计算概率时(在A),不考虑相对于B的D的第二个项,这是因为其低于A。但当相对于A的计算D的概率时(在B),考虑两个概率。
于是目前所找到的最佳的两个概率为0.589于0.444,分别相应于结点B于D。再一次选择这些结点并根据其概率排序。
虽然前面只描述了一个非常简单的菜单结构,但本发明也适用于具有许多级别的菜单结构,并且随时间累积概率,页提升可以在许多级别上发生。通用的算法在附录A中。
按照目前的情况,上述算法缺省为拷贝提升—将结点D从菜单B提升到菜单A并不意味着用户如果选择C就不能在B中看到D。
考虑图10所描述的例子,其中菜单A显示具有指向D于B的链接。现在假设用户选择菜单B(D原来的父结点)。在移动提升方案中,即使D在来自B的顶级k个结点中,其也不应被显示,这是因为其已经被用户在先辈菜单中看到(在本例中为父辈菜单,但也很可能是祖父辈菜单等等)。在本方案中,D会被重复为B的子结点。
如果确实希望实现移动提升方案,则需要两个基于逐会话的新表,以跟踪在该会话中的提升与降低。一个表管理父-子关系(为用户命中表的简单一些的版本)。另一表捕捉反向的子-父关系。在每一会话中,根据为每一个性化菜单所选择的结点,建立这些表。
再次考虑图10的例子,并假设用户刚刚访问了具有其两个链接B与D的菜单A。用户当前的子-父与父-子表将包含如图11所示的信息。
现在,当进行到建立菜单B时,通过跟随子-父表中的子-父关系,然后在父-子表中在每一级别上检查子结点,以递归地回退菜单树,从而可以检测给定结点n是否已经被用户在先辈菜单中看到。
例如,首先跟随B的父结点(如果有多个父结点,可以将其排列,使最近的父结点在父-子被列于第一)。然后检查n是否为该父结点的子结点的一员(通过使用父-子表)。已知即使指数级的大型菜单树也只有线性深度,所以这一运算花费很少,尤其是因为单一的用户会话可能集中于菜单结构的一小部分。
可能对上面的实施例作各种修改与完善。例如,可能指定只要一页的概率超过某阈值,如0.4,则提升此页,即使根据概率计算此页在顶级k页之中。
还可能为结点提供敏感度属性。结点的敏感度指示该结点对个性化的敏感程度。低敏感度值意味着该结点对个性化相对不敏感,因此移动得缓慢。相反对具有高敏感度值的结点也一样。在实践中,通过当选择给定结点时使用敏感度值作为增量来控制这一点。例如,如果结点的敏感度为3,则每次选择该结点时,将在命中表中适当的项上将该结点的当前值加3。这种方案的复杂之处在于:父结点的命中值有可能不再是其子结点的命中值之和(如果子结点的敏感度不同于父结点)。由于这一原因,使用一简单的正则化过程,以确保子结点的命中值之和等于父结点的命中值。简单而言,根据实际的子结点命中值的比例,将父结点的命中值散布到子结点之中。在本质上,敏感度是对结点概率加权的途径。
概括而言,本发明的实施例包括一应用,其使用户能够快速地开发并部署个性化的信息服务—即基于用户在线行为模式自动修改以适应单个用户的需求的信息服务。所构造的门户能够完全修改以适应各个在线用户的导航偏好,并能够最终向这些用户传送更有效率、更令人愉快的移动体验。该实施例使用户受益于到其偏好内容的更短的“点击距离”。
该实施例通过以下途径来提供这些好处:使WAP门户能够动态修改以适应单个用户的访问模式,以主动地预测该用户的可能的(以及共同的)信息需求,并因此将信息目标提升到WAP门户菜单结构中更容易访问的位置。
现在参照图12,为本发明的第二实施例,其保留了上述第一实施例的个性化功能,但增加了进一步的功能,该功能基于以下所称的相似推荐技术。为简便计,在图12中,菜单服务器12的视图中略去了定制引擎16,同样也略去了菜单管理器10、浏览客户端20与定制客户端24。然而,所有这些都具备,并如上述操作。与第一实施例相比,图12中的实施例包括相似推荐引擎40,其操作如下。
在相似推荐技术中,如果两个菜单选项都从同一组用户得到许多点击,则认为这两个菜单选项互相相当。此处的思路是:如果同一组用户对两个菜单选项都感兴趣,则有很高概率这些菜单选项可能以类似方式与单个用户相关。这不同于现有的协同过滤技术,即相似推荐技术融入了菜单选项间的相似程度,而这些菜单选项未必在概念上类似。例如,相似推荐技术可能认定在技术新闻菜单选项与电视节目表间存在很高相似度,即使在二者所引入的内容间没有直接的相似。该相似度值意味着查看技术新闻的一组用户也会查看电视节目表,所以这些用户对两个话题具有类似的兴趣。
相似推荐引擎20的运行基于用户导航模式。实质上,此导航发生在移动门户中的菜单选项之间,并且用户的导航模式被用来将菜单选项聚集在一起。
相似推荐技术的第一步为:查看用户在每一菜单选项上都点击了什么。这是通过以下实现的:首先穿过用户命中表,并建立以菜单选项为键值的反转索引。这些菜单选项的每一个都有相关联的特征集列表,其包括这些菜单选项以及它们被特征集的所有人所点击的次数。随着用户数目的增加,将该反转索引保存在内存中就变得不可行了。因此该反转索引中的每一项都存储在一个分离的文件中。对每一菜单选项创建一个文件,文件中的每一行都包含特征集的名称以及该菜单选项被该特征集所有人所点击的次数。
例如,对菜单选项M1的文件包括图13所示的数据,其意思是User1点击M110次,User6点击M1 50次,等等。为降低这些文件的数目与大小,可以使用以下阈值:
Hit threshold—当为诸如M1的菜单选项建立文件时,只包含那些对M1的点击值满足或超过该命中阈值的用户。该命中阈值为预定的数,表示在用户的特征集被认为对计算菜单选项的相似值有用之前,该菜单选项必须从该用户得到的点击数目的下限。
User threshold—如果添加到与该菜单选项相关联的文件中的用户数目超过该用户阈值,则停止向该文件添加用户。这些文件可能一起被移除,以使其不参加相似推荐。移除这些文件的原因在于该菜单选项是非常通用的菜单,因此可能不会为相似推荐过程提供其他好处,这是因为该菜单选项在大多数用户的个性化菜单结构中已经很高了。
当更新反转索引文件时,只检查那些自上一次更新之后被访问过的用户特征集中的命中表。如果没有访问过这些特征集,则不改变这些特征集中与命中表相关联的点击数目。结果,这些特征集不影响正在被更新的文件。
为了推荐与其他菜单选项类似的菜单选项,需要一种用于计算菜单选项之间相似度的方法。这使用了特征集到菜单选项的关联。考虑图14中两个菜单选项M1与M2之间的相似度。M1已经被User1、User3、User5、User10与User11点击,M2已经被User1、User4、User5、User11与User20点击。为计算M1与M2之间的相似度,只需要考虑已经将两个都点击的用户(即User1、User5与User11)给予每一菜单选项的命中数目。
使用皮尔森相关系数,可以计算M1与M2间的相似度,其返回在-1与+1间的值。此值越高则菜单越相似,反之亦然。下面的例子显示M1与M2间相似度的计算。结果相似度为0.266,表示菜单不很相似。
皮尔森相关系数:
如果考虑以上例子,则计算相似度如下。等式中X的值设定为与菜单选项M1相关联的值,Y的值设定为与菜单选项M2相关联的值,如图15。
一步步计算:
∑XY=(10×5)+(20×16)+(15×45)=1045
∑X=10+20+15=45
∑Y=5+16+45=66
∑X2=100+400+225=725
∑Y2=25+256+2025=2306
(∑X)2=2025
(∑Y)2=4356
N=3
相似度=0.266
当计算菜单选项之间的相似度时,需要“重叠阈值”。该阈值表示在可以使用皮尔森相关系数(或其他相似度技术)衡量菜单选项之间相似度之前,需要在两个菜单选项上都点击的用户的最小数目。小于该阈值的任何数表示菜单选项可能不相似,这是因为没有什么用户两个菜单选项都选择。
在上述例子中,使用了皮尔森相关系数来计算相似度。然而,这只是计算相似度的一种可能技术。可以使用任何有清晰定义的相似性度量来衡量采单选项之间的相似度。
相似推荐引擎40构造相似度文件,其被用来保存菜单选项之间的关系(即相似度)。对每一菜单选项都有一相似度文件,其包含了其他菜单选项以及这些选项与该相似度文件所有者之间关系的列表。例如,对M1的相似度文件的内容也许类似图16,其表示M1与M2具有相似度0.266,等等。
与索引文件相同,可以用各种方法限制相似度文件的大小:
1.Partners—只考虑将菜单选项的伙伴包含进该相似度文件。存在许多方法用来挑选特定菜单选项的伙伴。例如,参看图17,菜单选项B的伙伴可以是:
该菜单选项的后代(D,E,H,I)。
菜单结构中的所有结点,除去该菜单选项的后代(D,E,H,I)。
该菜单选项的兄弟(c)与后代(D,E,H,I)。
所有为非该菜单选项后代的叶子结点(即指向外部内容供应者)的菜单选项(F,J,K)。这将确保只有来自菜单结构其他区域的叶子结点才可以被与该菜单选项一道推荐。推荐这些是因为用户可能以前还未看到这些菜单选项,但它们可能让人感兴趣,并且还因为其与用户当前菜单选项的相似性。
在菜单结构中所有其他菜单选项。
在菜单结构中结点的任意组合。
在前面,伙伴所选自的菜单结构当然是用户的缺省菜单结构,这是因为个性化菜单只有当用户点击它时才动态构建。然而,相似推荐技术并不倚赖于相对第一实施例所描述的个性化技术,并且可以独立于该个性化技术地使用,而在这种情况下,定义伙伴所来自的菜单结构就是站点的菜单结构。
2.Affinity threshold—只包含具有超过特定阈值,即相似度阈值,的相似度值的菜单选项。这样作的原因在于确保只可能与菜单选项一道推荐与该选项足够相似的菜单选项。
相似推荐可以与任何菜单结构结合,以提供个性化推荐。对任意菜单选项,都有可能推荐足够相似(即超过所指定的相似度阈值)的任何其他菜单选项。如在当前实施例中,当将相似推荐与使用概率模型所构建的菜单选项相结合时,最简单的办法是(基于概率模型)构建个性化菜单,然后包括分离的个性化相似推荐列表,如图18所示,其中M=基于概率模型的菜单选项,A=相似推荐。
站点管理员可以预先设定推荐数目。为了产生个性化相似推荐列表,确定相似源。该相似源为菜单的菜单或列表,其用于产生相似推荐。还使用相似推荐分数,其代表菜单选项作为相似推荐出现的可能性。该分数可能只是于该菜单选项相关联的相似值,或者可能是概率与相似值的某种组合。以下描述了多种技术,用来选择相似推荐以出现在所选择的菜单页上。
考虑菜单页M,具有三个菜单选项M1、M2、M3。任务是产生k个相似推荐的列表,以出现在M上。以下描述了多种技术,可用来选择相似推荐。注意:方法A与B将相似值用作相似推荐分数。
A.将M用作相似源。
最简单的办法是将M用作相似推荐的源。对菜单页M的相似关系的列表以相似值的降序排列,并将与顶部k个关系相关联的菜单选项用作相似推荐。
B.将M1、M2与M3用作相似源。
在这种方法中,对M1、M2与M3的相似关系被结合。然后将该关系结合按相似值排序,并将顶部k’选为相似推荐。
并集(Affinity(M1,M2,M3)={A1 M1.....Ak M1,A1 M2.....Ak M2,A1 M3.....Ak M3},其中A1 M1为具有对M1的最高近似关系,诸如此类。
相似推荐=上述集合中具有最高相似值的顶部k个菜单选项。
C.将M1、M2与M3用作相似源,但改变相似推荐分数。
该方法类似(B),但该方法在选择k个最佳相似推荐时,融入了来自相似源的概率信息。对与M1、M2与M3相关联的顶部k个相似关系中的每一个,使用下列等式计算相似推荐分数:
Score(A1 M1)=Probability(M1)*Affinity(A1 M1,M1)
其中Probability(M1)为M1出现在菜单页M上的概率(基于概率模型)。Affinity(A1 M1,M1)为M1与相似推荐A1 M1之间的相似关系(即相似度)。
然后将可能的相似关系按相似分数的降序排列,并将顶部k个作为相似推荐。注意:在上面等式中,分数基于概率与相似值的积。可能使用其他组合以计算分数。
D.使用M1、M2与M3的各种组合。
在上面B与C中描述的技术可以用于M1、M2与M3的各种组合,例如:
那些来自M1到M3的为缺省菜单页M的部分的菜单选项。
那些来自M1到M3的不是缺省菜单页M的部分但已经使用概率模型被提升到菜单页M的菜单选项。
那些来自M1到M3的不是动态菜单页M的部分但已经被用户定制到菜单页M的菜单选项。
注意:使用方法A或将缺省菜单用作相似源所选择的相似推荐对所有用户都相同。然而,采用所描述的其他技术,出现在特定菜单页M上的相似推荐被个性化,因此选择为推荐的菜单选项可能人人不同。
因此,最终结果为个性化菜单42,图12,包含由概率计算所产生的个性化菜单结构44,并还包括相似推荐46。
本发明并不局限于此处描述的实施例,这些实施例可能在不脱离本发明的范围的前提下作各种修改或变动。
附录A
Personalize(userSession,parentNode,k)
{
expand=true
staticChildren=the static children of the parentNode
clickedChildren=nodes clicked by user from this parentNode
If(clickedChildren is empty)
possibleNodes=staticChildren
else
possibleNodes=clickedChildren+staticChildren
possibleNodes=possibieNodes-nodes hidden by user
possibleNodeS=possible Nodes-nodes customised by user to a different level
if(project implements move promote)
possibleNodes=possible Nodes-nodes promoted to a different level
compute probabilities of possibleNodes
sort possibleNodes in descending order of probability
while(expand is true){
expand=false
kBestNodes=the k nodes in possibleNodes with highest probability
kthMostProbableNode=kth most probable node in the possibleNodes
kthProbabilltyValue=the probability of the kthMostProbableNode
For each of the kBestNodes{
If(expand Is false){
currentNode=hext node In kBestNodes
If(node has not being expanded before and node is a menu node){
staticChildren=the static chIldren of currentNode
clickedChildren=nodes clicked by user from currentNode
If(clickedChlldren is empty)
possibleNodes=possibleNodes E staticChIldren
else
possibleNodes=possibleNodes E(clickedChildren E staticChildren
If(project implements move promote)
possibleNodes=possibleNodes-nodes promoted to a different level
possibleNodes=possibleNodes-nodes hidden by user
possibleNodes=possibleNodes-nodes customised by user to a different parent
compute probabilies of possibleNodes
sort possibleNodes in descending order of probability
expand=true
}
}
}
}
}