LLM面对复杂业务如何划分和组织任务

背景

在LLM时代，大模型的zero shot和few shot能力来源于大量知识的压缩在知识空间模型对知识做了上层抽象。对于我们具体的任务执行则是一个逆向的过程如何把抽象的知识概念具像化到实际业务，让模型可以服务于业务。在这个过程中就存在概念对齐和知识激活两个过程。对于概念对齐主要做法就是SFT+RLHF来实现业务私域指令和通用知识概念和范式对齐，RLHF更多是在做非对错而是选择观点站队问题；当然现在也有很多私域会做知识增量二次预训练。
对于知识激活，就是模型已经做到了私域对齐已经有比较好的抽象到具象能力前提下；该如何根据实际私域差异化任务把细分知识激活正确表述，讲更直白就是让模型更可控。
往前大部分算法人员关注的是二次预训练增加模型私域能力或者是做指令对齐把抽象层概念、范式对齐，亦或是做“观点站队”解决模型安全问题。这一方面是因为这几个方向是个更难的问题，也是在前一个阶段更有价值的事情。然而随着模型知识概念和范式越来越强，模型能力越来越强；模型的用好问题就成为当务之急。用好模型也就是如何把模型知识激活具像到实际业务过程问题；在这个过程中衡量模型是否具备完成任务的能力、如具备能力该如何有条理系统的优化描述让模型能力尽可能接近上限、模型如不具备该能力该如何对任务划分，分成更小任务分阶段让模型可以很好胜任工作就成为很必要去研究的话题。
这篇文章尝试用案例的方式来尽可能结构化这两个问题；因为这些问题在也是伴随LLM才出现，以前NLP问题并不是如此划分和认识问题，所以目前看来本没有什么理论体系可以直接拿来即用，只能从零碎描述中尽可能的抽象出一些体系。

如何探测LLM模型能力是不是够

验证模型是否满足条件
我们现在要根据输入生成一份java代码，那么我们要如何测试模型是否具备足够能力呢。我们刚开始应该尽可能简单的把需要做的事情表述清楚输入给模型即可。
下面列出几个第一轮测试模型能力的规则：
1.简单表述任务
2.简单交代背景
3.简单描述约束
4.简单描述或者不描述业务背景上下文
第一次测试着吗做的目的就是要测试下模型在尽可能少的条件下对事情认知背景有多少，也就是试探下它的知识模式有多厉害，没给你背景知识情况下你对这个事情认知推测下模型对这类任务具备的背景知识。

目前我们在编写一个产品目录服务，
通过API提供所有可售商品的详细信息。
此API不能修改或增加可售商品。使用Java编写。
请提供代码和所有功能的功能测试。

根据上面的任务描述，LLM会生成一段代码，如下：

对于您的需求，我将为您提供一个基本的Java API示例，用于读取产品目录。由于您没有提供具体的数据库或数据源，我将使用一个简单的内存数据结构来存储产品信息。
以下是代码示例：
import java.util.ArrayList;
import java.util.List;

public class ProductCatalogService {
    private List<Product> products;

    public ProductCatalogService() {
        products = new ArrayList<>();
        // 初始化一些产品
        products.add(new Product("Product 1", "Description 1", 10.0));
        products.add(new Product("Product 2", "Description 2", 20.0));
        products.add(new Product("Product 3", "Description 3", 30.0));
    }

    public List<Product> getAllProducts() {
        return products;
    }

    public Product getProductById(int id) {
        for (Product product : products) {
            ...
        }
        return null;
    }

    public static class Product {
        private int id;
        private String name;
        private String description;
        private double price;

        public Product(String name, String description, double price) {
            ...
        }

        ...

        private static int generateId() {
            // 简单的ID生成器，用于演示目的
            ...
        }
    }
}
现在，让我们编写一些功能测试来验证API的行为：
import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;

public class ProductCatalogServiceTest {
    private ProductCatalogService service = new ProductCatalogService();

    @Test
    public void testGetAllProducts() {
        ...
    }

