我要投稿

AI Agent + 电商：应用与探索

发布日期：2024-07-11 12:55:32 浏览次数： 5761

作者：NewBeeNLP

微信搜一搜，关注“NewBeeNLP”

导读本文将分享 AIAgent 在电商平台中的探索。

主要内容包括：

1. LLM 在电商的价值位

2. Agent 解决方案

3. 应用架构介绍

4. AI 创新范式

5. 预期与规划

6. 问答环节

LLM 在电商的价值位

首先来介绍大模型所赋予电商领域的一些新特性，AI 在电商模式下的应用，以及 1688 对 AIAgent 的探索。

1. 大模型赋予的新特性

在电商领域，AI 技术的应用涉及众多场景。通过抽象，归纳出大模型的六大基础能力：生成、总结、提取、改写、分类和检索。这些能力共同构成了 AIAgent 在电商环境中解决各种问题的基石。电商中的核心问题在于实现从感知到决策，再到内容生成的完整流程，这一流程需要持续迭代和交互。我们希望通过大模型来解决这一根本性问题，从而推动电商领域的智能化发展。

2. 电商模式下的 AI 应用

在电商领域，用户的购物流程通常涉及寻找商品、挑选满足需求的产品、与商家进行询盘，以及完成付款和履约等步骤。这一流程构成了从用户视角出发的标准交互形态。在这一过程中，AI 技术的应用已经深入到导购、营销、询盘、商家工具和销售后台等多个环节，极大地提升了电商平台的运营效率。

本文的重点在于如何将这些 AI 应用整合为一个整体，实现数据与决策的交互。具体而言，通过精准捕捉用户需求画像，满足其多样化的需求类型，进而实现智能决策。这一整体概念旨在将现有的搜索推荐模式转变为未来用户深度交互的导购模式，使电商平台能够扮演智能导购的角色，引导用户更好地进行采购，并促进复购场景的形成。这是电商在 AIAgent 领域实现突破的重要前提。

3. 1688 的 AIAgent 探索

以 1688 为例，平台展现出了强烈的 B 类用户导向。B 类用户，如经营轻奢连衣裙的中年妇女品牌商家，在采购时，会面临很多条件性因素的考量，比如寻找一款热销且价格在一定范围内，商家评价又高的商品。这些长尾化和离散的数据在传统搜索方式下难以一次性满足其需求。传统的做法是通过不断尝试 query 词或基于 item to item、user to item 的推荐逻辑，但整个交互过程仍然依赖于数据统计决策。

我们的目标是将数据决策过程转化为基于逻辑推导的过程。这意味着，在用户明确需求后，通过预先设定的逻辑框架来精确匹配用户需求，而不是仅仅依赖于数据推荐。这一转变将深刻影响搜索引擎和推荐算法的交互方式，使得机器能够更深入地理解并满足 B 类用户的复杂需求。

在现实中，B 类用户的需求往往包含大量非结构化和差异化的元素，这使得简单的搜索或推荐方式难以实现深度匹配。我们理想中的解决方案是，平台能够像线下批发市场一样，充分了解并满足买家的各种需求，包括商品和服务的多样化要求。这一目标的实现，将极大地提升 B 类用户在电商平台的采购体验，并推动电商行业向更加个性化、智能化的方向发展。

Agent 解决方案

1. 基于 LLM 的应用模式

大模型在电商领域的应用展现出了其强大的潜力和广泛的标准定义。从在人做事的过程中融入大模型的生成能力，到能够在助手体系中实现人机深度交互，进而通过 Agent 执行体实现有效任务级的代理。这一概念不仅深化了我们对 Agent及 AI 交互的理解，也为我们提供了综合运用的模式。具体而言，这种模式允许我们在 Agent 内部结合多种算法，或在 copilot 中实现多任务并行处理。

