一、For Web3

1.1 More 应用(Agent) or 通用模型

1. 通用大模型虽然在不断发展，但是离真正满足用户的需求仍然有不小的距离。

2. AI应用的最小单元是Agent，构建一个Agent需要给LLM再组装上额外的知识库、工具以及相应的指示。LLM只是决定了Agent的下限，LLM可以使用的组件才决定了其上限。我们需要更多深度定制的Agent（而不是简单的GPTs）来满足用户的需求，进而通过多Agent的协调合作来实现更复杂的应用场景。

3. 通用大模型的训练过程，就是在追求全局最优——多种能力（生成、编程、推理、数学）混合后的最优状态。所以这并不意味着它在局部上就一定优于一些针对性优化的模型。这也是一些MOE（混合专家）模型可以用更小的规模表现出等效于更大规模模型的原理。

4. 训练一个小规模的LLM，固然能展示团队的实力，但是未必就能满足实际的场景。不过这也不是团队意愿的问题，训练数据的匮乏限制了训练/微调一个针对性模型的可能性。在确定聚焦的场景后，积累和挑选数据也不是立竿见影的，需要真实用户的交互和反馈。

1.2 TypoX AI

所以我们打造了TypoX AI这个平台

1. 让用户能够在AI的协助下更好的进行调研，大大降低了调研门槛，让DYOR不再是一句空话。

2. 为了实现这一目标，我们建构了专属的RAG（检索增强生成）框架，为LLM配置了Web3知识库和实时检索工具，可以认为我们打造了一款服务于Web3行业的Perplexity AI。

3. 在RAG的加持下，我们总能得到质量优于原生LLM的输出，这恰好满足了我们进一步训练和微调模型的数据需要（训练/微调模型总是需要质量更高的问答对）。同时这些真实的交互数据也体现出了用户的偏好，使得模型能够更贴近社区的需求。

二、By Web3

2.1 AI发展到底应该怎么去中心化？

1. 如果LLM模式的AI发展到极致，那最后留给人发挥的空间是什么？
   至少需求还是由人提出的。实际上人将长期作为需求方存在，因为目前的生成式模型还是没有自主意识的，依然需要由人类来提出问题。

2. 更一般地来说，模型依然是通过从Experience中学习，来提升在具体Task上的Performance。即使当前的LLM的能力相对于最初的生成Task早已溢出，但是对其溢出的能力的优化依然脱离不了这一框架：
   提出问题： 确立Task，积累针对于该Task的数据（用于训练和测试）;
   解决问题： 在数据上训练，优化模型在具体Task上的表现，从而完成新的工作。

I. 算力去中心化的发展受限

物理规律限制了模型训练和部署（解决问题）的去中心化路径。通信成本是无法克服的瓶颈，相较于集中的算力集群，显卡网络更像是一座座孤岛。 小规模的显卡群基本只能部署生图模型和10B级别的LLM，模型训练上的差距只会更大。这不仅是效率问题，更是能力问题。 AI发展在一定时间内可能都无法摆脱对于集中化高质量算力的依赖。

II. 需求（评价&数据）的去中心化

很多人聚焦于硬件问题，却忽视了数据的重要性，实际上对于训练数据的规模和质量只会逐步提升。

1. 本轮AI的发展是基于语言模型的 Scaling Law，即模型规模越大，能力越强。更大的模型，就需要更多的数据用于训练；
2. 一个模型是无法从其本身生成的内容中学习更多的。 小规模的LLM可以使用GPT4等更大体量模型生成的数据来进行训练/微调，而GPT4级别的头部模型需要的数据质量只会更高。

谁掌握了数据，谁就掌握了AI发展的话语权。目前AI发展话语权是由少部分行业精英掌握的，这是通过树立评估标准、建立训练数据库来实现的。如果不能提出新的需求，那等来的将是更多打榜的通用型模型，用户所真正需要的场景将无法得到解决。

是时候由用户来提出自己对于AI发展的需求了。为了实现这一目标，我们需要建立用户自己的评价体系，进而构建专属的训练数据库，以此来获得对于AI发展方向的话语权。

2.2 TypoCurator

目前对于通用大模型有一些评价手段，但是针对具体AI应用的评价手段还很匮乏。针对于一些有明确答案标准的场景，比如意图识别场景（用户的需求应该调用哪一个DApp/DAgent），需要建构对应的标签数据库，以此来进行针对性的评价和优化。