    @Test
    public void testGetProductById() {
        ...
    }
}
请注意，这只是一个基本的示例，用于演示如何使用Java编写一个简单的产品目录API。在实际应用中，您可能需要考虑更多的因素，如数据库集成、安全性、错误处理等。

很显然模型应该是有任务理解能力：知道提供代码和测试、知道和商品相关，并且具备代码生成需要的能力。然而生成代码是很通用的模版似乎并没有真正理解我们的业务意图。如果我们通过上面生成代码并不能很好理解模型是如何生成这些代码的，所以为了更清晰的知道模型具备什么能力，我们可以让模型来描述下如果我要做这么一任务它需要关注什么。

验证模型对于这个任务下界

通过前面的能力验证环节我们已经大致知道模型具备了完成我们任务的能力：任务意图理解：拆成两部分代码生成、测试代码生成；代码生成能力、有基本商品java结构。但是上个环节最后部分我们也讲了，如果这样我们没法更清晰的定位到模型是如何生成这些代码，要如何提升完成任务准确性。所以我们需要把代码生成任务转成中间任务，完成这样任务模型会它任务中间过程能力探测。

背景
===
目前我们在编写一个产品目录服务，通过API提供所有可售商品的详细信息。
此API不能修改或增加可售商品。
使用Java编写。

任务
===
请问这个产品目录服务主要有什么功能？

这个产品目录服务的主要功能是提供一个API接口，通过该接口可以查询和获取所有可售商品的详细信息。具体来说，该服务可能包括以下功能：

1. **商品查询**：根据用户的查询条件，如商品名称、类别、价格等，返回符合条件的商品列表。
2. **商品详情**：提供单个商品的详细信息，包括商品名称、描述、价格、库存数量、图片等。
3. **商品分类**：将商品按照不同的类别进行组织和展示，方便用户浏览和选择。
4. **商品推荐**：根据用户的历史购买记录、浏览记录等信息，向用户推荐可能感兴趣的商品。
5. **商品搜索**：提供商品搜索功能，允许用户通过关键词搜索他们需要的商品。
6. **商品比较**：允许用户将多个商品进行比较，以帮助他们做出购买决策。
7. **商品评价**：允许用户对商品进行评价和评分，并展示其他用户的评价和评分信息。

需要注意的是，由于该服务不能修改或增加可售商品，因此它不提供商品的添加、编辑或删除功能。这些功能可能需要由其他系统或服务来提供。

从生成的结果看模型给出的答案是偏向完备性的回答，也就是说这类问题的所有可能都给出来了。并且不包含软件架构需要考虑功能性能力是不具备的。如此我们大致可以知道模型在不加业务背景知识情况下的下界能力。

验证模型对于这个任务上界

通过上面的模块我们已经确认了模型的能力边界、并且大致知道了在不给业务背景的前提下模型的下界能力。那么接下来我们需要验证在给定业务背景知识下模型的指令遵循能力，或者说我们需要验证下给定业务背景知识下模型的上界。

背景
===
目前我们在编写一个产品目录服务，通过API提供所有可售商品的详细信息。
此API包含列出所有商品，按SKU查看某个商品，按照分类列出商品以及按关键词搜索的功能；
使用Java编写。

任务
===
请问这个产品目录服务主要有什么功能？

这个产品目录服务主要具有以下功能：

1. **列出所有商品**：通过API，用户可以获取到产品目录中所有可售商品的详细信息。这包括商品的名称、描述、价格、库存等关键信息。
2. **按SKU查看某个商品**：SKU（Stock Keeping Unit）是商品的唯一标识符。通过API，用户可以根据SKU来查询特定商品的详细信息，包括商品的描述、价格、库存状态等。
3. **按照分类列出商品**：产品目录中的商品通常被组织成不同的类别或子类别。通过API，用户可以根据指定的类别来获取该类别下所有可售商品的详细信息。
4. **按关键词搜索**：用户可以通过关键词在产品目录中进行搜索，以找到与关键词相关的商品。API会返回与关键词匹配的商品列表，包括商品的详细信息。