在电商领域，大模型的应用首先解决了成本和规模问题，展现了其确定性和平台的投入价值。其次，大模型还能解决传统方法无法处理的问题，实现新的深度能力，进一步推动了电商领域的发展。与传统的大模型泛化应用不同，大模型在电商领域的应用更加专注于解决特定领域的深度问题，根据需求对模型进行训练和微调。展望未来，我们期待大模型与电商场景实现深度融合，打造 AI native 的深度交互场景，为用户带来更加自然、智能的购物体验。

2. LLM 应用的研发方式

模型应用的过程可以分为三个阶段。首先，当模型需要预训练时，其迭代周期与训练要求均属高标准，这一阶段依赖于基础设施和长期的研发积累。进入第二阶段，若涉及监督微调和业务评估模型，如 reward model 等体系，并辅以少量的强化学习（尽管该领域目前尚未成熟），则算法的深度介入变得至关重要。最后，当模型应用进入 prompt 的调试和整体数据效果优化阶段时，算法与工程均可灵活切入，共同推动模型性能的提升。

这三个阶段在投入量与产出效果上各有差异。我们期望模型能根据不同场景和问题类型进行适配。对于解题型任务，我们希望模型能更深入、更实用，因此会加大中间环节的投入。而若希望模型应用场景广泛，则更需依赖 prompt 的构造和基础模型的能力。这些经验来源于我们在模型开发过程中的实践与思考。

3. 模型能力的选择判断

1688 采用了通义千问-72B 模型，该模型在中文自然语言理解及相关评测任务上表现优异。该模型具备 32K 的上下文长度，同时其推理性能和部署策略均展现出显著优势。在实际应用中，该模型能够通过多种场景进行调试和优化，为业务开发提供了强大的支持。值得一提的是，相较于之前的 7B 和 14B 模型，72B 模型在任务执行能力上有了显著提升，使得许多原先难以完成的任务得以顺利解决。这一进步不仅证明了该模型的高效性，也为业界提供了参考性的经验。

4. Agent 模式电商例举

我们提出了一个体系设计，它旨在将当前较为狭义的系统助手模式逐步演进至 copilot 模式，并与现有产品功能实现融合。最终，我们期望达到一个 Agent 应用阶段，基于长会话能力，实现独立串联的对话场景。

在电商交互的领域中，我们探索了一种新型的 copilot 模式，这一模式在1688APP 中得到了具体实践。这一模式有效地解决了用户在进行商品比较时面临的困扰，例如当用户在购物车中选择多个商品进行比较时，传统方式往往会非常复杂。通过引入外部因素进行测评的方法虽然可行，但效率并不高。而 copilot 模式则能在用户界面中直接提供比较功能，使得用户可以方便地对两款产品进行快速比较。这种比较不仅限于价格或功能的对比，更可以涵盖产品的详细信息、用户评价等多个维度，为用户提供更为全面和准确的购物参考。这一模式的实现，正是基于大模型的基础能力，如信息提取、摘要生成等，为电商行业带来了新的用户体验和商业价值。

在商品选择的过程中，我们可以通过精准地捕捉用户对比选择的商品及其上下文，从而深入理解用户的偏好。针对用户所关注的两个商品，平台将全面分析并补充其价格因素和品质因素的相关信息。在现有的用户交互平台上，如淘宝等，用户往往需要频繁地在列表页和详情页之间切换，进行多次交互以补充商品参数、查看商品评价等，这无疑增加了用户的使用难度。然而，随着技术的不断发展，未来我们将通过更加直观、高效的方式，利用 Agent 模式，拆解并呈现用户所需的所有信息，从而极大地提升用户的购物体验。

