如何利用文心一言的 API 快速构建一个企业内部知识库问答助手

直接把企业内部的 PDF 或 Wiki 文档塞给 LLM 很容易导致 Token 溢出且响应极慢，最稳妥的方案还是走 RAG（检索增强生成）路径。我最近用文心一言的 API 搭建了一套内部知识库，核心逻辑是「向量化存储 + 语义检索 + 上下文注入」。

技术栈选型
API：文心一言 (ERNIE-Bot)
向量库：ChromaDB（轻量，本地运行快）
框架：LangChain (Python)

核心实现步骤
首先得把文档切片。千万别按字符数死切，建议按段落或语义块切，否则检索出来的片段没上下文，AI 容易胡说八道。

from langchain.text_splitter import RecursiveCharacterTextSplitter

# 建议 chunk_size 设在 500 左右，overlap 留 50 保证语义连续
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
    length_function=len
)
docs = text_splitter.split_documents(raw_documents)

接着是向量化。文心一言有专门的 Embedding 接口，将文本转为向量后存入 ChromaDB。查询时，先在向量库里搜最相关的 Top 3 片段，再把片段拼在 Prompt 里发给文心一言。

实操 Prompt 技巧
为了防止 AI 开启“幻想”模式，Prompt 必须强制它只根据提供的内容回答。如果库里没答案，就让它承认不知道，别乱编。

你是一个企业内部知识库助手。请仅根据以下【已知信息】回答问题。
如果【已知信息】中没有相关内容，请直接回答“知识库中暂无此信息”，不要尝试编造。

【已知信息】：
{context}

【用户问题】：
{question}

踩过的坑与优化点
1. 检索精度问题：单纯靠向量检索有时会搜到无关但词汇相近的段落。建议在检索后加一层简单的关键词过滤，或者调整 top_k 的数量。
2. 接口响应延迟：文心一言 API 在处理长上下文时会有明显延迟。建议在前端实现 Streaming 流式输出，用户体验会好很多，否则盯着加载圈转 5 秒钟真的会崩溃。
3. 文档清洗：最耗时的是数据预处理。PDF 里的页眉页脚、表格乱码会严重干扰向量化效果，建议先用 PyMuPDF 把 PDF 转纯文本并剔除干扰项，再喂给 API。

效率提升对比
以前手动查文档需要 5-10 分钟，现在通过这个助手，绝大多数制度类咨询在 3 秒内就能定位到具体条款，效率提升非常明显。