这些功能可以帮助用户方便地浏览和查询产品目录中的商品信息，从而提高购物体验和销售效率。

在给定了业务背景知识（约束下）模型能给比较明确的把很多不需要的功能裁剪了，可以相对精准给出功能范围；可见模型上界是符合我们当前任务需要的。
接下来我们还可以继续验证当前的业务知识是否是足够的，比如：

背景
===
目前我们在编写一个产品目录服务，通过API提供所有可售商品的详细信息。
此API包含列出所有商品，按SKU查看某个商品，按照分类列出商品以及按关键词搜索的功能；
使用Java编写。

任务
===
请问通过API提供的产品信息都包含哪些内容？

通过API提供的产品信息通常包括以下内容：

1. **基本信息**：
   - 产品名称（Product Name）
   - 产品描述（Product Description）
   - 产品代码或SKU（Stock Keeping Unit）
   - 产品类别或分类（Product Category）
   - 产品品牌（Brand）
   - 产品型号（Model）

2. **价格信息**：
   - 售价（Selling Price）
   - 折扣价（Discounted Price）
   - 促销信息（Promotion Information）
   - 价格有效期（Price Validity）

3. **库存信息**：
   - 库存数量（Stock Quantity）
   - 库存状态（Stock Status，如可用、缺货等）
   - 预计到货日期（Expected Arrival Date）

4. **图片和多媒体信息**：
   - 产品图片（Product Images）
   - 产品视频（Product Videos）
   - 360度全景图（360-degree Views）

5. **技术规格和特性**：
   - 产品尺寸（Dimensions）
   - 产品重量（Weight）
   - 材料和成分（Materials and Components）
   - 技术规格（Technical Specifications）
   - 产品特性和功能（Features and Benefits）

6. **购买和配送信息**：
   - 购买选项（Purchase Options，如购买数量限制）
   - 配送信息（Shipping Information，如配送方式、运费、预计送达时间）
   - 退货政策（Return Policy）

7. **客户评价和评分**：
   - 客户评价（Customer Reviews）
   - 产品评分（Product Ratings）

8. **相关产品和推荐**：
   - 相关产品（Related Products）
   - 购买此产品的顾客还购买了（Customers Who Bought This Item Also Bought）

9. **法律和合规信息**：
   - 产品认证和合规性（Certifications and Compliance）
   - 保修信息（Warranty Information）

以上是产品信息API可能包含的内容，但具体内容可能会根据产品类型、业务需求和API设计而有所不同。

同样模型给出了很多次泪问题的通用回答，给出很多冗余的答案。这就是模型在不给需要输出的产品业务背景知识下的模型能力下界。这就又回到了“验证模型对于制定任务下界”环节，接着我们可以在给定产品业务背景知识看看模型输出是否符合要求来验证模型对于制定任务上界。如此循环已确定出模型的能力边界，可解决问题的大小和范围。

背景
===
目前我们在编写一个产品目录服务，通过API提供所有可售商品的详细信息。
商品详细信息包括：SKU，商品名字，不同的产品选项，以Markdown形式保存的商品详情；
此API包含列出所有商品，按SKU查看某个商品，按照分类列出商品以及按关键词搜索的功能；
使用Java编写。

任务
===
请问通过API提供的产品信息都包含哪些内容？

通过API提供的产品信息通常包括以下内容：

1. **SKU（Stock Keeping Unit）**：这是产品的唯一标识符，用于跟踪和管理库存。
2. **商品名字**：产品的正式名称，通常用于在网站或目录中显示。
3. **产品选项**：这包括产品的尺寸、颜色、材料等不同变体。例如，一件T恤可能有不同的颜色和尺寸。
4. **商品详情**：这是关于产品的更详细信息，通常以Markdown形式保存。这可能包括产品的描述、功能、使用说明、保修信息等。

此外，API还可能提供其他功能，如：

- **列出所有商品**：返回所有可售商品的列表。
- **按SKU查看商品**：根据提供的SKU返回特定商品的详细信息。
- **按分类列出商品**：根据提供的分类返回属于该分类的所有商品。
- **按关键词搜索**：根据提供的关键词返回匹配的商品。

