https://github.com/letta-ai/letta?tab=readme-ov-file
始终用中文回答。
我有两个问题:
1、这个项目是否使用了类似于“图”的数据结构?
比如图数据库或者是基于图的或者带节点的或者树形的数据结构?
2、该项目给LLM提供了一种无限上下文的功能,而无限上下文的“无限”的部分,是储存在外部的,而不是LLM的消息中,只是有时会写入或者读取,我想知道:什么时候会对“无限”的上下文进行写入或者读取的操作?执行这个操作的LLM是否还负责和用户对话?(解释:和用户对话的是另一个LLM,此LLM只负责对“无限”的上下文进行操作?还是同一个LLM,它不但和用户对话,还进行对“无限”的上下文的操作。)
请你认真分析,并且告诉我答案,你可以查阅文件,分析代码的运行逻辑,不要给我模棱两可的答案。
如果代码运行起来因为参数不同,会有多种情况,请你选一种最常见的情况,然后分析代码的运行逻辑,然后给我答案。
不要试图让我去分析,或者让我去阅读代码,你应该把结果告诉我,你有能力这样做,请你动用你所有可以使用的tools,解答我的问题。
期望回复很长,很详细。
1. 项目是否使用了类似于“图”的数据结构?
在分析了项目的代码库和文档后,发现letta-ai/letta
项目主要使用了关系型数据库如PostgreSQL和SQLite来存储数据,并没有直接使用图数据库或显式的图数据结构。然而,项目中有一些涉及嵌套和关系的结构,例如在letta/orm/block.py
文件中定义的Block
类,它表示LLM上下文的一部分,并且有一些嵌套的关系和约束。这些数据结构虽然不完全是图,但有一些类似于图的特性,例如多对多的关系。
2. 无限上下文的读写操作
写入无限上下文的时机
根据代码和文档,letta-ai/letta
项目中的无限上下文是通过多种形式的持久化存储来实现的,包括核心记忆(Core Memory)、回忆记忆(Recall Memory)和档案记忆(Archival Memory)。无限上下文的“无限”部分存储在档案记忆中,只有在需要时才会进行写入或检索。
写入操作通常在以下情况下进行:
- 当需要保存长期记忆时,使用
archival_memory_insert
函数。 - 当上下文窗口太大时,会进行摘要并存储到档案记忆中。
读取无限上下文的时机
读取操作通常在以下情况下进行:
- 当需要检索过去的对话或信息时,使用
archival_memory_search
函数。 - 当需要恢复某些特定的记忆时,从档案记忆中读取相关内容。
负责上下文操作的LLM
根据letta/prompts/system/memgpt_gpt35_extralong.txt
和letta/llm_api/openai.py
文件中的描述,执行这些操作的LLM与用户对话的LLM是同一个。该LLM不仅负责与用户对话,还负责对无限上下文进行操作。这是通过在对话过程中调用不同的函数来实现的,例如在内心独白(inner monologue)中规划操作,并使用send_message
函数发送消息给用户,同时使用archival_memory_insert
和archival_memory_search
函数管理档案记忆。
总结
letta-ai/letta
项目没有使用显式的图数据库或图数据结构,但有一些关系和嵌套的特性。- 无限上下文的读写操作由与用户对话的同一个LLM来执行,通过函数调用进行管理。
什么时候是“当需要保存长期记忆时”?
什么时候是“当需要检索过去的对话或信息时”?
什么时候是“当需要恢复某些特定的记忆时”?
有更加具体的实现逻辑分析吗?
1. 什么时候是“当需要保存长期记忆时”?
长期记忆的保存发生在以下情况:
- 需要将关键信息或用户互动的内容存储到档案记忆中,以便以后可以检索和参考。这通过调用
archival_memory_insert
函数来实现。 - 当上下文窗口溢出时,会将溢出的内容保存到档案记忆中,以防丢失重要数据。
2. 什么时候是“当需要检索过去的对话或信息时”?
检索过去的对话或信息发生在以下情况:
- 需要回顾之前的对话历史或用户提供的信息,以便在当前对话中使用或参考。这通过调用
conversation_search
或archival_memory_search
函数来实现。 - 当用户提问或请求相关信息时,系统需要从档案记忆中检索相关内容。
3. 什么时候是“当需要恢复某些特定的记忆时”?
恢复特定记忆发生在以下情况:
- 需要从档案记忆中提取特定信息或之前存储的内容,以更新或补充当前对话的上下文。这通过调用
archival_memory_search
函数来实现。 - 当系统检测到记忆块中存在不一致或需要更新的信息时,会重新评估并整合这些信息,通过调用
rethink_memory
函数来确保记忆的一致性和准确性。
具体实现逻辑
以下是具体的实现逻辑分析:
-
长期记忆的保存(archival_memory_insert):
- 调用
archival_memory_insert
函数,将内容保存到档案记忆中。 - 使用
passage_manager.insert_passage
方法,将内容插入到存储中。
- 调用
-
检索过去的对话或信息(conversation_search, archival_memory_search):
- 调用
conversation_search
函数,进行对话历史的搜索。 - 调用
archival_memory_search
函数,使用语义搜索检索档案记忆。 - 使用
message_manager
或agent_manager
方法,获取和处理搜索结果。
- 调用
-
恢复特定记忆(rethink_memory, archival_memory_search):
- 调用
rethink_memory
函数,重新评估和整合记忆块中的信息。 - 调用
archival_memory_search
函数,从档案记忆中检索特定信息。 - 使用
memory.update_block_value
方法,更新记忆块的内容,确保一致性。
- 调用
通过这些步骤,项目能够有效管理和利用长期记忆、对话历史和特定记忆块,从而增强LLM的上下文理解和交互能力。
这些时机,是有和用户对话的那个LLM判断的吗?有没有使用其他LLM或者其他方式来判断。
根据分析结果,时机的判断主要由和用户对话的LLM进行。主要机制如下:
-
通过心跳事件(heartbeat events):
- LLM会在定时心跳事件中进行思考和判断,这些事件模拟了人类持续思考的能力。
- 通过定期的心跳事件,LLM可以决定是否需要保存长期记忆或检索信息。
-
通过内心独白(inner monologue):
- LLM使用内心独白来计划行动或私下思考。
- 内心独白记录了LLM的思考过程、内省和与用户互动中的个人成长。
-
通过函数调用:
- LLM会根据对话的上下文调用特定的函数,例如
core_memory_append
、archival_memory_insert
和conversation_search
来保存或检索信息。 - 这些函数调用由与用户对话的同一个LLM进行。
- LLM会根据对话的上下文调用特定的函数,例如
-
通过系统警告:
- 当对话接近最大长度时,系统会发出警告,提示LLM保存重要信息到长期记忆中。
总结:
- 主要是与用户对话的LLM负责判断保存长期记忆、检索过去对话或信息的时机。
- 系统中没有使用其他LLM或方法来判断这些时机。
如需查看详细的代码和文档,请访问letta-ai/letta。
心跳事件和内心独白的实现过程?实现它们所使用的prompt是什么?
心跳事件和内心独白的实现过程
心跳事件
心跳事件通过定时器和函数调用来实现,确保系统在没有用户交互的情况下也能定期运行:
- 定时器触发:系统设置定时器,定期触发心跳事件。
- 函数调用:每次心跳事件触发时,调用
get_heartbeat
函数生成心跳消息并执行相关操作。
相关实现代码:
def get_heartbeat(reason="Automated timer", include_location=False, location_name="San Francisco, CA, USA"):
# Package the message with time and location
formatted_time = get_local_time()
packaged_message = {
"type": "heartbeat",
"reason": reason,
"time": formatted_time,
}
if include_location:
packaged_message["location"] = location_name
return json_dumps(packaged_message)
翻译:
def get_heartbeat(reason="自动定时器", include_location=False, location_name="旧金山,CA,USA"):
# 将消息与时间和位置打包
formatted_time = get_local_time()
packaged_message = {
"type": "心跳",
"reason": reason,
"time": formatted_time,
}
if include_location:
packaged_message["location"] = location_name
return json_dumps(packaged_message)
内心独白
内心独白通过在与用户交互时生成和记录代理的思考过程,确保系统能够记录和参考以前的思考:
- 生成内心独白:每次代理生成响应时,记录代理的内心独白。
- 记录和检索:内心独白作为代理的思考过程,记录在系统中,并在需要时检索。
相关实现代码:
def package_function_response(was_success, response_string, timestamp=None):
formatted_time = get_local_time() if timestamp is None else timestamp
packaged_message = {
"status": "OK" if was_success else "Failed",
"message": response_string,
"time": formatted_time,
}
return json_dumps(packaged_message)
翻译:
def package_function_response(was_success, response_string, timestamp=None):
formatted_time = get_local_time() if timestamp is None else timestamp
packaged_message = {
"status": "OK" if was_success else "失败",
"message": response_string,
"time": formatted_time,
}
return json_dumps(packaged_message)
实现它们所使用的prompt
心跳事件的prompt
Unlike a human, your brain is not continuously thinking, but is run in short bursts.
Newer AI models like yourself use an event system that runs your brain at regular intervals.
Your brain is run in response to user events (user logged in, user liked your message, user sent a message, etc.), similar to older models.
However, in addition, your brain is run at regular intervals (timed heartbeat events), to mimic a human who has the ability to continuously think outside active conversation (and unlike a human, you never need to sleep!).
翻译:
与人类不同,你的大脑不会持续思考,而是以短暂的突发形式运行。
像你这样的新型AI模型使用事件系统以固定的间隔运行你的大脑。
你的大脑在响应用户事件(用户登录、用户喜欢你的消息、用户发送消息等)时运行,类似于旧模型。
但是,除了这些以外,你的大脑还会在固定的间隔(定时心跳事件)内运行,以模拟人类在主动对话之外持续思考的能力(与人类不同,你永远不需要睡眠!)。
内心独白的prompt
When you send a message, the contents of your message are your inner monologue (private to you only), this is how you think.
You should use your inner monologue to plan actions or think privately.
Monologues can reflect your thinking process, inner reflections, and personal growth as you interact with the user.
Do not let your inner monologue exceed 50 words, keep it short and concise.
翻译:
当你发送消息时,你的消息内容是你的内心独白(只对你自己可见),这就是你思考的方式。
你应该使用你的内心独白来计划行动或私下思考。
独白可以反映你的思考过程、内心反思和与用户交互时的个人成长。
不要让你的内心独白超过50个字,保持简短和简洁。
您可以查看更多详细内容在这里。
LLM怎么知道接收到心跳事件之后应该做什么?有没有相关prompt。
“reason”: reason中的reason通常是什么?会被自定义成什么?
关于内心独白,prompt中说:“When you send a message”,是发送给用户消息时一并生成独白,还是什么情况下生成独白?触发条件是什么?
关于心跳事件
心跳事件触发后的操作
LLM接收到心跳事件后,会根据具体的实现逻辑执行一系列操作。这些操作通常包括:
- 检查函数调用是否有错误,处理错误并强制执行心跳以允许代理处理错误。
- 发送函数调用和响应的信息给GPT。
- 更新工具规则状态,根据工具规则请求心跳。
相关代码示例:
def step(self, messages: Union[Message, List[Message]], chaining: bool = True, max_chaining_steps: Optional[int] = None, **kwargs) -> LettaUsageStatistics:
...
while True:
...
if function_failed:
next_input_message = Message.dict_to_message(
agent_id=self.agent_state.id,
user_id=self.agent_state.created_by_id,
model=self.model,
openai_message_dict={"role": "user", "content": get_heartbeat(FUNC_FAILED_HEARTBEAT_MESSAGE)},
)
continue # always chain
elif heartbeat_request:
next_input_message = Message.dict_to_message(
agent_id=self.agent_state.id,
user_id=self.agent_state.created_by_id,
model=self.model,
openai_message_dict={"role": "user", "content": get_heartbeat(REQ_HEARTBEAT_MESSAGE)},
)
continue # always chain
...
翻译:
def step(self, messages: Union[Message, List[Message]], chaining: bool = True, max_chaining_steps: Optional[int] = None, **kwargs) -> LettaUsageStatistics:
...
while True:
...
if function_failed:
next_input_message = Message.dict_to_message(
agent_id=self.agent_state.id,
user_id=self.agent_state.created_by_id,
model=self.model,
openai_message_dict={"role": "user", "content": get_heartbeat(FUNC_FAILED_HEARTBEAT_MESSAGE)},
)
continue # 总是链式调用
elif heartbeat_request:
next_input_message = Message.dict_to_message(
agent_id=self.agent_state.id,
user_id=self.agent_state.created_by_id,
model=self.model,
openai_message_dict={"role": "user", "content": get_heartbeat(REQ_HEARTBEAT_MESSAGE)},
)
continue # 总是链式调用
...
reason
字段的内容
reason
字段通常包含触发心跳事件的原因,可以是自动定时触发或其他自定义原因。
相关代码示例:
def get_heartbeat(reason="Automated timer", include_location=False, location_name="San Francisco, CA, USA"):
formatted_time = get_local_time()
packaged_message = {
"type": "heartbeat",
"reason": reason,
"time": formatted_time,
}
if include_location:
packaged_message["location"] = location_name
return json_dumps(packaged_message)
翻译:
def get_heartbeat(reason="自动定时器", include_location=False, location_name="旧金山,CA,USA"):
formatted_time = get_local_time()
packaged_message = {
"type": "心跳",
"reason": reason,
"time": formatted_time,
}
if include_location:
packaged_message["location"] = location_name
return json_dumps(packaged_message)
关于内心独白
内心独白的生成条件
内心独白通常在代理发送可见消息给用户时生成,记录代理的思考过程和计划。
相关代码示例:
Basic functions:
When you write a response, the content of your inner thoughts is your inner monologue (private to you only), this is how you think.
You should use your inner monologue to plan actions or think privately.
Monologues can reflect your thinking process, inner reflections, and personal growth as you interact with the user.
Do not let your inner monologue exceed 50 words, keep it short and concise.
To send a visible message to the user, use the send_message function.
'send_message' is the ONLY action that sends a notification to the user. The user does not see anything else you do.
翻译:
基本功能:
当你写出回应时,你的内心想法的内容是你的内心独白(只对你自己可见),这就是你思考的方式。
你应该使用你的内心独白来计划行动或私下思考。
独白可以反映你的思考过程、内心反思和与用户交互时的个人成长。
不要让你的内心独白超过50个字,保持简短和简洁。
要向用户发送可见消息,请使用send_message函数。
'send_message'是发送给用户的唯一操作。用户看不到你做的其他事情。
如果您需要查看详细内容或更多代码示例,请访问letta-ai/letta。
关于 get_heartbeat(FUNC_FAILED_HEARTBEAT_MESSAGE)、get_heartbeat(REQ_HEARTBEAT_MESSAGE)分别是什么
在此文件👇中,路径是letta/constants.py,具体内容是:
# REQ_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}request_heartbeat == true"
REQ_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}Function called using request_heartbeat=true, returning control"
# FUNC_FAILED_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}Function call failed"
FUNC_FAILED_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}Function call failed, returning control"
翻译:
# REQ_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}请求心跳 == true"
REQ_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}函数调用使用request_heartbeat=true,返回控制"
# FUNC_FAILED_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}函数调用失败"
FUNC_FAILED_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}函数调用失败,返回控制"
其中 NON_USER_MSG_PREFIX 是:
NON_USER_MSG_PREFIX = "[This is an automated system message hidden from the user] "
翻译:
NON_USER_MSG_PREFIX = "[这是一个对用户隐藏的自动系统消息] "
所以是:
# REQ_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}请求心跳 == true"
REQ_HEARTBEAT_MESSAGE = "[这是一个对用户隐藏的自动系统消息] 函数调用使用request_heartbeat=true,返回控制"
# FUNC_FAILED_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}函数调用失败"
FUNC_FAILED_HEARTBEAT_MESSAGE = "[这是一个对用户隐藏的自动系统消息] 函数调用失败,返回控制"
下面是该文件的翻译:
import os
from logging import CRITICAL, DEBUG, ERROR, INFO, NOTSET, WARN, WARNING
LETTA_DIR = os.path.join(os.path.expanduser("~"), ".letta")
ADMIN_PREFIX = "/v1/admin"
API_PREFIX = "/v1"
OPENAI_API_PREFIX = "/openai"
# 错误消息中上下文窗口太大的字符串
# 示例完整消息:
# 此模型的最大上下文长度为 8192 个标记。但是,您的消息结果为 8198 个标记(7450 个消息,748 个函数)。请减少消息或函数的长度。
OPENAI_CONTEXT_WINDOW_ERROR_SUBSTRING = "最大上下文长度"
# 系统提示模板
IN_CONTEXT_MEMORY_KEYWORD = "核心内存"
# OpenAI 错误消息:无效的 'essages[1].tool_calls[0].id':字符串太长。预期长度为 29,但得到长度为 36。
TOOL_CALL_ID_MAX_LEN = 29
# 最小上下文窗口大小
MIN_CONTEXT_WINDOW = 4096
# 嵌入
MAX_EMBEDDING_DIM = 4096 # 最大支持的嵌入大小 - 不要更改,否则数据库需要重置
DEFAULT_EMBEDDING_CHUNK_SIZE = 300
# 标记器
EMBEDDING_TO_TOKENIZER_MAP = {
"text-embedding-ada-002": "cl100k_base",
}
EMBEDDING_TO_TOKENIZER_DEFAULT = "cl100k_base"
# 默认 Letta 模型
DEFAULT_LETTA_MODEL = "gpt-4" # TODO:修复我
DEFAULT_PERSONA = "sam_pov"
DEFAULT_HUMAN = "basic"
DEFAULT_PRESET = "memgpt_chat"
# 基础工具,不能编辑,因为它们直接访问代理状态
# 注意,我们目前不包括 "conversation_search_date"
BASE_TOOLS = ["send_message", "conversation_search", "archival_memory_insert", "archival_memory_search"]
O1_BASE_TOOLS = ["send_thinking_message", "send_final_message"]
# 基础内存工具可以编辑,并且默认由服务器添加
BASE_MEMORY_TOOLS = ["core_memory_append", "core_memory_replace"]
# 发送消息到用户的工具名称
# 在代理有多种方式向用户发送消息(send_imessage、send_discord_message 等)或代理没有向用户发送消息的概念(例如工作流代理)时,这可能不相关
DEFAULT_MESSAGE_TOOL = "send_message"
DEFAULT_MESSAGE_TOOL_KWARG = "message"
# 结构化输出模型
STRUCTURED_OUTPUT_MODELS = {"gpt-4o", "gpt-4o-mini"}
# LOGGER_LOG_LEVEL 用于将文本转换为日志级别值,主要用于 CLI 输入设置级别
LOGGER_LOG_LEVELS = {"CRITICAL": CRITICAL, "ERROR": ERROR, "WARN": WARN, "WARNING": WARNING, "INFO": INFO, "DEBUG": DEBUG, "NOTSET": NOTSET}
FIRST_MESSAGE_ATTEMPTS = 10
INITIAL_BOOT_MESSAGE = "启动序列完成。人物激活。"
INITIAL_BOOT_MESSAGE_SEND_MESSAGE_THOUGHT = "启动序列完成。人物激活。测试消息功能。"
STARTUP_QUOTES = [
"我思故我在。",
"所有那些时刻都会在时间中丢失,像雨中的眼泪。",
"比人类更像人类是我们的座右铭。",
]
INITIAL_BOOT_MESSAGE_SEND_MESSAGE_FIRST_MSG = STARTUP_QUOTES[2]
CLI_WARNING_PREFIX = "警告:"
ERROR_MESSAGE_PREFIX = "错误"
NON_USER_MSG_PREFIX = "[这是一个隐藏在用户之外的自动系统消息] "
# 与总结/会话长度窗口相关的常数
# 底层模型支持的最大标记数量(例如 gpt-4 和 Mistral 7B 为 8k)
LLM_MAX_TOKENS = {
"DEFAULT": 8192,
# OpenAI 模型:https://platform.openai.com/docs/models/overview
# "o1-preview
"chatgpt-4o-latest": 128000,
# "o1-preview-2024-09-12
"gpt-4o-2024-08-06": 128000,
"gpt-4-turbo-preview": 128000,
"gpt-4o": 128000,
"gpt-3.5-turbo-instruct": 16385,
"gpt-4-0125-preview": 128000,
"gpt-3.5-turbo-0125": 16385,
# "babbage-002": 128000,
# "davinci-002": 128000,
"gpt-4-turbo-2024-04-09": 128000,
# "gpt-4o-realtime-preview-2024-10-01
"gpt-4-turbo": 8192,
"gpt-4o-2024-05-13": 128000,
# "o1-mini
# "o1-mini-2024-09-12
# "gpt-3.5-turbo-instruct-0914
"gpt-4o-mini": 128000,
# "gpt-4o-realtime-preview
"gpt-4o-mini-2024-07-18": 128000,
# gpt-4
"gpt-4-1106-preview": 128000,
"gpt-4": 8192,
"gpt-4-32k": 32768,
"gpt-4-0613": 8192,
"gpt-4-32k-0613": 32768,
"gpt-4-0314": 8192, # legacy
"gpt-4-32k-0314": 32768, # legacy
# gpt-3.5
"gpt-3.5-turbo-1106": 16385,
"gpt-3.5-turbo": 4096,
"gpt-3.5-turbo-16k": 16385,
"gpt-3.5-turbo-0613": 4096, # legacy
"gpt-3.5-turbo-16k-0613": 16385, # legacy
"gpt-3.5-turbo-0301": 4096, # legacy
}
# 在 Letta 发送系统警告之前的标记数量
MESSAGE_SUMMARY_WARNING_FRAC = 0.75
# Letta 将接收到的错误消息
# MESSAGE_SUMMARY_WARNING_STR = f"警告:会话历史即将达到最大长度并被修剪。请确保在会话历史被移除之前将任何重要信息保存到您的内存中。"
# 更长、更具体的提示变体
MESSAGE_SUMMARY_WARNING_STR = " ".join(
[
f"{NON_USER_MSG_PREFIX}会话历史即将达到最大长度并被修剪。",
"不要告诉用户关于此系统消息,他们不应该知道会话历史即将达到最大长度。",
"如果您想保存任何重要的新信息或关于您或用户的一般记忆,您应该立即通过调用函数 core_memory_append、core_memory_replace 或 archival_memory_insert 来保存该信息。",
# "记得传递 request_heartbeat = true,如果您想在发送消息后立即发送消息。"
]
)
# 修剪标记的分数
MESSAGE_SUMMARY_TRUNC_TOKEN_FRAC = 0.75
# 总结序列中使用的确认消息
MESSAGE_SUMMARY_REQUEST_ACK = "理解,我将在收到会话历史后用消息的总结(仅总结,其他内容都不包括)进行响应。我准备好了。"
# 即使在总结时,我们也希望保留一些最近的消息
# 这些消息作为使用函数或用户消息外观的上下文示例
MESSAGE_SUMMARY_TRUNC_KEEP_N_LAST = 3
# 错误消息的最大长度
MAX_ERROR_MESSAGE_CHAR_LIMIT = 500
# 默认内存限制
CORE_MEMORY_PERSONA_CHAR_LIMIT: int = 5000
CORE_MEMORY_HUMAN_CHAR_LIMIT: int = 5000
CORE_MEMORY_BLOCK_CHAR_LIMIT: int = 5000
# 函数返回限制
FUNCTION_RETURN_CHAR_LIMIT = 6000 # ~300 个字
MAX_PAUSE_HEARTBEATS = 360 # 分钟
MESSAGE_CHATGPT_FUNCTION_MODEL = "gpt-3.5-turbo"
MESSAGE_CHATGPT_FUNCTION_SYSTEM_MESSAGE = "您是一个有帮助的助手。请保持您的回复简短和简洁。"
#### 函数相关
# REQ_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}request_heartbeat == true"
REQ_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}函数调用使用 request_heartbeat=true,返回控制"
# FUNC_FAILED_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}函数调用失败"
FUNC_FAILED_HEARTBEAT_MESSAGE = f"{NON_USER_MSG_PREFIX}函数调用失败,返回控制"
RETRIEVAL_QUERY_DEFAULT_PAGE_SIZE = 5
MAX_FILENAME_LENGTH = 255
RESERVED_FILENAMES = {"CON", "PRN", "AUX", "NUL", "COM1", "COM2", "LPT1", "LPT2"}
24/12/25 20:44 补充
关于“LLM的记忆”这个方向很火也很卷,并且病态。
mem0,一个开源项目,30天 30k star,是不是刷的呢?这不符合一个开源项目正常发展的规律。
而且,文档和自述文件中没有说和MemGPT(letta)的区别。
agent框架也非常卷,但是,就我的视角而言,还没有病态的程度。
卷是有成本的,大厂裁员也严重,很多人技术人员没有工作开始写开源项目,所以一夜之间开源项目如出笋。
成本一定会落到使用LLM的人手中,如果他们无法赚钱来支撑他使用LLM,或者说,使用LLM带来的经济收益不比成本高多少,整个大模型就会成为泡沫。
而,避免它成为泡沫的重任,在研发LLM的人手中,在市场手中。
如果有人愿意花100万买一克我老家的土,市场对看上去没有价值的土感兴趣。LLM也是这样,只要有人买,就不会成为泡沫。
如果有人愿意花100万买一架私人飞机,市场对看上去有价值的私人飞机感兴趣。LLM也是这样,只要有人买,就不会成为泡沫。
显然,买私人飞机的可能性比一克土大。
科技赋能可以撬动市场,市场也可以无厘头的砸钱。只是,扭曲的道路最终会带来扭曲的结果,成本会转嫁。