1. 为什么你需要一个本地知识库？

最近几年，大语言模型（LLM）火得一塌糊涂，但说实话，很多朋友用起来心里总有点不踏实。把公司内部文档、个人笔记、甚至是产品设计稿这些敏感信息一股脑儿喂给在线的AI服务，数据安全怎么保障？网络一波动，或者服务商那边出点小状况，你的工作流就卡壳了。更别提那些需要实时、高频查询的场景了，每次请求都绕地球一圈，延迟和成本都是问题。

这时候，本地知识库的优势就凸显出来了。它就像是你自己家里的私人图书馆，所有的“藏书”（也就是你的文档数据）都存放在你自己的电脑或服务器上，完全由你掌控。而 Ollama，就是那个帮你轻松管理这个图书馆，并且请来一位博学的“图书管理员”（本地大模型）的得力工具。它把部署和运行各种开源大模型这件事，变得像安装一个普通软件一样简单。

我自己的团队就在用这套方案。我们有几个G的产品手册、技术白皮书和客户支持记录，以前查点东西得在十几个PDF里来回翻，现在直接问“本地AI”就行，回答又快又准，关键是数据不出内网，老板放心，我们也安心。接下来，我就手把手带你走一遍从零开始，用Ollama搭建一个高效、实用的本地知识库的完整流程，从文档准备到智能问答，把每一步的细节和踩过的坑都告诉你。

2. 搭建你的本地AI环境：Ollama安装与模型选择

2.1 一键安装Ollama，真的就这么简单

Ollama的安装过程是我见过最友好的之一，它屏蔽了所有底层环境的复杂配置。无论你是用Mac、Windows还是Linux，基本都是一条命令的事。

对于Mac和Linux用户，打开你的终端（Terminal），直接运行官方的一键安装脚本：

curl -fsSL https://ollama.ai/install.sh | sh

这条命令会自动下载、安装并启动Ollama服务。安装完成后，你会在终端里看到Ollama已经作为一个后台服务（daemon）运行起来了。你可以通过 ollama --help 来验证安装是否成功，看看它支持哪些命令。

Windows用户也别担心，你可以直接从Ollama官网下载安装程序（.exe文件），像安装其他软件一样双击运行即可。安装后，你可以在开始菜单找到Ollama，或者在PowerShell/CMD中直接使用 ollama 命令。

这里有个小提示：安装完成后，建议你重启一下终端（或者新开一个终端窗口），这样能确保 ollama 命令被正确添加到系统路径中，随时可以调用。

2.2 挑选你的“核心大脑”：如何选择适合的模型

Ollama本身不生产模型，它是优秀模型的“搬运工”和“运行器”。它内置了一个模型库，里面集成了数十个热门的开源大模型，比如Llama 3、Mistral、Gemma、Qwen等等。你的知识库智能程度如何，很大程度上取决于你为它选择的这个“大脑”。

对于构建知识库这个任务，我的经验是，模型的选择需要平衡三个因素：能力、速度和硬件开销。

  • 如果你追求极致的回答质量和逻辑推理能力，并且你的电脑配置足够高（比如有16GB以上的显存），那么 llama3:70b 或 mixtral:8x22b 这类大型模型是首选。它们能深刻理解文档上下文，给出非常精准、详尽的答案。
  • 如果你更看重响应速度和资源占用，比如在普通的笔记本电脑上运行，那么 llama3:8b、mistral:7b 或 gemma2:9b 这些中小型模型是绝佳的选择。它们在大多数问答任务上表现已经相当不错，而且速度飞快，对硬件要求友好。
  • 如果你主要处理中文文档，那么强烈建议考虑 qwen2:7b 或 qwen2:14b。通义千问系列模型对中文的理解和生成能力在开源模型中属于第一梯队，专门优化过中文场景，用起来会更得心应手。

怎么下载呢？命令简单到不可思议。比如，我想试试最新的Llama 3 8B模型：

ollama pull llama3:8b

Ollama会自动从官方仓库拉取模型文件。首次拉取需要一些时间，取决于你的网速和模型大小（8B模型大约4-5GB）。拉取完成后，这个模型就常驻在你的本地了，以后随时可以调用。

你可以用 ollama list 查看本地已下载的所有模型。我建议新手先从 llama3:8b 或 qwen2:7b 开始，快速体验整个流程，之后再根据需求尝试更强大的模型。

3. 从杂乱文档到结构化数据：文档处理实战

