GraphRAG 生产配置：多模型策略怎么选，成本怎么控

同样跑 10 万文档索引，全用 GPT-4o 要 ，用混合模型策略只要14——质量几乎一样。

阅读提示

• 适合谁看：已经跑通 GraphRAG Demo、准备上生产或正在优化成本的实践者
• 看完能做什么：配出一套多模型 settings.yaml，知道 chunk_size 调大调小分别影响什么，能算清 ROI

先给结论

• extraction 用小模型（GPT-4o-mini），summarization 用大模型（GPT-4o），是性价比最高的方案
• chunk_size 不是越大越好，1200 tokens 是个不错的默认值，调之前先理解 trade-off
• 生产上路的核心原则：先用便宜模型验证配置，确认质量后再切生产模型

很多人第一次把 GraphRAG 跑通后，会面临一个现实问题：这东西到底要花多少钱？

10 万文档跑一次 standard 索引，全用 GPT-4o 大概要 $20-30。如果你还在调试配置、改 prompt、换 chunk_size，反复跑几轮，一个月的 API 预算可能就烧完了。

更麻烦的是，很多人不知道 GraphRAG 支持"多模型配置"——extraction、summarization、embedding 可以分别用不同的模型。这意味着你完全可以用便宜模型做 extraction（这一步调用次数最多），用大模型做 summarization（这一步对质量最敏感）。

这篇就讲清楚：settings.yaml 的核心配置怎么配，多模型策略的 ROI 怎么算，chunk_size 调优的 trade-off 是什么。

01 先看全局：settings.yaml 的配置架构

GraphRAG 的所有配置都集中在settings.yaml一个文件里。这个文件的结构不复杂，但有几个关键决策点会直接影响成本和质量。

图 1｜settings.yaml 核心配置项关系图

从架构图可以看到，settings.yaml 的核心配置分 6 个模块：

• models：定义 completion 模型和 embedding 模型，可以定义多个，按名称引用
• input：输入数据的格式和路径
• chunking：文本分块策略，直接影响索引质量
• output：输出存储位置
• vector_store：向量存储后端（默认 LanceDB）
• workflows：每个索引步骤可以独立指定使用哪个模型

关键设计：models下可以定义任意多个模型实例，然后在extract_graph、summarize_descriptions、embed_text等 workflow 里通过completion_model_id分别引用。这就是多模型策略的配置基础。

代码 1

# 定义两个 completion 模型completion_models: cheap_model: model_provider: openai model: gpt-4o-mini api_key: ${GRAPHRAG_API_KEY} quality_model: model_provider: openai model: gpt-4o api_key: ${GRAPHRAG_API_KEY}embedding_models: default_embedding_model: model_provider: openai model: text-embedding-3-large api_key: ${GRAPHRAG_API_KEY}# 在 workflow 里分别引用extract_graph: completion_model_id: cheap_model # extraction 用便宜模型 summarize_descriptions: completion_model_id: quality_model # summarization 用大模型community_reports: completion_model_id: quality_model # 社区报告也用大模型

02 多模型策略：ROI 怎么算

这是整篇最核心的问题。先看一张对比图。

图 2｜三种多模型策略成本对比

三种方案的对比基于 10 万文档索引的估算：

方案 A：全用 GPT-4o

• extraction 成本约 ，成本约8，总计约 $23
• 质量最高，但成本也最高
• 适合对质量零容忍、预算充裕的场景

方案 B（推荐）：extraction 用 GPT-4o-mini + summarization 用 GPT-4o

• extraction 成本降到约 （省8，总计约 $14
• 总成本降 39%，质量几乎无损
• 为什么？因为 extraction 是调用次数最多的步骤（每个 chunk 都要调），用小模型省的钱最多；而 summarization 是对质量最敏感的步骤，实体描述的合并和社区报告的生成直接影响查询质量

方案 C：全用 GPT-4o-mini

• 总成本约 $6，省 74%
• 但 extraction 质量可能下降（实体遗漏、关系不完整），summarization 质量也会下降
• 适合预算极度紧张、可以接受质量折损的场景

ROI 计算公式

ROI = (方案A成本 - 方案B成本) / 方案B质量损失= ($23 - $14) / ≈0% 质量损失= $9 纯省钱，质量几乎无损

经验判断：extraction 步骤对模型能力的要求没有 summarization 高。extraction 本质上是"从文本中识别实体和关系"，GPT-4o-mini 在这个任务上的表现已经足够好。而 summarization 需要"合并多段描述、提炼关键信息"，这一步大模型的优势更明显。

03 chunk_size：调大调小分别影响什么

chunk_size 是最容易被忽视但影响最大的配置项之一。

代码 2

chunking: type: tokens size: 1200 # 每个 chunk 的最大 token 数 overlap: 100 # 相邻 chunk 的重叠 token 数 encoding_model: cl100k_base

调大 chunk_size（比如 2000+）

• 优点：chunk 数量减少，LLM 调用次数减少，总成本降低
• 缺点：每个 chunk 内容更多，实体提取可能不完整（LLM 的注意力被分散）；跨 chunk 的实体合并更难
• 适合：文档结构清晰、实体密度低的场景

调小 chunk_size（比如 600）

• 优点：每个 chunk 更聚焦，实体提取更完整
• 缺点：chunk 数量翻倍，LLM 调用次数翻倍，成本翻倍；跨 chunk 的实体合并压力更大
• 适合：实体密度高、需要精确提取的场景