由此我们最新推出了TypoCurator这个产品，借助Ton生态广泛的用户群体，通过社区分工的形式来构建聚焦于Web3场景的标签数据库，为我们之后训练Web3 AI OS做数据准备。对于普通用户而言，只要完成日常答题/标注任务，即可获得 $TPX 奖励。

2.3 Agent Arena (Soon)

除了标签数据之外，有大量的应用场景是没有明确标准的。比如根据项目信息生成调研报告，在保证事实清晰的基础上，依然会存在关注重点、行文逻辑和风格等问题。这些需要用户来进行对比选择。

受到LMSYS Arena的启发，我们即将推出Agent Arena。用户将在不知道Agent信息的情况下进行对比选择，帮助我们实现对Agent和模型的评估。早期将聚焦于Web3的行业场景，用户的评价将帮助我们更好地优化TypoX AI，从而更好地服务于Web3行业。

我们在LMSYS Arena的基础上，将评估对象从通用模型进一步推广到Agent，同时对于机制进行了进一步优化，降低了作弊和偏见风险。我们希望为AI开发者提供公允的评价体系和参考，以及定制化的AB测试流程，从而促进整个AI应用生态的发展。

一、拥抱随机性

要打造一款AI产品，首先应该知道要做的工作是什么。简单来说，就是控制LLM的随机性。随机性是一把双刃剑，用好了叫能力泛化，用不好就成了幻觉。在创作领域，对于精确性的容忍度高，随机性促成了创作的天马行空，相信大部分用户最初被大模型震撼的都是其创作生成能力。但是在面对事实和数学代码的严密逻辑时，就只有对错，没有模糊空间，所以幻觉大多出现在这种情形。

在数学和代码方面，较早的优化是给LLM配置外部工具（如Wolfram Alpha）、编译环境（Code Interpreter），随后是进一步的加强训练，进一步在一些工作流的加持下，可以解决相对复杂的数学问题，完成一定长度的实用代码。

在客观事实方面，大模型确实是能将部分信息存储在模型参数中，但是很难预知或者预设哪些知识点是必然拟合好的，而一味提高在训练上的准确性往往会导致过拟合，减弱泛化能力；同时大模型的训练数据总是有截止日期的，即使针对所有训练数据的问答都完美匹配，也无法预测出之后发生的事，况且大模型的训练成本决定了模型的更新不会过于频繁。所以通过使用外置的知识库增强生成结果才得到了广泛的重视。

二、RAG的挑战与愿景

2.1 什么是RAG

检索增强生成（Retrieval Augmented Generation, 即RAG) 早在2020年就被提出了，也是随着近期LLM产品的发展需求，才获得了比较广泛的应用。目前主流的RAG流程不涉及对模型本身参数的修改，是通过增强给模型的输入来提高生成内容的质量。用一个简单公式 y=f(x) 来解释一下：f 是大模型，一个参数量很大的（随机非线性）函数；x 就是输入项；y 就是输出项；RAG就是在 x 上下功夫，来提高 y 的质量。

因为不涉及模型本身，所以RAG在成本上有很大优势，组合性也高，可以随意替换模型使用。只需检索出最相关的内容，提供给大模型，相较于直接全文输入，节省了所需Token数量，除了降低使用成本外，也大大压缩了回复用户的反应时间。

2.2 长上下文模型

近阶段出现了很多支持长上下文（输入窗口）模型，可以直接将完整的长篇巨著直接丢给大模型来处理，算是克服了大模型早期输入短的限制，这也是最初RAG的诱因之一，许多人认为RAG也许会就此势微。

在大海捞针测试（让大模型在一段长文本中找到对应的内容）中，长上下文模型确实比之前的模型有更好的表现，但是相对于开头和结束部位，在处理文本中间的针时的表现有些差强人意；同时大海捞针测试本身也是有瑕疵的，目前公开的测试主要还是单针的（即要寻找的线索只有一条），从单针到多针，问题复杂度会急剧提升，对大模型而言依然是挑战，另外也有第三方测试者发现有些模型可能在训练时就已经得知需要找的针是什么了(有作弊嫌疑)。新模型在长上下文的表现上可能确实有提升，但是鲁棒性可能没有预期中的那么高。

