大模型项目实战与开发流程详解

两种快速开发 Demo 的框架：Gradio 和 Streamlit，可以帮助个体开发者迅速搭建可视化页面实现 Demo 上线。

在完成前后端搭建之后，应用就可以上线体验了。接下来就需要进行长期的用户体验跟踪，记录 Bad Case 与用户负反馈，再针对性进行优化即可。

三、项目流程简析：个人知识库问答助手

3.1 项目规划与需求分析

1. 项目目标：基于个人知识库的问答助手
2. 核心功能：
   • 上传文档、创建知识库
   • 选择知识库，检索用户提问的知识片段
   • 提供知识片段与提问，获取大模型回答
   • 流式回复
   • 历史对话记录
3. 确定技术架构和工具：
   • LangChain 框架
   • Chroma 知识库
   • 大模型使用 GPT、科大讯飞的星火大模型、文心一言、GLM 等
   • 前后端使用 Gradio 和 Streamlit

3.2 数据准备与向量知识库构建

3.2.1 收集和整理用户提供的文档

用户常用文档格式有 pdf、txt、doc 等，首先使用工具读取文本，通常使用 langchain 的文档加载器模块，也可以使用 python 比较成熟的包进行读取。

由于目前大模型使用 token 的限制，需要对读取的文本进行切分，将较长的文本切分为较小的文本，这时一段文本就是一个单位的知识。

from langchain.document_loaders import PyPDFLoader, TextLoader

loader = PyPDFLoader("example.pdf")
documents = loader.load()

3.2.2 将文档词向量化

使用文本嵌入 (Embeddings) 对分割后的文档进行向量化，使语义相似的文本片段具有接近的向量表示。然后，存入向量数据库，这个流程正是创建索引 (index) 的过程。

向量数据库对各文档片段进行索引，支持快速检索。这样，当用户提出问题时，可以先将问题转换为向量，在数据库中快速找到语义最相关的文档片段。然后将这些文档片段与问题一起传递给语言模型，生成回答。

3.2.3 将向量化后的文档导入 Chroma 知识库

Chroma 向量库轻量级且数据存储在内存中，非常容易启动和开始使用。

用户知识库内容经过 embedding 存入向量知识库，然后用户每一次提问也会经过 embedding，利用向量相关性算法（例如余弦算法）找到最匹配的几个知识库片段，将这些知识库片段作为上下文，与用户问题一起作为 prompt 提交给 LLM 回答。

from langchain.vectorstores import Chroma
from langchain.embeddings import HuggingFaceEmbeddings

embeddings = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")
vectorstore = Chroma.from_documents(documents=documents, embedding=embeddings)

3.3 大模型集成与 API 连接

• 集成 GPT、星火、文心、GLM 等大模型，配置 API 连接。
• 编写代码，实现与大模型 API 的交互，以便获取问题答案。

from langchain.chat_models import ChatOpenAI

llm = ChatOpenAI(temperature=0, model_name="gpt-3.5-turbo", openai_api_key="YOUR_API_KEY")

3.4 核心功能实现

• 构建 Prompt Engineering，实现大模型回答功能，根据用户提问和知识库内容生成回答。
• 实现流式回复，允许用户进行多轮对话。
• 添加历史对话记录功能，保存用户与助手的交互历史。

3.5 核心功能迭代优化

• 进行验证评估，收集 Bad Case。
• 根据 Bad Case 迭代优化核心功能实现。

3.6 前端与用户交互界面开发

• 使用 Gradio 和 Streamlit 搭建前端界面。
• 实现用户上传文档、创建知识库的功能。
• 设计用户界面，包括问题输入、知识库选择、历史记录展示等。

3.7 部署测试与上线

• 部署问答助手到服务器或云平台，确保可在互联网上访问。
• 进行生产环境测试，确保系统稳定。
• 上线并向用户发布。

3.8 维护与持续改进

• 监测系统性能和用户反馈，及时处理问题。
• 定期更新知识库，添加新的文档和信息。
• 收集用户需求，进行系统改进和功能扩展。

四、项目架构简析

4.1 整体架构

搭建一个基于大模型的个人知识库助手，基于 LangChain 框架搭建，核心技术包括 LLM API 调用、向量数据库、检索问答链等。项目整体架构如下：

项目从底向上依次分为 LLM 层、数据层、数据库层、应用层与服务层：

4.1.1 LLM 层

基于四种流行 LLM API（OpenAI-ChatGPT、百度文心、讯飞星火、智谱 GLM）进行了 LLM 调用封装，支持用户以统一的入口、方式来访问不同的模型，支持随时进行模型的切换；

