基于AIGC构建本地知识库问答 - 文本切割粒度考量

粗粒度的文本被检索出来之后给大模型参考,大模型总会被文本中的无关信息干扰; 而细粒度的文本,检索出来的信息可能不全,缺少上下文信息,导致大模型没法给出正确答案。那么在工程中如何平衡切割文本的长短呢?

一、背景

使用AIGC构建本地知识库的其中一个步骤就是切割文本(chunk),其中一个核心的参数便是控制文本切割的粒度,这直接关系到Q&A环节的回答质量。

粗粒度的文本被检索出来之后给大模型参考,大模型总会被文本中的无关信息干扰; 而细粒度的文本,检索出来的信息可能不全,缺少上下文信息,导致大模型没法给出正确答案。那么在工程中如何平衡切割文本的长短呢?

二、基本准则

首先,以你使用的Text模型的最大上下文Token为上限,比如使用GPT-4K模型,那么文本切分粒度天然限制就不能超过4K,大模型根本就无法接受超过最大Token限制的文本内容,这是上限!那么最小是多少?为了保证检索出来的信息是完整的,确保有足够的上下文,从以往的经验来看,不能少过50-100 Token吧,不然大模型也没办法给出准确的答案。

那么再100-大模型Token上限的这个范围,如何具体确定你的切割粒度?那这个又跟你的Q&A期望相关了。如果你是做检索类型的任务,期待查询的返回是500字以内的反馈,那么400-600的Token切割数量是合适的。如果是你是做总结类型的任务,那么切片要大一点比较好,比如500,1000Token数量,这样才能归纳总结的全面准确一点。

三、其它考量

  • 考虑上下文:确保即使在细粒度的文本中,也要保存足够的上下文信息。例如,如果你选择句子为单位,那么可能考虑将前后的句子也加入,形成一个段落,以便为大模型提供上下文。

  • 采用动态窗口:在检索时,可以采用动态的窗口大小,即根据检索到的关键信息动态调整文本切割的范围。这样可以确保即使在细粒度中也能提供足够的上下文。

结合多粒度策略:在检索或其他任务中,可以考虑同时使用多个文本粒度。例如,首先使用粗粒度获取大致的范围,然后在该范围内使用细粒度进一步检索。

四、总结

基于基本准则和其它考量因素,较好的办法是"调试",通过调整切割文本粒度,验证问题得出答案的准确性,匹配适合你提供的知识域的切割粒度,即不同的知识域应该给予相匹配的文本切割粒度。

相关推荐
仙人掌_lz6 小时前
利用python从零实现Byte Pair Encoding(BPE):NLP 中的“变形金刚”
开发语言·python·gpt·自然语言处理·llm·token·deepseek
Justin3go8 小时前
谷歌 Agent2Agent(A2A)协议深度调研报告
google·openai·mcp
姚瑞南14 小时前
【Prompt实战】结构化 Prompt 高质量模板
人工智能·chatgpt·prompt·aigc
ai大师14 小时前
开源智能体MetaGPT记忆模块解读
gpt·claude·metagpt·中转api·apikey·中转apikey·免费apikey
大鹏dapeng14 小时前
使用 gone.WrapFunctionProvider 快速接入第三方服务(下)—— LLM接入支持 openAI 和 deepseek
go·openai·deepseek
量子位15 小时前
字节开源新生图模型:一个模型统一所有生图任务,多主体融合效果 SOTA
人工智能·llm·aigc
zidea15 小时前
MCP SDK 源码随处可见的 Python 上下文管理器,优雅的资源管理利器
人工智能·aigc·mcp
新智元16 小时前
勇克 FPGA 难题!UCLA 丛京生教授斩获 2024 年 ACM 计算突破奖
人工智能·openai
新智元16 小时前
谷歌最强 AI 芯片狙击英伟达 B200,性能狂飙 3600 倍!谷歌版 MCP 一统 AI 智能体宇宙
人工智能·openai
机器之心16 小时前
MoE 模型已成新风口,AI 基础设施竞速升级
人工智能·openai