Ragas结合Ollama生成RAG测试集时脚本挂起的调试方案咨询

看起来你在使用Ragas搭配Ollama生成RAG测试集的时候，卡在了KnowledgeGraph最后一个节点的处理上，这种卡壳的情况确实挺闹心的，我来给你分享几个实用的调试思路，帮你定位问题所在：

一、先排查Ollama服务本身的可用性 #

咱们先把最基础的环节排查清楚，避免在复杂逻辑里绕圈：

• 先单独测试Ollama LLM能不能正常响应，写个极简的调用脚本试试：

  response = ollama_llm.invoke("Hello, can you give me a quick response?")
  print(response)
  

  如果这个调用都卡，那问题肯定出在Ollama服务或者模型上。
• 查看Ollama的实时日志，在终端运行ollama logs，重点看处理最后一个节点时有没有超时、资源不足或者模型加载失败的报错信息。
• 确认llama3.2:1b模型是完整可用的，有时候中途中断下载会导致模型损坏，可尝试重新拉取：ollama pull llama3.2:1b

二、开启Ragas的调试日志，追踪执行细节 #

给Ragas加上DEBUG级别的日志，就能清楚看到ThemesExtractor处理每个节点的全过程，到底是卡在了LLM调用，还是数据处理环节：
在脚本开头加上这段代码：

import logging
logging.basicConfig(level=logging.DEBUG)

运行后你能看到每一步的执行日志，比如是不是在等待LLM返回结果，还是在处理节点数据时陷入了死循环。

三、简化测试场景，缩小排查范围 #

把复杂场景拆成小单元测试，能快速定位问题根源：

• 先创建一个只有1-2个节点的极小KnowledgeGraph，看看是不是还会卡在最后一个节点，排除是节点数据量过大导致的内存或处理超时问题。
• 暂时把max_num_themes改成1，看看主题提取能不能正常返回，排除是多主题提取逻辑的问题。
• 换个LLM试试，比如暂时用Ragas内置的其他LLM（如果有可用的API），或者换个更轻量化的Ollama模型（比如qwen2:0.5b），排查是不是特定模型和Ragas的兼容性问题。

四、检查异步调用的上下文是否正确 #

你用了await theme_extractor.transform(kg=kg)，要确保你的脚本是在合法的异步上下文中运行的，比如：

import asyncio
async def main():
    await theme_extractor.transform(kg=kg)

asyncio.run(main())

如果异步调用没有正确的上下文支撑，很容易导致程序挂起等待。

五、监控系统资源使用情况 #

有时候资源耗尽也会导致程序卡住：

• 运行脚本时打开任务管理器（Windows）或活动监视器（Mac），观察CPU、内存、GPU的使用率，如果Ollama把资源占满了，程序自然没法继续执行，这种情况下可以关掉其他占用资源的程序，或者换个资源需求更低的模型。
• 检查Ollama的配置文件（一般在~/.ollama/config.json），看看是不是设置了过小的上下文窗口，比如可以尝试修改num_ctx参数扩大上下文：

  {
      "num_ctx": 8192
  }
  

修改完记得重启Ollama服务：ollama restart

内容来源于stack exchange