在 LLM 层，构建了一个 Self_LLM 基类，基类定义了所有 API 的一些共同参数（如 API_Key，temperature 等）；在该基类基础上继承实现了上述四种 LLM API 的自定义 LLM。四种 LLM 的原生 API 封装在了统一的 get_completion 函数中。

4.1.2 数据层

包括个人知识库的源数据（包括 pdf、txt、md 等）以及 Embedding API，源数据经过 Embedding 处理可以被向量数据库使用；

4.1.3 数据库层

基于个人知识库源数据搭建的向量数据库，本项目中选择了 Chroma。在该层实现了源数据处理、创建向量数据库的方法;

4.1.4 应用层

应用层封装了整个项目的全部核心功能。基于 LangChain 提供的检索问答链基类进行了进一步封装，支持通过 model 参数进行不同模型切换以及便捷实现基于数据库的检索问答。

实现了两个检索问答链，分别是有历史记录的 Chat_QA_Chain 和没有历史记录的 QA_Chain；

4.1.5 服务层

实现了 Gradio 搭建 Demo 与 FastAPI 组建 API 两种方式来支持本项目的服务访问。

4.2 代码结构

-project
    -readme.md 项目说明
    -requirements.txt 使用依赖包的版本 
    -llm LLM 调用封装
        -self_llm.py 自定义 LLM 基类
        -wenxin_llm.py 自定义百度文心 LLM
        -spark_llm.py 自定义讯飞星火 LLM
        -zhipuai_llm.py 自定义智谱 AI LLM
        -call_llm.py 将各个 LLM 的原生接口封装在一起
        -test.ipynb 使用示例
    -embedding embedding 调用封装
        -zhipuai_embedding.py 自定义智谱 AI embedding
        -call_embedding.py 调用 embedding 模型 
    -data 源数据路径
    -database 数据库层封装
        -create_db.py 处理源数据及初始化数据库封装
    -qa_chain 应用层封装
        -qa_chain.py 封装检索问答链，返回一个检索问答链对象
        -chat_qa_chian.py：封装对话检索链，返回一个带有历史记录的对话检索链对象
        -get_vectordb.py 返回向量数据库对象
        -model_to_llm.py 调用模型
        -test.ipynb 使用示例
    -serve 服务层封装
        -run_gradio.py 启动 Gradio 界面
        -api.py 封装 FastAPI
        -run_api.sh 启动 API
        -test.ipynb 使用示例

4.3 项目逻辑

1. 用户：可以通过 run_gradio 或者 run_api 启动整个服务；
2. 服务层调用 qa_chain.py 或 chat_qa_chain 实例化对话检索链对象，实现全部核心功能；
3. 服务层和应用层都可以调用、切换 prompt_template.py 中的 prompt 模板来实现 prompt 的迭代；
4. 也可以直接调用 call_llm 中的 get_completion 函数来实现不使用数据库的 LLM；
5. 应用层调用已存在的数据库和 llm 中的自定义 LLM 来构建检索链；
6. 如果数据库不存在，应用层调用 create_db.py 创建数据库，该脚本可以使用 openai embedding 也可以使用 embedding.py 中的自定义 embedding。

五、最佳实践与优化建议

5.1 提示词优化策略

为了提高回答质量，建议采用以下策略：

1. 角色设定：在 Prompt 开头明确模型的角色，例如'你是一位专业的法律顾问'。
2. 思维链（CoT）：要求模型在给出最终答案前先进行推理步骤的展示。
3. 少样本学习（Few-Shot）：提供几个高质量的输入输出示例，引导模型模仿格式和风格。
4. 约束条件：明确限制回答的长度、格式或禁止包含的内容。

5.2 检索增强生成（RAG）优化

1. 分块策略：根据文档结构选择合适的 chunk size 和 overlap，避免关键信息被切断。
2. 混合检索：结合关键词检索（BM25）和向量检索，提高召回率。
3. 重排序（Re-ranking）：在检索结果返回后，使用重排序模型对结果进行二次打分，选取最相关的片段。

5.3 性能与成本考量

1. 缓存机制：对相同的用户提问进行缓存，减少重复的 API 调用。
2. 模型选择：对于简单任务使用小参数模型，复杂任务使用大参数模型，平衡成本与效果。
3. 异步处理：在高并发场景下，使用异步 IO 处理请求，提升吞吐量。

六、总结

大模型开发不仅仅是调用 API，更是一个系统工程。从需求分析、架构设计、数据准备、Prompt 工程到部署运维，每一个环节都需要精心打磨。通过本文介绍的开发流程和实战案例，希望能为开发者提供一套可落地的参考方案，帮助大家快速构建高质量的大模型应用。