不是必须，但强烈建议使用Ollama或vLLM；直接用transformers在CPU上运行deepseek-r1-7b极慢且显存管理易出错，Ollama提供量化、GPU调度和OpenAI兼容API，vLLM则适合高并发场景。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
DeepSeek 本地部署必须用 Ollama 或 vLLM 吗？
不是必须，但强烈建议。直接用 transformers 加载 deepseek-r1-7b 在 CPU 上跑得极慢，且显存管理容易出错；Ollama 封装了量化、GPU 调度和 HTTP 接口，ollama run deepseek-r1:7b-q4_k_m 一行就启动，返回 OpenAI 兼容格式，LangChain 开箱即用。vLLM 更适合高并发场景（>50 QPS），但需要手动配 tensor_parallel_size 和 dtype，新手容易卡在 CUDA 版本不匹配上。
- 确认 Ollama 版本 ≥ 0.3.0：
ollama --version - 拉取量化模型时别漏掉后缀：
deepseek-r1:7b-q4_k_m比:latest省 60% 显存 - 启动后测试接口：
curl http://localhost:11434/api/chat -d '{"model":"deepseek-r1:7b-q4_k_m","messages":[{"role":"user","content":"你好"}]}'，有 JSON 响应才算通
ChromaDB 存文档前，chunk 大小设多少才不丢信息？
中文文档别硬套英文的 512 token 规则。bge-large-zh-v1.5 对长句语义捕获强，但 chunk 过大会让关键细节被平均掉——比如“报销流程需附发票原件+审批单扫描件”这种带条件的句子，拆成两段就失效了。实测 256–384 字符（非 token）最稳，用 RecursiveCharacterTextSplitter 时设 chunk_size=300、chunk_overlap=50，能保句意完整又避免跨段落断裂。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
- PDF 解析优先用
pdfplumber，别用PyPDF2——后者抽表格会把行列打乱 - Word 文档用
python-docx提取正文，但页眉页脚要手动过滤，否则 chunk 里混入“第3页/共12页”这种噪声 - 切完立刻打印前 3 个 chunk 验证：
print([len(c.page_content) for c in chunks[:3]])，全在 280–350 之间才算合格
LangChain 的 RetrievalQA 为什么总答非所问？
根本原因不是模型差，而是检索器没把用户问题真正“对齐”到知识片段。默认 similarity_search 只比向量余弦距离，但中文里“怎么重置密码”和“忘记登录凭证怎么办”语义近，向量却可能差很远。必须加 score_threshold 和 fetch_k 控制召回质量：
- 设
search_kwargs={"k": 3, "score_threshold": 0.45}，低于 0.45 的强行过滤（bge-large-zh-v1.5的合理阈值区间是 0.4–0.6） - 用
ContextualCompressionRetriever套一层LLMChainExtractor，让 DeepSeek 自己判断哪段真相关，比纯向量筛准 22% - 别省略
return_source_documents=True，调试时直接看result["source_documents"]里返回的是不是你想要的原文段落
问答延迟高，是模型慢还是检索慢？
先定位瓶颈：用 time.time() 包住 retriever.invoke() 和 qa_chain.invoke() 两段，90% 的情况是前者拖慢——尤其 ChromaDB 默认用 hnsw 索引但没建好。初始化数据库后必须调一次 collection.add() 再立即 collection.get()，触发底层索引构建；否则首次查询要现场建树，耗时翻 5 倍。
- ChromaDB 启动时加
persist_directory参数，否则每次重启都重算索引 - 超过 1 万文档就别用默认
hnsw，改用annoy引擎：chroma_client.get_or_create_collection(..., metadata={"hnsw:space": "cosine"})不起作用，得换底层 - CPU 模式下，
deepseek-r1-7b单次生成 100 字约 4 秒，如果总响应超 8 秒，八成是检索卡在 IO 或未预热
persist_directory 路径权限不对会导致 silently fail；Ollama 拉取模型时网络中断，残留的半成品文件会让后续 ollama list 显示异常；bge-large-zh-v1.5 必须用 torch.bfloat16 加载，用 float32 会 OOM。这些地方不踩一遍，光看架构图是搭不起来的。 