模型准备好了，接下来就是喂给它的“粮食”——你的文档。原始文档往往是杂乱无章的，有PDF、Word、PPT、网页，甚至图片。直接扔给模型，效果通常很差。我们需要一个处理流程，把它们变成模型能高效“消化”的格式。

3.1 文档的收集与预处理：别让格式成为障碍

第一步，是建立一个“原料仓库”。把你所有想要纳入知识库的文档集中到一个文件夹里。这些可能包括：

  • 文本类：.txt, .md, .html
  • 办公文档：.pdf, .docx, .pptx, .xlsx
  • 代码文件：.py, .js, .java 等（如果你的知识库包含代码文档）

对于非纯文本格式，我们需要进行转换。这里我推荐使用 unstructured 这个Python库，它是由AI基础设施公司Scale AI开源的，专门用于从各种格式中提取文本，功能强大且简单。

首先安装它：

pip install "unstructured[all-docs]"

然后，你可以写一个简单的Python脚本，批量处理你的文档文件夹：

from unstructured.partition.auto import partition
import os

input_folder = "./我的文档"
output_folder = "./处理后的文本"

os.makedirs(output_folder, exist_ok=True)

for filename in os.listdir(input_folder):
    file_path = os.path.join(input_folder, filename)
    try:
        # 核心的一行代码：自动识别并解析文档
        elements = partition(filename=file_path)
        # 将所有解析出的文本元素合并
        full_text = "\n\n".join([str(el) for el in elements])
        
        # 保存为纯文本文件，可以用原文件名，后缀改为.txt
        output_path = os.path.join(output_folder, os.path.splitext(filename)[0] + ".txt")
        with open(output_path, 'w', encoding='utf-8') as f:
            f.write(full_text)
        print(f"成功处理: {filename}")
    except Exception as e:
        print(f"处理失败 {filename}: {e}")

这个脚本会遍历你的文件夹，把PDF里的文字、Word里的段落、甚至PPT里的演讲者备注，都提取出来，合并成一个干净的 .txt 文件。预处理这一步非常关键，它直接决定了后续步骤的输入质量。

3.2 文本分割与向量化：让AI理解文档的关键

现在你有了纯文本，但一整本书那么长的文本直接塞给模型是不行的。一方面有模型上下文长度的限制（比如4096个token），另一方面模型也很难从海量文字中精准定位相关信息。

解决办法是：切分和向量化。

切分（Chunking）：把长文本按语义切成一个个小片段。这里不能简单地按固定字数切，那样可能会把一个完整的句子或概念拦腰斩断。好的做法是按段落、按标题，或者使用更高级的“递归字符文本分割器”，它能在尽量保持语义完整性的前提下进行分割。

向量化（Embedding）：这是构建智能检索的核心。我们把每一段文本（chunk）通过一个“嵌入模型”（Embedding Model）转换成一个高维度的数字向量（可以理解为一串有特殊意义的数字）。这个向量就像这段文本的“数学指纹”。语义相近的文本，它们的“指纹”在数学空间里的距离也会很近。

当用户提出一个问题时，我们同样把问题转换成向量，然后去知识库里快速找出那些“指纹”最接近的文本片段。这个过程比传统的关键词匹配要聪明得多，因为它理解语义。比如，你问“如何重启服务”，它能找到包含“系统复位”、“重新启动进程”等描述的段落，即使没有出现“重启”这个词。

我们可以用 sentence-transformers 这个库来轻松完成向量化。它封装了很多优秀的开源嵌入模型，比如 all-MiniLM-L6-v2，这个模型小巧但效果很好。

from sentence_transformers import SentenceTransformer
import numpy as np

# 加载嵌入模型
embedding_model = SentenceTransformer('all-MiniLM-L6-v2')

# 假设我们有一个文本片段列表
text_chunks = ["这是第一段文档内容...", "这是第二段关于产品的描述...", ...]

# 批量生成向量，速度更快
chunk_embeddings = embedding_model.encode(text_chunks, show_progress_bar=True)

# chunk_embeddings 就是一个NumPy数组，每一行代表一个文本片段的向量
print(f"生成了 {len(chunk_embeddings)} 个向量，每个向量维度是 {chunk_embeddings.shape[1]}")

现在，你的每一段文档都有了对应的“数学指纹”（向量）。下一步，就是把这些向量和原文存储起来，构建成可以快速查询的数据库。

4. 构建可查询的向量数据库

