-
-
Notifications
You must be signed in to change notification settings - Fork 171
Open
Labels
enhancementNew feature or requestNew feature or request
Description
Describe the feature
Suggestions for RAG System Functionality
-
If the text segments of an entry are too long, the semantic meaning of keywords can easily be diluted, leading to lower ranking during retrieval. If the text segments are too short, while retrieval may be precise, context is easily lost, resulting in incomplete information recall. Therefore, it is recommended to use a parent-child chunking approach.
-
The current grouping method is too simplistic and does not fully meet the needs of practical development. For example:
- Knowledge entries should be categorizable, such as worldviews, common knowledge, NPC-specific memories, legends, etc. Currently, during retrieval, there is only a single group search, which is too simplistic. To achieve effects like: for common knowledge questions, every NPC should know the answer, and retrieval should be possible without grouping; for NPC-exclusive information, the current API interface requires two separate searches: one with Search(text, 5, "public") and another with Search(text, 5, "npcid").
- For legendary knowledge entries, it is recommended to allow probability settings for NPCs knowing certain information. For example, there is a treasure in the mountains, and 20% of NPCs know about this legend, requiring players to explore and discover it themselves. Of course, as the storyline progresses, one NPC might share this information with another, or players could directly inform an NPC.
- For event-based knowledge entries, it is suggested to introduce importance decay. For instance, as the storyline advances and more events occur, the memory entries of NPCs increase. When the number reaches a certain threshold, during retrieval, if you request the top 5 results, the importance of some entries should decrease; otherwise, they will occupy the top 5 slots excessively.
- For entries that have already been stored, there should be an opportunity to modify them. For example, according to the storyline, an NPC might initially misunderstand an event and later have that misunderstanding resolved. In such cases, the entry should be modifiable or recreatable.
关于RAG系统功能的建议
- 如果条目文本分段很长,则关键词语义很容易被稀释,导致召回时排名不靠前,如果文本条目太短,则检索虽然精确,但很容易丢失上下文,导致信息召回不全。因此,建议使用父子分段方式。
2.现有的分组方式太过简单,不太满足实际开发时的需要,比如:
- 知识条目应该可以被分类,比如游戏里世界观、常识、NPC自己独有的记忆、传说等。在检索时,目前只有一个分组检索,太过简单,如果想要实现这样的效果:对于常识问题,是每个NPC都应该知道的事,不需要分组就能查到;然后是对于某NPC独有的分组信息。目前的API接口,要实现这个,只能分别调用两次Search,一次是Search(text, 5, "public"),一次是Search(text, 5, "npcid")。
- 对于传说类知识条目,建议允许设置NPC知道某件事的概率。比如,山上有一个宝藏,20%的NPC知道这个传说,需要玩家自己去探索。当然,随着剧情发展,某个NPC可能告诉另一个NPC,或玩家也可以直接告诉某个NPC。
- 对于事件类的知识条目,建议增加重要性衰减。比如,随着剧情推进,事件越来越多,NPC的记忆条目会增加,当达到某个数量后,进行检索时,假设你要TOP5,那么,某些条目重要性应该降低,要不然就会挤占TOP5名额。
- 对于已经存入的条目,应该有机会能够再修改它。比如,按照剧情设定,某个NPC可能对某件事有误解,后来解除了误会,那么条目应该可以被修改或者重建。
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request