在当前的商业环境中，特别是在 1688 这样的平台上，存在着大量的厂牌和产品。对于消费者而言，如何快速、准确地获取到厂家的位置、资质、产品信息以及品牌背书等信息至关重要。为了解决这一问题，我们构建了一个综合性的信息体系，旨在为消费者提供一个清晰、易于理解的查询途径。通过这一体系，消费者可以轻松获知厂牌的资质、位置等关键信息，以及品牌背后的实力背书，如婴幼儿产品所需的特定执照等。这一体系的建立，不仅提升了消费者的购物体验，也为商家提供了一个展示自身实力和信誉的平台。

5. Agent 模式电商的演进：从计划到自主

Agent 模式的演进包含了两个阶段，第一个阶段是 Plan-based Agent 模式，这一模式缺乏自治性链路，依赖于程序和数据的补充。第二阶段是 Auto Agent 模式，这一模式更为智能化，能够自动处理如出行计划等复杂任务，自动安排机票、酒店和行程等。在某些高级外部模型的支持下，Auto Agent 能够在 200B 基础上实现任务的自适应性。然而，从推理难度和应用场景的复杂度来看，我们目前仍处于第一种模式的阶段，主要依赖于工程设计来串联任务链路。这种方法目前可以在 72B 的基础上构建出相对完整的任务链路，如从提取商品特征到评价，并最终分析得出结论以提供给用户。

6. 模型能力与应用设计

在模型应用的过程中，存在一个标准的应用范式。当用户提出问题时，系统会首先进行意图判定，随后与外部知识库进行交互，如搜索引擎的文档重绘和知识结构的解析。此外，系统还会整合内部的核心电商数据，构建完整的交互结果并返回给用户。这一过程中，模型能力的提升至关重要，它决定了系统如何有效整合静态数据和动态数据，以提供更为精准和有效的结果。通过这种方式，系统能够在保留信息主体同时，提高结果的有效性和准确性。

7. Agent 实际开发应用挑战

在 Agent 的实际开发应用中，面临着多重挑战。首先，如何将定量转化为定性是一大难题，尤其是在提高模型更新后指令测评的有效性方面。这一过程中，虽然可以通过调整多个问题或在不同尺寸模型上进行尝试，但如何确保得到最佳结果仍充满偶然性和随机性。因此，需要借助工程手段来解决这一难题。

其次，prompt 编写的挑战也不容忽视。与传统的强约定、强类型、强规则性的代码编写不同，prompt 编写更侧重于自然语言描述和调试过程。这种转变使得从编写程序到期望结果的直线逻辑变得模糊，增加了工程不确定性和调试稳定性的挑战，需要更高的质量保障。

最后，效果的叠加与展示情况的不一致也是一大挑战。过去，我们往往通过成功案例来驱动产品形态的描绘和上限的评估。然而，在当前的模型实验效果评估中，我们更多地需要依赖中位线来判断该产品是否具备平台产品化的潜力。然而，即使在大多数用户满意的情况下，如果仍有部分用户体验效果极差，这将影响平台服务的提供。因此，如何定义和把握这一边界，确保产品能够满足大多数用户的需求，是我们在平台应用中必须面对和解决的问题。

具体来看 prompt 编写的问题。现在的 prompt 都是在固定模型下试出来的。如果模型大小和微调过程对模型有影响，那么 prompt 可能就不是稳定可以复用的。

Agent 结果的测评包括两部分，一是格式测评，相对简单，另一部分是内容测评，相对困难大很多，包括外包人力评估、用 GPT-4 评估，以及训练专用模型来评估。

Agent 应用架构介绍

1. Agent 架构总览

Agent 开发要有一个完整的平台，来解决算法运行时间、结果不确定性以及工程复用度等问题。其核心部分包括一个双层网关，第一层用于处理业务路由和缓存，确保与业务的高效关联；第二层则负责判断并分配适当的 Agent 以执行用户的具体操作。Agent 作为子任务的结果集，通过树状结构实现子任务的执行。此外，平台右侧设有 prompt，通过后台配置加速用户过程，并要求知识库标准化并具备向量化检索功能，以增强系统的实用性。底层则提供开发工具，帮助开发者更高效地应用于 Agent 体系，并构建完整的测评体系。这一测评体系不仅涵盖语料库的构建，还着重于算法有效性的评估以及线上数据的有效性验证，确保整个系统的高效性和准确性。整体而言，该平台通过整合这些工具和链路，构建了一个集数据、意图识别等核心能力于一体的智能系统。