经验判断：1200 tokens 是个不错的默认值。如果你的文档是长篇技术文档（实体密度中等），1200 左右通常够用。如果是新闻短文（实体密度高），可以调到 800。如果是小说（实体密度低），可以调到 1500。

overlap 的作用：overlap 防止实体被切断在两个 chunk 的边界。100 tokens 的 overlap 意味着相邻 chunk 有约 100 个 token 的重叠区域。如果实体经常被切断，可以适当增大 overlap，但不要超过 chunk_size 的 15%。

04 向量存储配置：默认就够用

GraphRAG 默认用 LanceDB 做向量存储，本地开发完全够用。

代码 3

vector_store: type: lancedb # 默认，本地开发用 db_uri: output/lancedb # 存储路径 index_schema: text_unit_text: vector_size: 3072 # 必须匹配 embedding 模型的维度

生产环境如果需要更好的向量检索能力，可以换成 Azure AI Search：

vector_store: type: azure_ai_search url: https://your-search.search.windows.net api_key: ${AI_SEARCH_API_KEY}

最容易踩的坑：vector_size必须和你用的 embedding 模型输出维度一致。text-embedding-3-large输出 3072 维，text-embedding-3-small输出 1536 维。配错了不会报错，但查询时会出问题。

05 从开发到生产：部署流程

图 3｜从开发到生产的完整部署流程

整个流程分三个阶段：

开发阶段：用便宜模型 + 小数据集测试配置

# 初始化项目graphrag init --root ./myproject# 用小数据集测试# 把 input 目录里放 5-10 篇文档graphrag index --root ./myproject --method fast

验证阶段：评估索引质量，确认成本预算

• 跑完索引后检查output/下的 parquet 文件
• 看entities.parquet的实体数量是否合理
• 看relationships.parquet的关系是否完整
• 看community_reports.parquet的社区报告是否准确

# 用 query 命令测试graphrag query --root ./myproject --method local "你的测试问题"graphrag query --root ./myproject --method global "你的全局问题"

生产阶段：切换生产模型，全量索引

确认质量达标后，在 settings.yaml 里把模型换成 GPT-4o，调整并发和 rate_limit，跑全量索引。

三个判断节点是关键：配置正确吗？质量达标吗？成本预算够吗？任何一步不通过，都要回到上游调整。

06 Prompt Tuning：生产前必做的一步

Prompt Tuning 不是可选的。默认 prompt 是通用的，对你的数据领域不一定最优。

# 自动调优（推荐）graphrag prompt-tune --root ./myproject --domain "你的领域"# 限制 token 预算graphrag prompt-tune --root ./myproject --max-tokens 2000

Prompt Tuning 会从你的数据中采样，生成适合你领域的实体类型和关系类型。这一步能显著提升 extraction 质量，尤其是在非英文文档场景下。

07 CLI 命令速查

图 4｜settings.yaml 关键配置项速查图

08 最容易踩的坑

坑 1：rate_limit 没设置

GraphRAG 默认没有 rate limiting。如果你的文档量大，extraction 阶段会并发调用 LLM，很容易触发 API 的 429 限流。

completion_models: cheap_model: model_provider: openai model: gpt-4o-mini rate_limit: requests_per_period: 60 tokens_per_period: 100000

坑 2：max_gleanings 默认是 1

max_gleanings控制 extraction 的"反复确认"次数。默认 1 意味着 LLM 只提取两次。对复杂文档，可以调到 2-3，但会增加成本。

坑 3：o-series 模型不兼容

GraphRAG 2.2.0+ 支持 o-series 模型（o1, o3），但这些模型有推理 token 消耗，成本会比预期高。而且 o-series 模型有原生的 chain-of-thought，GraphRAG 的 prompt 里也有 CoT，两层 CoT 叠加可能反而降低效果。如果用 o-series，建议重写 prompt。

坑 4：chunk_size 和 prompt-tune 的 chunk-size 不一致

graphrag prompt-tune --chunk-size会覆盖settings.yaml里的chunking.size。如果 prompt tuning 时用 1200，但 settings.yaml 里写 600，prompt 就不适合你的 chunk 大小。

09 什么时候该用，什么时候别急着上

更适合 GraphRAG 生产配置的场景：

• 文档量超过 1 万篇，传统 RAG 的检索质量不够
• 需要回答实体关系类问题（“X 和 Y 什么关系”）
• 有预算做 Prompt Tuning 和质量评估
• 能接受 2-3 天的索引时间

不适合的场景：

• 文档量少于 1000 篇，传统 RAG 够用
• 只需要文本匹配，不需要图谱结构
• 预算极度紧张，连 GPT-4o-mini 都觉得贵
• 没有时间做 Prompt Tuning

3 问判断法

1. 你的文档量是否超过 1 万篇？
2. 你的查询是否需要实体关系信息？
3. 你是否有 $15+ 的 API 预算做一次全量索引？

如果 3 个问题大多是肯定的，值得上 GraphRAG 生产配置。如果大多是否定的，先用传统 RAG。

决策帮助

• 如果你正在从零开始：先用graphrag init生成默认配置，用 5 篇文档 + GPT-4o-mini 跑通 fast 索引
• 如果你已经在用单模型：把 extraction 切到 GPT-4o-mini，观察质量变化，大概率不会下降
• 如果你最关心成本：方案 B（混合模型）是最佳选择，省 39% 成本，质量几乎无损
• 如果你只能先做一步：先做 Prompt Tuning，这一步的 ROI 最高

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】