LlamaIndex项目异步任务处理中的嵌套事件循环问题解析

在基于FastAPI和LlamaIndex构建的后端服务中，开发人员经常会遇到"Detected nested async"的错误提示。这个问题源于Python异步编程模型与同步代码的混合使用，特别是在后台任务处理场景下。

问题本质分析

当使用FastAPI的BackgroundTasks功能执行LlamaIndex评估任务时，系统会检测到嵌套的异步事件循环。这是因为：

1. FastAPI本身运行在异步事件循环中
2. 后台任务调用了同步的LlamaIndex评估方法(evaluate)
3. 评估方法内部又尝试启动新的事件循环

这种架构违反了Python异步编程的基本原则——避免在已有事件循环中创建新的事件循环。

技术解决方案

方案一：统一异步化改造

最规范的解决方法是保持调用链的异步一致性：

async def llama_index_evaluate(dataset):
    llm = Ollama("qwen2.5:7b", base_url="http://localhost:11434", request_timeout=500)
    evaluator = CorrectnessEvaluator(llm=llm)
    results = []
    for row in dataset.itertuples():
        result = await evaluator.aevaluate(
            query=row.question,
            response=row.answer,
            reference=row.ground_truth,
        )
        results.append(result.score)
    dataset["answer_correctness"] = results
    return dataset

方案二：使用专用线程池

对于必须保留同步代码的场景，可以隔离同步任务到独立线程：

from concurrent.futures import ThreadPoolExecutor

executor = ThreadPoolExecutor(max_workers=4)

def evaluate_in_thread(dataset):
    # 同步评估代码
    return llama_index_evaluate(dataset)

async def handle_evaluation_request():
    loop = asyncio.get_event_loop()
    await loop.run_in_executor(executor, evaluate_in_thread, dataset)

性能考量

1. 异步方案：更高效利用CPU资源，适合IO密集型任务，但需要重构整个调用链
2. 线程方案：实现简单，适合计算密集型任务，但会增加线程切换开销

最佳实践建议

1. 新项目建议采用全异步架构
2. 遗留系统改造可考虑渐进式迁移
3. 对于长时间运行的任务，建议结合Celery等分布式任务队列
4. 注意资源限制，特别是LLM模型的并发处理能力

理解这些异步编程模式，可以帮助开发者构建更健壮、高效的AI服务后端架构。