2. Agent 交互流程

在运用这些技术时，核心在于如何将逻辑理解的用户需求转化为具体的描述，并借助程序化的方式实现持续迭代的交互。这构成了 1.0 版本的交互模式。具体而言，它涉及从买卖双方的数据中提取信息，结合买家的用户意图和画像特性，在特定上下文中为用户推荐相关产品。同时，这一交互模式还涵盖了对用户下一次可能提出的问题和疑问的预测与构造，从而实现一个单次但完整的交互循环。

3. Agent 交互流程

实现高效的交互循环，首先需要一个完备的知识库作为支撑。知识库融合了众多异构数据源，包括内部和外部数据，确保模型在静态之外也能获取到最新信息。为了处理这些具有时效性的数据，我们引入了外部引擎，如通过 API 调用夸克等服务。内部数据则通过不断提取、文档化、检索和应用的过程，实现知识的有效管理。

考虑到数据的复杂性和多样性，我们采取了离线预处理的方法，确保数据在接入时就已经经过了清洗和整合。同时，我们关注在线数据的实时性和有效性，通过两级缓存策略优化检索链路和合并性能。首先，在应用层实现 KV 缓存，提供快速的数据访问；其次，在平台层面实现向量召回，确保复杂查询的高效处理。

整体而言，这一知识库链路的构建，不仅为交互循环提供了坚实的基础，也确保了数据的高效处理和应用，从而支持了复杂交互场景的实现。

4. Agent 多轮交互

在处理多轮交互时，与单轮交互相比存在显著差异。以寻找婴儿睡袋为例，首轮交互可以通过平台内的商品信息检索和用户意图识别来实现。然而，当进入第二轮，即用户需要挑选具体商品时，由于电商平台内可能缺乏完整的挑选知识，比如如何选购婴儿睡袋，此时就需要借助外部信息。通过外部知识召回的方式，引入外部资源，如某书上的用户笔记或知乎上的相关说明，以丰富挑选的知识基础。在第三轮，即推荐品牌时，需要整合站内的品牌信息和站外对该行业的认知，进行深度内容融合，最终给出推荐结果。在多轮交互中有效结合内部与外部信息，为用户提供精准和全面的服务。

5. Agent 部署架构

在交互设计之后，部署环节的重要性不容忽视。部署不仅关乎产品在线上应用的稳定性，更体现了其架构与原生架构的显著差异。当前，如 PaaS、SaaS 等多层次架构体系广泛应用，其最底层聚焦于资源的高效调动。在阿里集团等大型企业中，资源调动的关键在于确保虚拟化实例的确定性，使线上推理能够灵活伸缩。

对于大模型而言，其 QPS 与传统应用存在显著差异。传统应用可能依赖单一服务器处理数百或数千的查询，而大模型则对显卡资源有着更高的依赖，且难以实现基于 CPU 模式的高并发和时间分片。因此，资源的调度需围绕显卡资源的动态调度展开，确保资源的有效利用。

在架构的上层，服务的热更新、流量预测和管理等任务也提出了新的挑战。与传统的离线化或基于轻量级模型推理的应用方式相比，当应用达到一定规模后，这些架构都必须进行全新的升级和改造，以适应大模型的需求。这一过程不仅需要技术的创新，更需要对于整体架构的深入理解和优化。

6. Agent 推理优化