这些信息可以通过API以结构化的方式（如JSON或XML）提供给客户端应用程序，以便在网站、移动应用程序或其他系统中使用。

增加产品描述项背景知识后，模型可以比较准确的输出想要的结果；可见模型的能力是能够胜任给定的任务的。接着我们把前面验证需要增加的各种业务知识整理汇总到业务背景知识上下文。让模型生成完成最终任务，看看模型能不能比较好的完成任务。

背景
===
目前我们在编写一个产品目录服务，通过API提供所有可售商品的详细信息。
商品详细信息包括：SKU，商品名字，不同的产品选项，以Markdown形式保存的商品详情；
此API包含列出所有商品，按SKU查看某个商品，按照分类列出商品以及按关键词搜索的功能；
使用Java编写。

要求
===
所有API文档需要以RAML形式编写;
如存在异常分支，给出示例;

任务
===
请提供代码和所有功能的功能测试。

编写一个完整的产品目录服务并提供所有功能测试是一个相对复杂的任务，需要详细的设计和实现。由于篇幅限制，我将提供一个简化的示例，包括API的基本结构和部分功能测试。请注意，这只是一个起点，实际项目中需要更复杂的逻辑和更全面的测试。

### 产品目录服务示例（Java）

首先，我们需要定义一些基本的类来表示商品和产品目录。