当然大模型在长上下文上还会继续优化，目前的瑕疵可能过段时间也许不是问题了，但是成本对于训练者和使用者来说依然是较高的门槛。相较于直接粗暴得将所有文本一股脑甩给模型，RAG在成本和时效性上依然有不可替代的优势。但RAG也需要根据模型的进步进行调整，特别是文本处理的颗粒度，避免出现过度处理反而降低整体效率的情况。在具体的产品中，我们总是需要在成本、时效和质量之间做权衡。

2.3 RAG的愿景

相较于简单使用向量库存储召回的早期RAG应用，我们需要从更系统的角度来审视和构建新的RAG框架，也许我们可以从RAG的持续研究中获得启发。内容、检索方式与检索器、生成器（LLM），是RAG系统的基本元素。

针对检索器的优化相对丰富，同时也因为其便利性，是应用最早也最多的RAG方法。除此之外，应该更多地考虑内容本身，向量数据库未必就是唯一的选择，键值/关系型/图数据库也是可以考虑的方案，一切根据数据的结构来进行选择，同时相应的调整检索器就可以进一步增加检索聚合的效果。

另外LLM也可以在内容预处理中扮演更重要的角色，相较于简单的切片-向量化-检索路径，使用分类模型和LLM进行提炼总结和重构，将内容以对LLM更友好的形式进行存储，同时更加依赖语义而不是向量距离来进行检索，将大幅提高生成的效果，TypoX AI团队在产品实现中也验证了这一点。

除了单独优化其中某一元素，也可以同时优化多个元素，尤其是大部分RAG方法都是锁定（不涉及）生成模型的，将检索与生成模型一起训练，也将是RAG的一个很重要的方向。由此引出了另一个话题：RAG、微调和LLM的关系。每逢LLM本身能力的提升与更低成本的微调技术的出现，都会有人会说要用微调干掉RAG，RAG已死。

回到前文提到的 y=f(x) 上，LLM和微调影响的都是 f 本身的参数，目的是在不加强输入x 的情况下，就能提升生成 y 的质量。而RAG则是通过加强 x 的输入，来提高 y 的质量。两种方案并不是矛盾的，而是相向而行的，模型的能力提升和输入的加强都有助于生成结果的优化。同时进阶的RAG也会涉及到模型对于知识库的针对性微调，将不再局限于对于输入的增强上。RAG的价值就在于，比原始LLM有更好的生成效果，（即使是与微调模型比，RAG的时效性和效果也是更好的，同时配置成本也不会高于微调的成本），以及与把全部知识直接丢给LLM相比，又有更高的效率。

三、人与AI

3.1 大模型的定位

笔者是一贯反对唯模型论和模型极大论的，大模型是很强，但是单独的大模型距离用户真正需要的Agent还是有不少距离的。有独家训练的小模型或微调模型，固然是团队实力的展现，但是落地到产品上，就一定能够给用户提供更好的体验吗？也许将这一部分的资源投入到其他要素（工具、知识库、工作流）上，提升效果可能更明显。而且目前在Web3行业缺乏自己的训练数据和评价标准的情况下，我们行业真的需要更多的打榜通用（小）模型吗？笔者在此呼吁，加密行业需要构建专属的训练数据库和评价标准，进而构建更多更适配行业的专属模型。

当然也不应该低估大模型的能力，在TypoX AI产品的早期探索中，为了使得流程更可控，我们给予了模型较低的信任，有很多流程目前来看都过度开发了。同时也存在为了保证生成质量，而导致成本增加，回复速度过慢的问题（比较典型的就像让LLM进行自反思）。我们在后续的迭代中，逐步优化流程中硬逻辑与LLM的参与度，达到了一个相对较优的平衡。

3.2 人的价值

AI能力的提升，其实反而更突显了人的价值，使得人的价值更具象化了。在人机交互中，人反而是最高效的Agent。只有人最知道自己要什么不要什么，人永远是甲方（需求方），AI固然可以进行自我反思，但是提升质量和准确性，结果也未必符合用户的需求。所以在产品的交互中，过于重视准确性，忽略时间延迟，未必是明智之举。有些决策过程更适合用户自己执行，应该把主要的决策权让渡给用户。