在探讨推理技术的优化时，首先要关注的是用户交互的流畅性和安全性。传统的交互模式在响应速度上存在挑战，如 GPT 等系统，在处理大约 1000 字的输出时，其返回时间通常介于 5 秒至 8 秒之间。为了提高响应速度，我们采取了多层次的加速策略。首先，全域加速通过优化扩大模型来减少处理时间；其次，在部署平台上进行全局性能优化，并构建全局缓存结构。此外，我们还针对特定应用场景进行应用域内的优化，如上下文缓存和 prompt 缓存，这些优化能够显著提升系统层面的性能。

在实际部署中，我们采用了针对 72B 模型的应用部署策略，在 L40S 相对低成本高显存的特性下，可相对充裕的部署推理卡资源。同时能够确保在线上的良好性能和水平扩展性，结合技术优化和部署策略，显著提升了推理系统的效率和用户体验。

7. Agent 质量保障

在当前的科技背景下，质量风险的控制与传统模式有所不同，特别是在涉及模型输出的质量方面。传统的自动化测试在覆盖度和程序执行上较为直接，但当前的挑战在于如何确保模型的稳定性和可靠性。首先，我们需要确保模型在全域领域内能够产生符合用户交互需求的测试用例，这通常涉及从线上大量数据中抽取样本。其次，保证模型的巡检和稳定性也至关重要，要能够准确地识别出用户反馈中真实存在的问题，而不仅仅是用户投诉中的 5% 至 10% 的显著性问题。此外，测评过程需结合主观与客观评价，确保结果的有效性。

8. Agent 质量测评

在实际应用中，我们经常会遇到这样的情况：在比较两个商品时，模型将某个商品置于首位，可能会增加该商品获得好评的概率。这种现象要求我们具备强大的模型边界定义能力，以准确判断哪些情况是错误的。为了达到这一目的，测试质量在后期起着关键作用，它能够帮助我们确定模型的用例和质量评分。

测试构造的过程通常从创建测试语料开始，这涉及使用 AI 工具和远程数据模型进行对比分析。同时，人工评测的重要性不容忽视，尽管我们期望减少人工干预以提高规模化和应用的稳定性，但在当前阶段，基于模型的客观与人工对比打分仍然是必要的步骤。这一过程将持续进行，直到我们能够得出可靠的质量报告，为模型的优化和归因提供有力支持。

AI 创新范式

1. 产品驱动模式

随着 AI 技术的不断发展，其创新的边界正在被重新定义，对产品驱动模式、研发流程以及技术趋势产生了深远影响。传统的电商业务目标通常基于运营策略构建产品方案，随后通过算法进行决策和运筹，再到工程层面进行数据交互和渲染。然而，在大模型时代，这一流程发生了显著变化。

首先，模型能力成为决定产品方案的关键因素。懂得模型能力边界和应用模型的人员不再局限在传统产品团队，而可能来自技术团队或技术产品背景。他们可基于不断验证模型或应用效果来构建产品设想，并评估模型应用能否实现可规模化。这一过程对于创新产品方案的迭代至关重要。

其次，智能化定义的边界变得模糊化。为了提供更好的用户体验，如帮助用户找到更好的产品，不再仅仅依赖于现有产品体系的迭代和研发团队的跟进。相反，需要跳出传统框架，探索新的模型带来的产品交互变化。

另外，工程能力也需要进行补全。随着算法调试和模型调整成为主要工作，数据处理能力变得尤为重要。工程师需要具备更强的算法应用能力，以确保后续研究和研发工作的顺利进行。同时，工程团队还需要完成基础设施建设，以降低模型调整的成本，并缩短上线验证的周期。

总体来看，AI 技术的发展带来了研发模式的变革。模型能力、新产品边界和工程能力成为影响产品开发和应用的关键因素。为适应这一变化，团队构造和研发流程需要相应调整，以更好地利用 AI 技术的潜力。

2. 研发流程 SOP

