本地Ollama+RAG实现PDF对话：嵌入后代码停滞无报错

1. 先确认Ollama服务与模型可用性 #

• 执行命令ollama serve启动Ollama后台服务（如果未运行）
• 在终端执行ollama run <你的模型名>（比如ollama run llama2），测试模型能否正常响应提问，排除模型加载失败的底层问题
• 核对代码中指定的模型名与ollama list输出的名称完全一致（比如本地模型是llama2:7b，就不能只写llama2）

2. 定位代码停滞的具体环节 #

在代码中添加打印标记，精准锁定阻塞点：

# embedding完成后添加
print("✅ Embedding操作完成，开始加载LLM")
# LLM加载代码前添加
print("✅ LLM加载完成，开始构建检索链")
# 检索链构建代码前添加
print("✅ 检索链构建完成，进入问答逻辑")

3. 针对常见阻塞场景修复 #

（1）向量库持久化阻塞 #

如果使用Chroma等本地向量库，显式触发持久化并指定路径，避免隐式写入卡住：

db = Chroma.from_documents(documents, embeddings, persist_directory="./local_chroma_db")
db.persist()  # 强制完成向量写入

若仍卡住，删除旧的local_chroma_db目录，重新生成向量库。

（2）Ollama LLM加载超时 #

给LLM实例添加超时参数，避免无限等待：

llm = Ollama(model="你的模型名", timeout=60)  # 设置60秒超时阈值

（3）检索链构建阻塞 #

先简化链配置，排除复杂链式调用的问题：

# 先测试单步LLM调用
response = llm.invoke("测试LLM是否正常响应")
print(response)
# 确认LLM正常后再构建检索链
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=db.as_retriever(search_kwargs={"k": 3}),
    return_source_documents=True
)

4. 资源占用排查 #

打开任务管理器/活动监视器，查看CPU、内存占用：

• 若内存占满，减小PDF文本分割的chunk_size（比如从1000改为500）
• 换用轻量化embedding模型（比如all-MiniLM-L6-v2）降低资源消耗

内容的提问来源于stack exchange，提问作者NIrbhay Mathur