销售昨天看过一条办公室搬迁需求今天又在“新线索”里看到它。如果对方已经暂停搬迁第二次出现带来的只是一次重复阅读如果需求范围变了沿用昨天的沟通准备还可能问错问题。星河卓越旗下意客AI根据业务描述寻找匹配需求将需求原文和相关依据积累到销售线索库供销售继续开发客户。线索库越积越多产品就越需要回答一个具体问题哪些材料可以复用哪些判断必须重做本文结合意客AI的原文入库与匹配实现拆开同一来源的重复、内容变化和业务范围变化。关键在于复用已经取得的原文不把旧需求状态当成今天的新机会。方法图解同一页面更新后本轮匹配不回退到更容易命中的旧版本。同一页面为什么不能先做关键词过滤例如一家企业IT服务商要找办公室搬迁和网络调整需求确认的搜索表达包含“办公室 网络”。同一页面先后保存了两份原文原文观察保存的内容与搜索条件的关系较早一次办公室要搬到新楼层想找人调整网络包含“办公室”和“网络”较晚一次搬迁暂缓暂不找服务商了不再包含这组搜索词如果先筛出包含关键词的版本再从筛选结果里取最新一条较晚的内容会先被丢掉。系统最后选中较早的原文销售看到的仍是“正在找人调整网络”。意客AI的CandidatePoolMatchStore.match_task()把顺序反过来先为每个来源选择最新观察再对这份原文做文本过滤。查询中的顺序可以从两处看出来SELECTDISTINCTON(o.source_id)o.source_id,o.version_id,o.observation_id,o.observed_at,o.received_at,s.source_identity,v.content-- 原代码此处拼接原文库关联与账号条件ORDERBYo.source_id,o.observed_atDESC,o.received_atDESC,o.observation_idDESC这部分先生成latest集合外层查询随后才检查关键词、排除词并限制本轮返回量。前面的例子因此不会回退到旧版本。这里的“最新”是库中已保存的最新观察排序依据是观察时间、接收时间及观察ID。它不表示系统已经发现网页上所有后续变化也不能替代采购有效期。原文今天再次读到里面提到的项目仍可能是去年的。一份原文要分清来源、版本和观察把一次页面读取直接存成一个新客户线索库很快就会膨胀。意客AI在candidate_ingestion.py中分别保存这些关系保存对象解决的问题来源source_id本次读取是否来自已知的同一个来源内容版本version_id保存的内容是否出现了新的版本观察observation_id这一次何时读到材料、对应哪份内容候选candidate_id在当前业务画像与策略范围内销售处理的是哪条候选入库时代码先查来源身份再查该来源的内容版本存在的来源与版本继续使用原ID。一次新的观察有自己的记录不必因此创建一个新来源。这对销售线索统计很关键同一页面读了三次不应当直接被计成三个新客户原文改了服务地点也应保留变化而不是覆盖过去的材料后让同事失去比较依据。新研究可以复用候选内容变化则推进版本候选的复用还有业务范围。匹配代码按账号、业务画像版本、策略版本与来源一起查找候选实际使用的范围是scope(tenant,claims.user_id,task[profile_version_id],task[strategy_version_id],original[source_id])因此同一来源在同一业务范围内再次命中时可以延续已有candidate_id。它仍是一条可追溯的候选本轮匹配有新的match_id用来记录这次任务为什么带回它。如果保存的原文版本变化代码在合适的观察顺序下推进候选的revision并指向新版本。相同内容版本则保留当前候选观察绑定不为每次重复读取都创建新候选。业务画像或策略版本变了不能只沿用旧范围里的适配结论。例如IT服务商从北京扩展到天津或者停止承接服务器运维原文与新业务的关系就需要重新判断。材料值得保存不意味着以前的“适合我们”永远有效。这一机制处理的是来源身份与业务范围内的复用。不同网站转载了同一件事仍需要额外判断它们是否指向同一需求不能把这里的来源去重解释成跨平台语义重复全部消失。查询完成以后还要防一次并发变化还有一个不容易在正常演示里出现的问题匹配查询取得了版本A准备保存候选时采集端已经收到同一来源的版本B。如果只相信第一次查询结果本轮仍可能保存旧版本。match_task()会取得与入库端一致的来源事务锁在等待结束后再查一次最新观察。核心判断是cursor.execute(SELECT o.observation_id _POOL_FROM AND o.source_id%s ORDER BY o.observed_at DESC,o.received_at DESC, o.observation_id DESC LIMIT 1,(tenant,claims.user_id,original[source_id]))ifcursor.fetchone()!(original[observation_id],):continue最新观察与第一次选择不一致时这条旧选择不继续写入本轮候选。此处选择保守跳过不把等待锁之前取得的内容当作仍然最新。这比在界面里简单提示“数据已更新”更靠前它约束的是本次匹配究竟依据哪份原文后续解释和销售阅读才有一致的材料可以依赖。销售接手时仍要读最新原话版本筛选修正了顺序问题关键词筛选仍有自己的边界。假如最新原文写着“办公室网络已解决不再找人”它还包含两个关键词。没有相应排除条件时字符串匹配仍可能命中后续就需要根据最新原话继续评估需求状态。因此销售接手一条线索时先看当前原文再看它与自己业务的关系。对仍在寻找服务商的搬迁需求可以准备布线安排、设备沿用和实施时间的问题原文已经写明暂停就不继续使用昨天的开场草稿。意客AI线索库承担的是寻找和整理需求材料的工作让销售从具体问题开始开发客户。原文复用减少已经取得材料的重复整理版本与业务范围保留判断依据新的研究继续寻找与这项业务有关的需求。销售拿到的材料应该能解释“为什么这一条值得继续了解”而不是只展示又多了多少条记录。关于按周期继续寻找需求可接着阅读AI获客如何持续监控销售线索意客AI的周期任务设计。意客AI产品团队北京星河卓越科技有限公司
销售昨天看过一条办公室搬迁需求今天又在“新线索”里看到它。如果对方已经暂停搬迁第二次出现带来的只是一次重复阅读如果需求范围变了沿用昨天的沟通准备还可能问错问题。星河卓越旗下意客AI根据业务描述寻找匹配需求将需求原文和相关依据积累到销售线索库供销售继续开发客户。线索库越积越多产品就越需要回答一个具体问题哪些材料可以复用哪些判断必须重做本文结合意客AI的原文入库与匹配实现拆开同一来源的重复、内容变化和业务范围变化。关键在于复用已经取得的原文不把旧需求状态当成今天的新机会。方法图解同一页面更新后本轮匹配不回退到更容易命中的旧版本。同一页面为什么不能先做关键词过滤例如一家企业IT服务商要找办公室搬迁和网络调整需求确认的搜索表达包含“办公室 网络”。同一页面先后保存了两份原文原文观察保存的内容与搜索条件的关系较早一次办公室要搬到新楼层想找人调整网络包含“办公室”和“网络”较晚一次搬迁暂缓暂不找服务商了不再包含这组搜索词如果先筛出包含关键词的版本再从筛选结果里取最新一条较晚的内容会先被丢掉。系统最后选中较早的原文销售看到的仍是“正在找人调整网络”。意客AI的CandidatePoolMatchStore.match_task()把顺序反过来先为每个来源选择最新观察再对这份原文做文本过滤。查询中的顺序可以从两处看出来SELECTDISTINCTON(o.source_id)o.source_id,o.version_id,o.observation_id,o.observed_at,o.received_at,s.source_identity,v.content-- 原代码此处拼接原文库关联与账号条件ORDERBYo.source_id,o.observed_atDESC,o.received_atDESC,o.observation_idDESC这部分先生成latest集合外层查询随后才检查关键词、排除词并限制本轮返回量。前面的例子因此不会回退到旧版本。这里的“最新”是库中已保存的最新观察排序依据是观察时间、接收时间及观察ID。它不表示系统已经发现网页上所有后续变化也不能替代采购有效期。原文今天再次读到里面提到的项目仍可能是去年的。一份原文要分清来源、版本和观察把一次页面读取直接存成一个新客户线索库很快就会膨胀。意客AI在candidate_ingestion.py中分别保存这些关系保存对象解决的问题来源source_id本次读取是否来自已知的同一个来源内容版本version_id保存的内容是否出现了新的版本观察observation_id这一次何时读到材料、对应哪份内容候选candidate_id在当前业务画像与策略范围内销售处理的是哪条候选入库时代码先查来源身份再查该来源的内容版本存在的来源与版本继续使用原ID。一次新的观察有自己的记录不必因此创建一个新来源。这对销售线索统计很关键同一页面读了三次不应当直接被计成三个新客户原文改了服务地点也应保留变化而不是覆盖过去的材料后让同事失去比较依据。新研究可以复用候选内容变化则推进版本候选的复用还有业务范围。匹配代码按账号、业务画像版本、策略版本与来源一起查找候选实际使用的范围是scope(tenant,claims.user_id,task[profile_version_id],task[strategy_version_id],original[source_id])因此同一来源在同一业务范围内再次命中时可以延续已有candidate_id。它仍是一条可追溯的候选本轮匹配有新的match_id用来记录这次任务为什么带回它。如果保存的原文版本变化代码在合适的观察顺序下推进候选的revision并指向新版本。相同内容版本则保留当前候选观察绑定不为每次重复读取都创建新候选。业务画像或策略版本变了不能只沿用旧范围里的适配结论。例如IT服务商从北京扩展到天津或者停止承接服务器运维原文与新业务的关系就需要重新判断。材料值得保存不意味着以前的“适合我们”永远有效。这一机制处理的是来源身份与业务范围内的复用。不同网站转载了同一件事仍需要额外判断它们是否指向同一需求不能把这里的来源去重解释成跨平台语义重复全部消失。查询完成以后还要防一次并发变化还有一个不容易在正常演示里出现的问题匹配查询取得了版本A准备保存候选时采集端已经收到同一来源的版本B。如果只相信第一次查询结果本轮仍可能保存旧版本。match_task()会取得与入库端一致的来源事务锁在等待结束后再查一次最新观察。核心判断是cursor.execute(SELECT o.observation_id _POOL_FROM AND o.source_id%s ORDER BY o.observed_at DESC,o.received_at DESC, o.observation_id DESC LIMIT 1,(tenant,claims.user_id,original[source_id]))ifcursor.fetchone()!(original[observation_id],):continue最新观察与第一次选择不一致时这条旧选择不继续写入本轮候选。此处选择保守跳过不把等待锁之前取得的内容当作仍然最新。这比在界面里简单提示“数据已更新”更靠前它约束的是本次匹配究竟依据哪份原文后续解释和销售阅读才有一致的材料可以依赖。销售接手时仍要读最新原话版本筛选修正了顺序问题关键词筛选仍有自己的边界。假如最新原文写着“办公室网络已解决不再找人”它还包含两个关键词。没有相应排除条件时字符串匹配仍可能命中后续就需要根据最新原话继续评估需求状态。因此销售接手一条线索时先看当前原文再看它与自己业务的关系。对仍在寻找服务商的搬迁需求可以准备布线安排、设备沿用和实施时间的问题原文已经写明暂停就不继续使用昨天的开场草稿。意客AI线索库承担的是寻找和整理需求材料的工作让销售从具体问题开始开发客户。原文复用减少已经取得材料的重复整理版本与业务范围保留判断依据新的研究继续寻找与这项业务有关的需求。销售拿到的材料应该能解释“为什么这一条值得继续了解”而不是只展示又多了多少条记录。关于按周期继续寻找需求可接着阅读AI获客如何持续监控销售线索意客AI的周期任务设计。意客AI产品团队北京星河卓越科技有限公司