唯模型论的另一方面，就是忽视了人的存在，一味追求模型的表现，忽视了人机交互中人的体验，以及人机协作对于整体流程的效率提升。将产品用户转变为共建者，这也是加密社区去中心化精神所在。 从对知识库、工具的偏好，提示词、工作流的挖掘，到模型训练和微调所需要的语料，DAgent的所有部件都离不开社区的参与。TypoX AI团队已经初步构建了一系列与用户共建的机制，后续将逐步向社区公布，让每一位TypoX AI用户无需考虑硬件门槛，都有机会参与到DAgent生态的建设之中。

Introduction to CrewAI

CrewAI is a multi-agent framework with a more humanized development concept. You act as a project manager, define various employees (agents), assign them different tasks, and finally define a team (crew). This team consists of various agents and subtasks, and the final task of the team is to fulfill the client's requirements.
To quickly understand CrewAI, you only need to grasp its three basic elements: Agent, Task, and Crew.

I. Agent

An agent is the basic operational unit in CrewAI, similar to a virtual role with specific duties and capabilities. In CrewAI, an agent is defined by the following four basic elements, which are described in natural language in the code.

1. Role
The role is the identity and duty description of the agent. It defines the agent's position and function within the system, determining the agent's behavior and interaction with other agents.

2. Goal
The goal is the specific task or result that the agent needs to achieve. Each agent has a clear goal that guides its behavior and decision-making.

3. Backstory
The backstory provides context and background for the agent, helping to define its behavior and decision-making style. It may include the agent's hypothetical experiences, knowledge areas, and working style.

4. Tools
Tools are the specific resources or methods used by the agent to perform tasks. These can include external APIs, data processing libraries, search engines, etc. Agents can work without tools, but tools are not mandatory.

1.1 Example

Suppose we create a Research Specialist Agent.

1. Role
Research Specialist

2. Goal
Collect and organize detailed information about conference participants, including their background, company, and recent activities.

3. Backstory
An experienced researcher with extensive data analysis and information gathering experience, capable of efficiently mining and organizing relevant information to provide strong support for conference preparation.

4.Tools
Web scraping tool (ScrapeWebsiteTool), PDF reading tool (PDFSearchTool)

II. Task

A task is the specific work that an agent needs to complete. CrewAI defines a task through the following four elements:

1. Description
A detailed description of the task, clearly stating its purpose and content.

2. Expected Output
The specific results or products required upon task completion. This sets a clear standard for task completion, ensuring the agent knows what kind of result to deliver.

3. Tools
The specific resources or methods used by the agent in task execution. These tools are the same as those defined for the agent and can be temporarily relied upon for the task.

4. Agent
The specific role that will execute the task.

2.1 Example

Suppose we create a "Collect Conference Participants Information" task.

1. Description
Collect detailed background information on all conference participants, including their educational background, career experience, current job position, and responsibilities.

2. Expected Output
An Excel sheet containing detailed information for each participant, with columns for name, educational background, career experience, current position, and current company.

3. Tools
ExcelTool, a tool for creating Excel sheets.

4. Agent
Research Specialist Agent

III. Crew

A crew is a team composed of multiple agents working together to complete more complex tasks. Defining a crew mainly involves defining a team of agents, a list of tasks, and a process, which can be understood as the project execution process.

1. Agents
Define which members (agents) are in the crew.

2. Tasks
Define the specific tasks the crew needs to complete.

3. Process
The key to defining a crew is defining the process. Generally, this is a sequential structure where the next task starts after the previous one is completed, and the final task represents the crew's ultimate output. For advanced operations such as defining parallel and sequential tasks, CrewAI has a dedicated Process class, which is beyond the scope of this introductory chapter.

3.1 Example

Suppose we define a crew to send product quotations.

1. Agents

• list itemProductInfoCollectorAgent: Responsible for collecting product information.
• CustomerInfoCollectorAgent: Responsible for collecting customer information.
• PricingCalculatorAgent: Responsible for calculating product prices.
• QuoteDocumentGeneratorAgent: Responsible for generating the quotation document.
• EmailSenderAgent: Responsible for sending the quotation via email.

2. Tasks

• CollectProductInformationTask: Collect detailed product information.
• CollectCustomerInformationTask: Collect detailed customer information.
• CalculatePricingTask: Calculate prices based on product and customer information.
• GenerateQuoteDocumentTask: Generate the product quotation document.
• SendQuoteEmailTask: Send the quotation to the customer via email.

3. Process

• Sequential structure.