用 Claude 3.5 Sonnet 搭建个人知识库：从 Prompt 优化到代码实现全记录

我这次尝试用 Python + LangChain + ChromaDB 快速搭了一个本地 Demo，在处理复杂技术文档时，直接喂内容给 LLM 经常会出现幻觉，核心在于检索阶段的噪声太高。

1. 关键的 Prompt 调优
我尝试了多种 System Prompt，发现最有效的不是告诉它“请根据上下文回答”，而是给它一个明确的拒绝机制和引用要求。

你是一个严谨的知识库助手。回答时必须遵循：
1. 仅使用提供的上下文信息。如果上下文中没有答案，直接回答“知识库中未记录相关信息”，严禁自行脑补。
2. 每一段结论后必须标注来源，格式为 [文档名-页码/行号]。
3. 如果上下文存在矛盾，请同时列出两种观点并标注来源。

2. 代码实现中的坑：分块策略
刚开始用默认的 CharacterTextSplitter，结果检索出来的片段经常断在句子一半，导致 Claude 理解偏差。后来改用 RecursiveCharacterTextSplitter 并设置了 chunk_overlap，这样能保证语义连续。

from langchain.text_splitter import RecursiveCharacterTextSplitter

# 经验值：chunk_size 500, overlap 50 比较稳
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500, 
    chunk_overlap=50,
    length_function=len,
    separators=["\n\n", "\n", "。", "！", "？", " ", ""]
)
docs = text_splitter.split_documents(raw_documents)

3. 效率提升技巧：利用 Cursor 的 Composer 模式
在写这个项目时，我直接用 Cursor 的 Ctrl+I (Composer) 模式。我把整个 requirements.txt 和目前的 main.py 丢给它，直接下指令：「把目前的向量存储改为持久化存储，并增加一个检查向量数据库是否已加载的逻辑，避免每次启动都重新 Embedding」。

它直接帮我写好了 persist_directory 的配置和 if os.path.exists() 的判断，省去了手动查文档的时间。

4. 避坑指南：Embedding 模型的选择
千万别在本地跑那种极小的 Embedding 模型，检索精度极差。建议直接用 text-embedding-3-small，虽然花几分钱，但配合 Claude 3.5 的推理能力，问答的准确率从 60% 提升到了 90% 以上。

核心配置清单：

• LLM: Claude 3.5 Sonnet (Via API)
• Vector Store: ChromaDB (Local)
• Framework: LangChain
• Embedding: OpenAI text-embedding-3-small