cognee Token 成本分析:用代表性分块估算持久记忆 vs 全上下文提示的 Token 开销

发布时间:2026/9/11 8:03:15
cognee Token 成本分析:用代表性分块估算持久记忆 vs 全上下文提示的 Token 开销 cognee Token 成本分析用代表性分块估算持久记忆 vs 全上下文提示的 Token 开销【免费下载链接】cogneeCognee is the open-source AI memory platform for agents. Give your AI agents persistent long-term memory across sessions with a self-hosted knowledge graph engine.项目地址: https://gitcode.com/GitHub_Trending/co/cognee本文是 cognee 开源仓库中 token_usage_analysis 评测模块的完整技术解读。它回答一个实际部署中最关心的问题对于同一批语料、同一组重复查询把整份语料每次都塞进上下文full-context prompting与先用cognee.remember()建好知识图谱、之后每次只取一小段检索上下文cognee persistent memory相比Token 成本何时出现交叉、何时 cognee 开始显著节省。读完本文你将掌握其成本模型与削减里程碑公式、四个语料密度档位的实测结论、命令行工具的完整用法以及底层analyze.py测量管线的源码级原理可以直接在自己的语料上复现同样的成本估算。为什么需要测量一次摄入长期受益的 Token 经济学对同一个固定语料反复回答查询两种策略的累计 Token 成本都是查询次数的线性函数full-context: queries × (corpus_tokens query_overhead) cognee: ingestion_tokens queries × retrieved_contextingestion_tokenscognee.remember()的一次性成本包括对每个分块做摘要summarize与图谱抽取graph extraction。它按代表性子分块实测后按语料规模放大ingestion_tokens multiplier × corpus_tokens其中multiplier是每内容 Token 的实测摄入 Token 数。retrieved_contextcognee.recall()每次查询打包给模型的近似恒定上下文典型值为 1118 Token。query_overhead每次查询的指令包装与问题本身的 Token 数默认 32。由于 cognee 有一次性摄入成本而全上下文没有两者曲线必然在某个查询数处相交——这就是parity平价点。基于该模型每个削减里程碑reduction milestone回答的问题是累计全上下文成本达到 cognee 累计成本含一次性摄入的factor倍时已经过了多少次重复查询queries(factor) factor × ingestion_tokens / ((corpus_tokens query_overhead) − factor × retrieved_context)factor 1即平价点两条曲线交叉处7里程碑表示此时全上下文已花掉 cognee 7 倍的输入/上下文 Token即 cognee 在该点少用了 7 倍输入 Token。没有任何一个里程碑天然更特殊——平价点只是其中之一。该公式的推导与实现位于 cost_model.py其中queries_for_reduction在分母 0时返回None表示该因子不可达cognee 单次查询成本本身已超过目标。值得注意的是Token 用量直接读取真实 LLM 响应的usage字段prompt completion因此指令包装与 Pydantic 图谱 schema 的开销都被如实计入没有任何估算常量。这一点在 measure.py 中实现兼容 litellm 的prompt_tokens/completion_tokens与 Anthropic 客户端的input_tokens/output_tokens两种命名。实测结果密度谱系上的四个档位测量条件openai/gpt-5-mini每个语料采样 3 个分块retrieved_context 1118query_overhead 32每个语料约 1 万~1.2 万 Token。整个谱系在两种分块大小下各跑一遍cognee 默认的8191与减半的4095。表中数值依次为图谱输出 ÷ 输入/摄入乘数/平价点查询次数。档位来源语料 Token 数chunk 8191chunk 4095小说 Fiction《战争与和平》节选10,5042.8× / 5.7× / ~64.5× / 8.0× / ~9新闻 NewsWikinews23 篇10,1614.2× / 7.3× / ~85.9× / 9.8× / ~11百科 EncyclopedicWikipedia——《阿波罗 11 号》10,0373.4× / 6.5× / ~75.9× / 10.3× / ~12稠密合成 Dense synthetic基准集people_raw12,0099.3× / 12.0× / ~1310.1× / 14.0× / ~15这些数字背后是三个稳健的结论摄入乘数与图谱输出比同向变动平价点随乘数变动——与成本模型的预测完全一致。稠密合成语料每个输入 Token 产出约 9~10× 的图谱输出普通散文只有约 3~6×。真实文本聚在低位。小说、新闻、百科类散文的平价点落在个位数到低两位数稠密合成语料才是离群值。此前技术笔记中约 23~26 次查询的结论反映的是这个稠密离群值且使用了更大的摄入分块并不代表典型输入。分块大小同样重要。分块减半会抬升所有比率与乘数因为更小的分块按内容 Token 分摊了比例更高的固定 prompt/schema 开销。同一语料、同一模型平价点却不同。单次运行的代表性说明这些是单次运行的结果而图谱抽取并非完全确定性其输出长度在不同运行间有波动稠密语料波动最大8191 分块的一次重复运行就把乘数移动了好几个百分点。因此应把这些数字视为代表性而非精确值稳健的结论是档位之间的排序。每个档位的累计成本交叉图与逐分块 JSON 存放在results/chunk_8191/与results/chunk_4095/。例如百科档位在 8191 分块下的完整报告wikipedia.json显示摄入乘数 6.482、平价点 7.3 次查询、2× 里程碑 16.6 次、7× 里程碑 203.0 次、10× 里程碑不可达——直观展示了平价之后 cognee 的优势随时间加速扩大的曲线形态。对应的交叉图由 plot.py 从报告中的四个数字直接重绘纵轴为累计 Token、横轴为查询次数并标注平价点位置使用方法在自己语料上跑一次成本估算安装项目含评测依赖后在该目录内执行命令uv sync --dev --all-extras cd cognee/eval_framework/token_usage_analysis脚本会加载仓库根目录的.env请确保其中包含可用的LLM_PROVIDER、LLM_MODEL与 API key。若省略--llm-models则使用.env中配置的LLM_MODEL。# 单个代表性文件该输入整体被视为语料 uv run python analyze.py --file data/wikipedia_article.txt --plot # 一个目录里的 .txt 文件合并后采样 uv run python analyze.py --dir some_corpus/ --out report.json # 单个代表性分块语料大小必须显式给出 uv run python analyze.py --text $(cat one_chunk.txt) --corpus-tokens 200000脚本用 cognee 的TextChunker对输入分块采样少量分块--samples默认 3让每个分块依次经过cognee.remember()的摘要与图谱抽取调用并记录真实 Token 用量最后写出 JSON 报告。加--plot会额外写出累计成本交叉图matplotlib已包含在evalsextra 中。上述输入解析逻辑见 corpus.py 的read_source。关键参数一览参数默认值含义--file/--dir/--text—输入形式三者必选其一互斥--samples3参与测量的分块数--llm-models.env中的模型逗号分隔列表逐个运行并切换 cognee 配置--corpus-tokens输入的 Token 数用于对比的语料大小与--text搭配时必填--retrieved-context1118每次查询的 recall 上下文--query-overhead32每次查询的指令 问题 Token--reduction-factors1,2,7,10需要报告的里程碑1 平价点--plot/--plot-dir关 /.同时输出交叉图--max-chunk-size4095分块上限传8191以匹配 cognee 默认值--seed42采样随机种子保证可复现其中--reduction-factors支持浮点并自动将整数值归一为整数见 cli.py--llm-models缺省时回落到get_llm_config().llm_model若.env中也没有则直接报错退出cli.py。复现密度谱系实验谱系实验是每个分块大小 4 次单输入运行、手工汇总的结果。每个分块大小对应独立的结果目录for size in 8191 4095; do for tier in war_and_peace wikinews wikipedia dense; do uv run python analyze.py --file data/${tier}*.txt --max-chunk-size $size \ --out results/chunk_${size}/${tier}.json --plot --plot-dir results/chunk_${size} done done--max-chunk-size默认是4095传8191即 cognee 默认分块。--llm-models只会运行你有对应 key 的模型要对比多家提供商在.env中追加OPENAI_API_KEY/ANTHROPIC_API_KEY即可——脚本会在每次测量前切换LLM_PROVIDER、LLM_MODEL与LLM_API_KEY实现见 measure.py通过清除get_llm_config缓存使新配置生效。上述运行使用的是.env中配置的openai/gpt-5-mini。源码架构六个模块各司其职analyze.py是纯编排层每一步只调用一个聚焦模块见 analyze.py 的main读源 → 采样分块 → 逐模型测量 → 构建报告 → 写输出cli.py— 参数定义与默认值解析保持编排层干净。corpus.py— 输入 → 采样分块cogneeTextChunker。不涉及 LLM 与任何数学。它还做了一件关键的事把 chunker 的 tokenizer 指向本地 tiktoken 编码corpus.py使分块过程完全不需要 embedding 模型分块边界使用固定的gpt-4o编码决定与最终测量模型解耦。measure.py— 唯一的 LLM/IO 面让一个分块通过 cognee 的extract_summary与extract_content_graph真实调用见 measure.py逐模型记录真实 Token 用量多个模型串行执行之间切换 cognee 配置。cost_model.py— 纯算术FullContextQueryCost与CogneeQueryCost两个策略成本对象、平均分块、摄入放大、削减里程碑。其中的ChunkMeasurement数据类把图谱输出 ÷ 输入定义为密度信号graph_ratiocost_model.py这正是整个谱系实验的核心度量。report.py— 逐模型编排与 JSON 组装报告包含ingestion_multiplier、两种策略的逐查询成本、各削减里程碑、平均分块与逐分块明细。plot.py— 可选的累计成本交叉图matplotlib 惰性导入纯 JSON 运行不需要额外依赖它只消费报告里的四个数字重绘曲线不依赖成本模型本身。值得注意的是本地 Token 计数在 OpenAI 系使用 tiktoken 编码、在 Anthropic 系使用 litellm 的token_countermeasure.py确保输入 Token与语料 Token处于同一计量基准这正是摄入放大公式成立的前提。假设与边界条件恒定检索上下文。recall 上下文按每次查询固定处理在固定top_k下它随语料规模只缓慢增长。排除 Embedding。只统计语言模型 Tokenembedding 在本地计算不计入成本。代表性分块外推。摄入成本按采样分块的平均值放大隐含假设语料其余部分与采样分块密度相似——这正是要选代表性文件/分块的原因也是 README 建议在接近真实工作负载的文本上运行而非依赖单一合成语料的原因。数据与出处data/目录下的节选文本就是实际被摄入的原文data/war_and_peace_excerpt.txt— 《战争与和平》Project Gutenberg 电子书 #2600公有领域。data/wikipedia_article.txt— 英文维基百科《阿波罗 11 号》条目CC BY-SA 4.0。data/wikinews_article.txt— 23 篇近期英文 Wikinews 文章拼接至可比语料规模CC BY 2.5标题与来源 URL 清单见data/wikinews_sources.json。data/dense_synthetic.txt— 本仓库内基准集people_raw语料的节选。这些文本在 corpus.py 中通过 cognee 的TextChunker分块、以固定种子采样随后进入真实测量——因此文章中的所有数字都对应仓库内可复现的输入文件与命令行而非凭空给出的估算。【免费下载链接】cogneeCognee is the open-source AI memory platform for agents. Give your AI agents persistent long-term memory across sessions with a self-hosted knowledge graph engine.项目地址: https://gitcode.com/GitHub_Trending/co/cognee创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考