在 AI 研发中，研发的流程正经历着显著的变化。新的研发模式强调运维态的平台化能力，利用开源或面向大规模服务的平台，实现模型的调度和应用配置的简化，减少开发运维投入。同时，开发态和观察态的反复迭代成为常态，通过不断补充数据和微调模型，以追求更好的应用效果。这种从开发态到观察态的持续切换，体现了敏捷迭代的重要性。为了支持这一过程，整个平台需要同时考虑纵向的敏捷迭代和横向的基础建设。这意味着需要一支专注于基础建设的团队，解决工程应用问题，同时需要懂业务和数据工程的团队来推动上层应用的优化。通过这种不断迭代的方式，可以持续提高 Agent 的应用场景效果，并基于用户反馈和使用率的数据，不断提升系统的整体性能。

3. 技术趋势影响

在新技术趋势的背景下，特别是 AIGC 的崛起，企业面临的挑战和机遇并存。尽管 AIGC 展现出对各行各业的潜在重构能力，但在实际应用中，企业首先关注的是模型尺寸评测和推理上下文能力。以电商为例，其复杂的上下文，如用户场景、商品特性、行业知识、买家意图和人群画像等，对模型提出了极高的要求。因此，清晰定义模型应用能力的边界至关重要。

在平台化建设方面，随着模型基座与应用工具的交互，产生了大量信息。为解构问题，企业可借鉴跨团队合作的开发项目和可复用的数据建设体系，早期阶段不必过于追求平台的完整性，而应专注于平台能解决的实际问题。

在团队角色方面，不同 Agent 承载着不同的职责。例如，LM（语言模型）需要深入理解模型能力和应用场景分析，这需要领域专家的设计和标注。而在图像领域，则需要团队不断创新，以满足用户多样化的需求。

最终，企业需聚焦于为用户提供更新颖的产品和更强大的问题解决能力，这是新技术趋势下的核心目标。

规划与预期

最后分享一下对未来工作的规划和预期。

1. 1688 未来 AI 化的规划

在未来的规划中，我们将探索 AI 在消费电商和产业化领域的广泛应用。首先，关注视频技术和数字人讲解等应用场景，这些技术不仅需要强大的模型能力，还消耗大量显卡资源。然而，若能实现泛化应用，它们将极大地提升供给侧的构建效率，为电商带来大量用户交互体验的改善。我们期待这些技术能与电商的搜索和推荐系统相结合，打造全新的用户产品平台。

在供应链方面，我们致力于将平台上的非结构化信息转化为结构化数据，以实现更高效的商品定制和供应链管理。例如，通过文本描述，用户可以轻松定制商品，而商家则能更便捷地提供个性化服务。此外，我们还计划通过 AI 技术提高供应链的渗透能力，实现与 ERP 系统的高效对接，减少信息转化和集成的时间及人力成本。

更进一步，我们将探索如何通过 AI 技术编排供应链的任务流和上下流，构建一个集成生态系统，连接平台与业务，以及工业品等源头产业链。这一规划不仅将提升供应链的效率，还将为整个电商生态带来更大的想象空间。

2. 一些感悟

在 AI 向产业渗透的过程中，电商作为一个典型的赛道，其技术发展遵循着特定的生命周期。在这一赛道中，技术的推进往往遭遇挑战与瓶颈，投入与产出的比例时常波动。对于 AIAgent 的应用，其核心在于 LM 的泛化应用，旨在解决非结构化到结构化匹配之间的连接问题。然而，其输出结果具有自带的偶然性和随机性，这要求我们在推广时不仅要展示成功案例，更要关注其普遍适用性和稳定性。

目前，业界对于电商领域 AIAgent 的探索和应用正不断深入，如京东的豆包、淘宝的问问等，均致力于提升用户满意度和交互体验。这些努力的目标，是希望从现有的搜推模式，进化到更为智能、更为用户友好的交互方式，从而推动电商行业的进一步发展。

问答环节

Q1：怎么理解 Agent 的概念，它和 RPA 在业务上的差别在哪里？