```java
// 商品类
public class Product {
    private String sku;
    private String name;
    private Map<String, String> options; // 产品选项
    private String details; // 以Markdown形式保存的商品详情

    // 构造函数、getter和setter省略
}

// 产品目录服务接口
public interface ProductCatalogService {
    List<Product> listAllProducts();
    Product getProductBySku(String sku);
    List<Product> listProductsByCategory(String category);
    List<Product> searchProductsByKeyWord(String keyword);
}

接下来，我们实现这个服务接口。

// 产品目录服务实现
public class ProductCatalogServiceImpl implements ProductCatalogService {
    private List<Product> products;

    public ProductCatalogServiceImpl(List<Product> products) {
        this.products = products;
    }

    @Override
    public List<Product> listAllProducts() {
        return new ArrayList<>(products);
    }

    @Override
    public Product getProductBySku(String sku) {
        return products.stream()
                .filter(p -> p.getSku().equals(sku))
                .findFirst()
                .orElse(null);
    }

    @Override
    public List<Product> listProductsByCategory(String category) {
        return products.stream()
                .filter(p -> p.getOptions().getOrDefault("category", "").equals(category))
                .collect(Collectors.toList());
    }

    @Override
    public List<Product> searchProductsByKeyWord(String keyword) {
        return products.stream()
                .filter(p -> p.getName().toLowerCase().contains(keyword.toLowerCase()) ||
                             p.getDetails().toLowerCase().contains(keyword.toLowerCase()))
                .collect(Collectors.toList());
    }
}

功能测试示例

对于功能测试，我们可以使用JUnit框架。以下是一些基本的测试用例。

import static org.junit.Assert.*;
import org.junit.Before;
import org.junit.Test;
import java.util.Arrays;
import java.util.List;
import java.util.HashMap;

public class ProductCatalogServiceTest {
    private ProductCatalogService service;

    @Before
    public void setUp() {
        List<Product> products = Arrays.asList(
                new Product("SKU001", "Laptop", new HashMap<>(), "## Laptop Details"),
                new Product("SKU002", "Smartphone", new HashMap<>(), "## Smartphone Details")
        );
        service = new ProductCatalogServiceImpl(products);
    }

    @Test
    public void testListAllProducts() {
        assertEquals(2, service.listAllProducts().size());
    }

    @Test
    public void testGetProductBySku() {
        assertNotNull(service.getProductBySku("SKU001"));
        assertNull(service.getProductBySku("INVALID"));
    }

    @Test
    public void testListProductsByCategory() {
        // 假设SKU001和SKU002都属于"Electronics"类别
        service.getProductBySku("SKU001").getOptions().put("category", "Electronics");
        service.getProductBySku("SKU002").getOptions().put("category", "Electronics");
        assertEquals(2, service.listProductsByCategory("Electronics").size());
    }

    @Test
    public void testSearchProductsByKeyWord() {
        assertEquals(1, service.searchProductsByKeyWord("Laptop").size());
        assertTrue(service.searchProductsByKeyWord("Details").size() >= 2);
    }
}

请注意，这只是一个示例，实际的实现和测试可能需要更多的细节和考虑。例如，你可能需要处理异常情况、数据库集成、API安全性、性能测试等。此外，实际的API实现可能需要使用Spring Boot或其他框架来提供RESTful服务。

从生成的结果看，模型应该是可以比较好的完成任务。当然还有很多的非架构层面支持代码没有考虑进来还是有很多的改进的。<br />**prompt模版基本组成：背景上下文+约束条件+业务知识策略+输出要求+任务描述**<br />![](https://intranetproxy.alipay.com/skylark/lark/0/2024/jpeg/284872/1716435555526-2b966130-12d3-41a6-b5f0-74959729388f.jpeg)
<a name="fv6br"></a>
# 什么时候要把任务划分成更小任务（怎么划）
上面的模块简单的介绍了该如何去验证模型的能力、模型能力的上下界。然而对于现实的业务问题，模型往往是很难一步就生成我们想要的答案的。实际的业务问题往往是复杂的，综合性的问题；并非简单的一个prompt或者一步就能解决的问题。<br />对于这类复杂的业务问题，问题本身就耦合很多信息。如果一股脑儿的把需要的业务知识喂到模型，你会发现要描述清楚这些业务知识、业务知识之间的关系就已不是容易之事；并且就算把这些业务知识、知识管理理清楚了一股脑儿的给模型，模型往往也不具备这么强能力消费。<br />1.模型不具备接受如此长prompt能力 <br />2.模型不具备分析清楚如此复杂知识之间差异能力 <br />3.模型不具备从一次激活如此复杂约束下所有约束能力<br />如此可见如果要解决复杂的问题，分步骤、分任务切分任务，并做好任务之间的串接、组织是非常必要的工作。换句话话说就是复杂问题要如何切分成小任务，小任务之间关系如何组织是解决业务关键。<br />这和业务相关性很高，不同业务会有不同的小任务切分、小任务组织的最优方法。在此只能介绍些简单通用的规则。
<a name="G26qs"></a>
## 什么样任务需要切分
1.任务复杂涉及多个步骤<br />2.任务结果简单，但是直接看结果不方便人类验证<br />3.任务需要知识量过大，涉及到过多背景上下文<br />4.任务耦合多个差异性较大小任务
<a name="J60ON"></a>
## 如何切分成小任务
<a name="dgVgR"></a>
### 划分任务并非越小越好
划分任务越小业务复杂度降低越多；但是这会增加小任务的个数，小任务个数增加会增加系统复杂度。系统复杂度的增加一样会带来可控性灾难，让生成任务不鲁棒导致每次执行可能得到不一样结果，任务不稳定。
<a name="sXman"></a>
### 能力分块
<a name="yWQvR"></a>
#### 问题解耦合
复杂任务往往是由多个业务知识耦合在一起，复杂很大部分来源于多业务知识的交互场，多个影响因素导致精准表述任务的难度增加。<br />所以对这类业务问题，需要构建解决业务架构。把涉及到的业务域划分出来，把业务域交互的地方剥离开；构建出相对稳定的业务域衔接架构。尽可能的把交互业务域个数控制在2个左右。
<a name="lvc0r"></a>
#### 建立好能力
业务域划分清楚了，也搭建好了相对稳定的业务交互的机构。接着就是对每个业务任务做划分，这一步的目的是让模型能完全胜任划分的任务。很有可能一个业务域任务还是太大，模型不足以胜任。这时候我们需要把单业务域下问题在划成小问题，让模型能力足以解决。<br />同一业务域下的问题如何划分，同一业务域下问题划分关键在于业务知识映射关系要建立好。把相关映射关系下问题归到一个字问题应该问题大小、问题解决难度模型就能过胜任。
<a name="IHQEB"></a>
### 小任务之间如何组织
<a name="ngyeO"></a>
#### 信息串接
两个任务间多用清晰结构输出衔接。前一个任务得到结果作为下一个任务的输入，这时候如果上一个任务直接生成的是一整段话各种信息都混杂在一起。那么往往下一个任务生成结果很容易出现幻觉、不可控。所以对于这类信息串接为了维持稳定性，我们希望前一个任务生成的结果是结构化整理组织的。并且下一个任务制定出结构数据的某几项里面取数据来保证生成结果的稳定可控。
```bash
智通财经获悉，亚马逊(AMZN.US)周一发布了新款Echo Spot，售价79.99美元，在7月17日之前面向 Prime 会员的售价为44.99美元。这款支持Alexa的2024版智能闹钟较此前设计有所改进，音频质量也有所改善。该公司表示，最新迭代的产品具有更好的视觉效果和更高的音频质量。该设备有黑色、冰川白和海洋蓝三种颜色。