有了文本片段和它们的向量，我们需要一个专门的地方来存储和管理它们，并且要能进行高效的相似度搜索。这就是向量数据库（Vector Database）的用武之地。它就像一个超级索引，能帮我们瞬间找到和问题最相关的文档片段。

4.1 轻量级首选：ChromaDB入门

在本地知识库的初期或中小规模场景下，我首推 ChromaDB。它轻量、易用，完全开源，而且和Python生态结合得非常好，几乎不需要什么配置就能跑起来。

安装非常简单：

pip install chromadb

下面是如何创建数据库、添加文档并保存的完整示例：

import chromadb
from chromadb.config import Settings

# 1. 初始化客户端和数据库（持久化模式，数据会保存到磁盘）
chroma_client = chromadb.PersistentClient(path="./my_local_knowledge_db")

# 2. 创建一个集合（Collection），可以理解为一个独立的知识库
collection = chroma_client.get_or_create_collection(
    name="my_tech_docs", # 集合名称
    metadata={"description": "存储公司技术文档和产品手册"} # 可选元数据
)

# 3. 准备要添加的数据
# 假设我们已经有了处理好的文本片段列表和它们的ID
documents = ["文档片段1的文本内容...", "文档片段2的文本内容...", ...] # 你的文本片段列表
ids = ["doc_chunk_1", "doc_chunk_2", ...] # 为每个片段分配唯一ID
metadatas = [{"source": "用户手册.pdf", "page": 5}, {"source": "API文档.md", "section": "概述"}, ...] # 可选的元数据，记录来源

# 4. 将文档添加到集合中
# 注意：这里我们没有提供embeddings参数，ChromaDB会使用默认的嵌入模型自动生成。
# 如果你想使用之前自己生成的向量，可以传入 `embeddings=chunk_embeddings.tolist()`
collection.add(
    documents=documents,
    ids=ids,
    metadatas=metadatas
)

print(f"成功将 {len(documents)} 个文档片段添加到知识库。")

这样，你的知识库就初步建好了。数据会保存在你指定的 ./my_local_knowledge_db 目录下，下次启动程序可以直接加载，无需重复添加。

4.2 执行你的第一次语义搜索

知识库建好了，怎么用呢？核心就是查询（Query）。你提出一个问题，ChromaDB会帮你找到最相关的几个文档片段。

# 用户提出问题
query_text = "我们的产品支持哪些支付方式？"

# 在集合中进行查询，返回最相关的3个结果
results = collection.query(
    query_texts=[query_text],
    n_results=3 # 返回最相似的3个片段
)

# 查看结果
print("最相关的文档片段：")
for i, doc in enumerate(results['documents'][0]):
    print(f"\n--- 结果 {i+1} ---")
    print(doc)
    # 你还可以打印出对应的元数据，比如来自哪个文件
    print(f"来源：{results['metadatas'][0][i]}")

你会发现，即使用户的问题和文档中的表述不完全一致（比如文档里写的是“接入支付宝和微信支付”，而用户问“支付方式”），基于向量的语义搜索也能很好地找到正确答案。这就是本地知识库智能化的基础。

5. 连接大脑与数据库：搭建智能问答系统

现在，我们有了强大的本地模型（Ollama）和存储了知识片段的向量数据库（ChromaDB）。最后一步，就是把它们巧妙地连接起来，打造一个完整的智能问答系统。这个系统的核心工作流程是：用户提问 -> 从数据库检索相关上下文 -> 将“上下文+问题”一起交给模型 -> 模型生成答案。

5.1 使用LangChain编排整个流程

手动管理这个流程比较繁琐，而 LangChain 这个框架就是专门为这种任务而生的。它像是一个“胶水”或者“编排器”，把大模型、向量数据库、提示词模板等组件优雅地连接在一起。虽然原始文章提到了LangChain，但代码有些混乱，我这里给你一个清晰、可运行的版本。

首先安装必要的库：

pip install langchain langchain-community chromadb sentence-transformers

然后，我们一步步构建这个问答链：

from langchain.vectorstores import Chroma
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.llms import Ollama
from langchain.chains import RetrievalQA
from langchain.prompts import PromptTemplate

# 1. 加载我们之前构建的Chroma向量数据库
# 指定我们使用的嵌入模型，必须和创建时一致（如果创建时用了自定义的）
embedding_function = HuggingFaceEmbeddings(model_name="all-MiniLM-L6-v2")
vectorstore = Chroma(
    persist_directory="./my_local_knowledge_db", # 数据库路径
    collection_name="my_tech_docs", # 集合名称
    embedding_function=embedding_function
)