A1：在探讨 AIAgent 的功能时，其最终理想表现为能够自动解析并执行各类任务。以订票为例，当用户提出需求时，Agent 通过内置的模型迅速理解其意图，并自动将需求转化为具体的任务流，如查询航班、选择座位、支付购票等。这一过程无需人工干预，完全由 Agent 自主完成，实现了从任务接收到任务完成的自动化流程，即所谓的 Auto Agent 模式。这种模式的实现，不仅极大提升了工作效率，也为用户带来了更加便捷、智能的体验。

RPA 是一种基于任务流编排的自动化流程。这种编排允许用户设定一系列的操作或功能，形成固定的流程。然而，当面对如法律文件分析这类需要高度准确性和专业性的任务时，固定的流程可能显得不够灵活。这种 Auto Agent 模式，虽然流程被精心设计和编排，但在面对变化或错误时，其修正能力有限。

我们团队近期研究了一种新的解决方案，该方案能够动态地分析商品和人群特征，并基于后台模型进行自动判断和分支决策。这一方法展现了 Auto Agent 的潜力，能够自适应地应对不同场景。然而，我们也认识到，在复杂的决策链中，一旦某个环节出现错误，修正的难度将显著增加。因此，如何确保系统的准确性和鲁棒性，仍是我们需要深入探索的问题。

Q2：在微调大模型的时候，这怎么避免在自己的垂直领域的数据集上过拟合？

A2：在探讨微调模型时，我们首先经历了一个 SFT 过程，并随后运用 reward model 进行修正。然而，值得注意的是，尽管国内文献中普遍提及重新进行强化学习，但在实际社区中，强化学习的线上应用效果并不理想。这提示我们，在采用此类方法时需谨慎评估其适用性。

此外，当考虑通过 SFT 方法提升模型效果时，存在一个显著的问题：一旦模型底座的尺寸发生变化，之前的微调可能失效，甚至需要全部重调。为了避免这种资源的浪费，建议在进行微调时尽量考虑全尺寸调整，并充分投入资源。仅通过降低维度进行微调虽然可能部分满足需求，但长期来看，这种策略在数据集或模型尺寸发生变化时，其效果将大打折扣。

基于我们的经验，将模型降低维度以进行过拟合的策略，在实际应用中效果并不理想。这种方法往往只能在非常狭窄的范围内取得较好的效果，且推理速度虽快，但泛化能力有限。因此，在进行模型调整时，我们需要更加全面和谨慎地考虑各种因素，以确保调整的有效性和可持续性。

Q3：搜推场景下，使用大模型的性能如何，有没有考虑用小点的模型？

A3：在搜推场景中，传统的倒排索引结构以其高效性而著称，其推荐和搜索的响应速度通常在几十毫秒内完成，远超过大模型推理的实时性。为了克服这一挑战，我们提出了结合传统搜推技术与大模型推理的方案。具体而言，我们首先利用大模型推理出推荐逻辑，然后利用这些逻辑在搜索结果中进行召回，并在召回后进行大模型推理的重排。然而，这种方法在实时性要求极高的一级入口场景中并不适用，因为尽管它能提供更精准的推荐逻辑，但性能上的限制使其难以满足实时需求。

此外，用户对于搜推场景的期望和习惯也是我们需要考虑的重要因素。用户往往更习惯于传统的搜推方式，其高效性和直观性深受用户喜爱。因此，尽管交互式场景可以作为一种补充，但完全替代传统搜推方式并不现实。然而，在某些特定场景下，如用户需要深入了解某类产品或服务时，大模型推理可以发挥其优势，通过改写搜索词、重构用户长尾需求等方式，提供更精准的搜索结果。

结合传统搜推技术与大模型推理是一种可行的方案，但需要根据具体场景和用户需求进行权衡和选择。在追求精准性的同时，我们也应充分考虑实时性和用户体验，以提供更为优质的搜索和推荐服务。

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业