Echo Spot显示屏可以让用户设置和查看闹钟，还可以查看时间、天气和歌曲名。它还配备了一个 1.73 英寸的前置定向扬声器，可提供"清晰的人声和深沉的低音"。

这是亚马逊自2017年推出Echo Spot以来的首次升级。上一款设备在亚马逊上的售价为129美元，同样采用了半圆设计，但配备了全尺寸显示屏和摄像头。与 2017 年的 Echo Spot 不同，最新版本没有集成用于视频通话的摄像头。这一改变可能会受到欢迎，尤其是对于那些不想在卧室里安装带摄像头设备的人来说。上一代 Echo Spot 配备了一个完整的圆形屏幕，而最新版本则将设备的正面与扬声器分割开来。

据此前报道，亚马逊正在更新Echo Spot，因为它有望彻底改造为其智能扬声器提供动力的语音助手Alexa。该公司通常会在9月举行的秋季发布会上发布一系列关于Echo和Alexa系列的产品。
总结这篇文章

## 亚马逊发布新款Echo Spot智能闹钟

### 产品信息
- 新款Echo Spot售价为79.99美元，但Prime会员在7月17日之前可以44.99美元的价格购买。
- 该设备支持Alexa，并提供黑色、冰川白和海洋蓝三种颜色选择。
- Echo Spot显示屏可用于设置和查看闹钟，以及查看时间、天气和歌曲名等信息。
- 设备配备了一个1.73英寸的前置定向扬声器，提供清晰的人声和深沉的低音。

### 设计改进
- 新款Echo Spot在设计上有所改进，具有更好的视觉效果和更高的音频质量。
- 与2017年的版本相比，新款Echo Spot没有集成用于视频通话的摄像头，这可能受到一些用户的欢迎。
- 上一代Echo Spot配备了一个完整的圆形屏幕，而最新版本则将设备的正面与扬声器分割开来。

### 背景信息
- 这是亚马逊自2017年推出Echo Spot以来的首次升级。
- 上一款Echo Spot在亚马逊上的售价为129美元，采用了半圆设计，并配备了全尺寸显示屏和摄像头。
- 据报道，亚马逊正在更新Echo Spot，因为它有望彻底改造为其智能扬声器提供动力的语音助手Alexa。
- 该公司通常会在9月举行的秋季发布会上发布一系列关于Echo和Alexa系列的产品。

智通财经获悉，亚马逊(AMZN.US)周一发布了新款Echo Spot，售价79.99美元，在7月17日之前面向 Prime 会员的售价为44.99美元。这款支持Alexa的2024版智能闹钟较此前设计有所改进，音频质量也有所改善。该公司表示，最新迭代的产品具有更好的视觉效果和更高的音频质量。该设备有黑色、冰川白和海洋蓝三种颜色。

Echo Spot显示屏可以让用户设置和查看闹钟，还可以查看时间、天气和歌曲名。它还配备了一个 1.73 英寸的前置定向扬声器，可提供"清晰的人声和深沉的低音"。