# 2. 初始化Ollama本地模型
llm = Ollama(model="llama3:8b", temperature=0.1)
# temperature参数控制创造性，知识库问答建议设低一点（如0.1），让答案更确定、更基于上下文。

# 3. 创建一个检索器（Retriever），它负责从向量库中查找相关文档
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})
# 这里设置 k=4，表示每次检索返回最相关的4个文档片段。

# 4. （关键！）设计一个提示词模板
# 这个模板告诉模型如何利用我们提供的上下文来回答问题。
prompt_template = """请严格根据以下提供的上下文信息来回答问题。如果上下文中的信息不足以回答问题，请直接说“根据已知信息无法回答此问题”，不要编造信息。

上下文：
{context}

问题：{question}

请根据上下文给出答案："""
PROMPT = PromptTemplate(
    template=prompt_template, input_variables=["context", "question"]
)

# 5. 创建检索问答链（RetrievalQA Chain）
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff", # “stuff”模式简单地将所有检索到的上下文拼接到提示词中
    retriever=retriever,
    chain_type_kwargs={"prompt": PROMPT}, # 使用我们自定义的提示词
    return_source_documents=True # 设置为True，可以返回参考了哪些源文档
)

# 6. 现在，开始提问吧！
question = "申请退款后，款项通常多久可以到账？"
result = qa_chain({"query": question})

print(f"问题：{question}")
print(f"\n答案：{result['result']}")
print(f"\n参考来源：")
for i, doc in enumerate(result['source_documents']):
    print(f"  片段{i+1}: {doc.page_content[:150]}...") # 打印片段前150个字符
    # print(f"  元数据: {doc.metadata}") # 如果需要可以打印元数据，如文件名

运行这段代码，你就会得到一个基于你自己文档的答案。chain_type="stuff" 是最简单直接的方式，适合上下文总长度不超过模型限制的情况。如果你的文档片段很多很长，可能需要考虑 "map_reduce" 或 "refine" 等更复杂的链类型来处理。

5.2 进阶技巧：优化检索与回答质量

在实际使用中，你可能会遇到一些问题，比如检索到的片段不相关，或者模型“幻觉”（胡编乱造）。这里分享几个我踩过坑后总结的优化技巧：

  1. 优化检索（Retrieval）：

    • 调整 k 值：search_kwargs={"k": 4} 中的 k 是返回的片段数量。太小可能信息不全，太大可能引入噪音。根据你的文档特点，尝试3到6之间的值。
    • 使用MMR（最大边际相关性）：search_type="mmr"。它不仅考虑相似度，还考虑结果之间的多样性，避免返回一堆意思重复的片段。
    retriever = vectorstore.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 4, "fetch_k": 10} # 先取10个，再从中选4个最相关且多样的
)

  2. 优化提示词（Prompt）： 我上面给的模板是一个很好的起点。你还可以强化指令，比如：

    • 要求引用来源：在模板中加入“请在答案后注明该信息来源于上下文的哪个部分”。
    • 分步思考：对于复杂问题，可以要求模型“首先，从上下文中找出与XX相关的信息；然后，综合这些信息得出结论”。
    • 拒绝回答的指令：一定要像示例中那样，明确要求模型对于不知道的事情说“无法回答”，这是减少幻觉的最有效手段之一。

  3. 后处理（Post-processing）： 对模型的答案进行一些检查。例如，检查答案中是否包含明显的、与已知事实矛盾的内容，或者是否完全脱离了检索到的上下文。

搭建这样一个系统，一开始可能会觉得步骤不少，但一旦跑通，你会发现它带来的效率提升是巨大的。你可以把这个脚本封装成一个简单的Web API（用FastAPI或Flask），或者集成到你的内部办公系统、客服机器人里，一个属于你自己的、安全可靠的AI知识助手就诞生了。整个过程，数据始终在你本地，模型也在你本地，完全自主可控。

# Ollama
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

会议室音视频协作痛点全解析与专业解决方案

avatar 亚马逊云科技技术品牌专区
cover

PLC自动化|PLC|毕设项目|毕设答辩|基于PLC的小型粮仓粮情监控系统设计

avatar 亚马逊云科技技术品牌专区
cover

DPJ-81基于STM32单片机WiFi智能家居系统 物联网家庭防盗设计

avatar 亚马逊云科技技术品牌专区