这是亚马逊自2017年推出Echo Spot以来的首次升级。上一款设备在亚马逊上的售价为129美元，同样采用了半圆设计，但配备了全尺寸显示屏和摄像头。与 2017 年的 Echo Spot 不同，最新版本没有集成用于视频通话的摄像头。这一改变可能会受到欢迎，尤其是对于那些不想在卧室里安装带摄像头设备的人来说。上一代 Echo Spot 配备了一个完整的圆形屏幕，而最新版本则将设备的正面与扬声器分割开来。

据此前报道，亚马逊正在更新Echo Spot，因为它有望彻底改造为其智能扬声器提供动力的语音助手Alexa。该公司通常会在9月举行的秋季发布会上发布一系列关于Echo和Alexa系列的产品。
总结这篇文章,列出：
1.事件内容描述
2.涉及企业
3.对哪个投资板块有影响
4.对资本是正向还是负向影响
5.文章观点
6.影响多少市值
7.描述什么产品
json格式输出

{
    "事件内容描述": "亚马逊发布了新款Echo Spot，售价79.99美元，Prime会员在7月17日之前可以44.99美元购买。新款Echo Spot在设计和音频质量上有所改进，支持Alexa，有黑色、冰川白和海洋蓝三种颜色。它具有更好的视觉效果和更高的音频质量，但与上一代相比，没有集成用于视频通话的摄像头。",
    "涉及企业": "亚马逊（AMZN.US）",
    "对哪个投资板块有影响": "智能家居和语音助手技术板块",
    "对资本是正向还是负向影响": "正向影响，新款Echo Spot的发布可能增加亚马逊的销售额和市场份额。",
    "文章观点": "文章认为新款Echo Spot在设计和音频质量上的改进，以及更低的售价，可能会受到消费者的欢迎，尤其是那些不希望在卧室里安装带摄像头设备的人。",
    "影响多少市值": "文章没有提供具体的影响市值的数据。",
    "描述什么产品": "文章描述了亚马逊新款Echo Spot智能闹钟，包括其设计、功能、售价和与上一代产品的区别。"
}

业务域交互组织

对于多个业务域交互衔接部分，该如何组织来保证生成结果能够稳定呢。首先是尽可能让多个业务域交互控制在两个；其实交互部分用SOP流程+BOM物料组织方式来保证生成内容稳定性；在此多用总结抽取替代生成保证多业务交互部分少出现模型凭空发挥，引入不必须的噪声经过交互震荡导致生成内容奔溃。

小结

文章总结

引言

• 文章讨论了在LLM（大型语言模型）时代，如何将抽象的知识概念具体化到实际业务中，以使模型能够更好地服务于业务。
• 文章提出了两个关键过程：概念对齐和知识激活。
  

概念对齐

• 概念对齐主要通过SFT（监督微调）和RLHF（基于人类反馈的强化学习）来实现业务私域指令和通用知识概念的对齐。
• RLHF更多地用于解决非对错问题，如选择观点站队。
• 一些私域会进行知识增量二次预训练来增强模型的私域能力。
  

知识激活

• 知识激活是指如何根据实际私域差异化任务，将细分知识正确地激活和表述，使模型更可控。
• 这包括如何探测LLM模型的能力是否足够，以及如何验证模型是否满足任务要求。
  

探测LLM模型能力

• 文章提供了一些测试模型能力的规则，如简单表述任务、交代背景、描述约束等。
• 通过逐步增加任务的复杂性和背景知识，可以验证模型的能力边界和上界。
  

任务划分与组织

• 对于复杂的业务问题，文章建议将任务划分成更小的任务，并做好任务之间的串接和组织。
• 文章提供了一些任务划分和组织的通用规则，如任务的复杂性、结果的验证性、知识量的大小等。
  

结论

• 文章强调了在LLM时代，如何用好模型，即如何将模型知识激活并具体化到实际业务中的重要性。
• 通过结构化的方法来探测模型能力、验证任务要求，并合理地划分和组织任务，可以更好地发挥LLM在实际业务中的作用。