
如果你是一名开发者最近一定被各种AI大模型的消息刷屏。从ChatGPT到Claude从DeepSeek到通义千问似乎每个公司都在推出自己的大模型。但当你真正想把这些技术用在自己的项目中时却常常陷入困境公开API太贵且有数据安全顾虑开源模型又不知从何下手好不容易跑起来一个模型却发现它“一本正经地胡说八道”对专业领域知识一无所知。这正是当前AI应用落地的核心矛盾我们拥有强大的基础模型却缺乏一套系统的方法将其低成本、高效率、安全可控地转化为解决实际业务问题的生产力工具。今天要讨论的正是一套被广泛验证的“AI大模型工程化四件套”本地部署、RAG知识库、模型微调、以及Dify这样的应用编排平台。这并非某个单一教程而是一个完整的技能栈。掌握它意味着你不仅能“玩转”AI更能“驾驭”AI让大模型真正为你所用。本文将为你拆解这四大核心模块提供从零到一的实操路径。我们不会空谈概念而是聚焦于每个环节的核心原理、关键决策、实操步骤以及最容易踩的坑。无论你是想为团队搭建一个内部知识问答系统还是希望开发一个智能客服应用这套组合拳都能为你提供清晰的行动指南。1. 为什么是“本地部署RAG微调Dify”在深入技术细节之前我们必须先回答一个根本问题为什么是这四者的组合它们各自解决了什么问题又如何在项目中协同工作想象一个典型的业务场景你需要开发一个智能客服它能回答公司内部产品手册、技术文档和客户历史工单中的问题。第一步本地部署。你不可能把所有内部文档都发送给OpenAI的服务器。因此你需要一个能在自己服务器或电脑上运行的模型。这解决了数据隐私、网络延迟和长期使用成本的核心问题。本地部署是私有化AI应用的基石。第二步RAG知识库。直接询问一个通用大模型“我们产品A的XX功能如何配置”它大概率答不上来。RAG检索增强生成技术就是让模型在回答前先去你准备好的产品手册、文档库中查找相关信息然后基于找到的“证据”来生成答案。这极大地提升了回答的准确性和专业性是让通用模型“懂你业务”的最快路径。第三步模型微调。RAG解决了“知识”问题但模型的“说话风格”和“思维模式”可能还不符合你的要求。比如你希望客服回答更简洁或严格遵循某种格式。这时你可以用自己积累的优质对话数据QA对对模型进行微调让它学习你期望的响应模式。这优化了模型的行为偏好和输出格式。第四步Dify应用编排。前面三步提供了“原料”本地模型和“能力”知识检索、定制化响应。Dify这样的平台则像一个可视化的工作流编辑器让你能通过拖拽的方式将模型、知识库、各种工具如代码解释器、搜索引擎连接起来构建成一个完整的、可发布的AI应用并提供用户界面、权限管理、对话历史等生产级功能。它解决了应用快速构建和工程化管理的问题。它们的关系可以概括为本地部署提供算力基础RAG注入领域知识微调塑造个性风格Dify完成产品封装。这是一个从底层基础设施到上层应用开发的完整闭环。2. 核心概念快速解读在动手之前我们需要统一语言理解几个关键术语避免后续产生混淆。2.1 大模型本地部署不只是“下载-运行”本地部署的核心目标是在自有环境中运行大语言模型。这里有三个关键选择决定了你的技术路线和资源投入模型格式与推理框架GGUF格式 llama.cpp这是目前最流行的轻量级本地部署方案。GGUF是一种量化模型格式能显著降低模型对显存的需求。llama.cpp是一个高效的C推理框架可以在CPU上流畅运行数十亿参数的模型。适合绝大多数个人开发者和对GPU资源有限的团队。Transformer PyTorch使用Hugging Face的transformers库这是最原生、最灵活的方式可以方便地进行模型微调和实验。但对GPU显存要求最高。vLLM / TGI专为生产环境高性能推理设计的框架支持连续批处理、PagedAttention等优化技术能极大提高吞吐量。适合需要高并发服务的线上场景。量化Quantization这是让大模型在消费级硬件上运行的关键技术。通过降低模型权重的数值精度如从FP16降到INT4可以大幅减少模型体积和内存占用代价是轻微的性能损失。对于大多数问答、总结任务7B70亿参数的模型经过4-bit或5-bit量化后在16GB内存的电脑上已能有不错的表现。Ollama一个将上述复杂步骤封装起来的工具。它类似于“大模型的Docker”一条命令就能下载、运行和管理各种开源模型自动处理依赖和配置。对于初学者和快速原型开发Ollama是入门首选。2.2 RAG让模型“有据可查”的工程系统RAG不是一个简单的函数调用而是一个包含多个环节的流水线系统文档加载与切分支持PDF、Word、Markdown、网页等格式。将长文档按语义切分成大小适中的片段Chunk这是影响检索效果的第一步。向量化与嵌入使用嵌入模型如text-embedding-ada-002的开源替代BGE-M3将文本片段转换为数学向量一组数字。向量数据库存储将这些向量存入Chroma、Milvus、Qdrant等向量数据库它们能高效计算向量间的相似度。检索与生成当用户提问时将问题也转换为向量在数据库中检索出最相关的几个文本片段将它们和问题一起“喂”给大模型指令其基于这些片段生成答案。关键洞察RAG的瓶颈往往不在大模型而在检索质量。切分策略不当、嵌入模型不准都会导致“检索不到正确答案”后续生成再强也无用。2.3 微调是“精修”而非“重造”微调是在预训练大模型的基础上用特定领域的数据继续训练使其适应新任务。你需要了解两种主流高效微调技术LoRA在原始模型旁边增加一个小的“适配器”网络进行训练只更新这部分参数训练快显存占用小且可以多个LoRA模块切换。是目前最流行的微调方法。QLoRALoRA的升级版在微调时也对模型进行4-bit量化使得在单张消费级显卡如24G的RTX 4090上微调70B大模型成为可能。重要提醒微调需要高质量的数据集通常需要数百到数千条精心构造的指令-回答对且训练过程有风险可能破坏模型原有能力。对于很多场景优先使用RAG注入知识将微调用于调整格式和风格是更稳妥的策略。2.4 DifyAI应用的“操作系统”Dify的核心价值在于可视化编排和工程化。它把模型、知识库、提示词、工作流、API等组件抽象成可配置的模块。你可以通过界面配置RAG知识库而无需写代码处理文档管道。用“提示词编排”功能调试复杂指令管理不同场景的对话模板。使用“工作流”功能设计多步骤AI应用例如用户输入→检索知识库→调用模型生成→审核内容→发送邮件。一键发布为Web应用或API服务并自带用户管理、对话日志、运营监控等功能。它降低了AI应用开发的门槛让开发者能更专注于业务逻辑而非底层工程。3. 环境准备搭建你的AI工作站工欲善其事必先利其器。以下是为这套技术栈推荐的软硬件环境。3.1 硬件建议入门级学习与原型CPU现代多核处理器如Intel i7/i9或AMD Ryzen 7/9。内存32GB及以上。这是运行量化后7B-13B模型的基本要求。显卡非必须但有则更好。一块RTX 306012GB或4060 Ti16GB能显著加速推理和微调。存储NVMe SSD至少预留50GB空间存放模型。进阶级生产与开发GPU单卡显存24GB以上如RTX 4090这是本地微调70B以下模型的黄金标准。多卡环境则适合更大模型或更高并发。内存64GB或更高。网络稳定的网络环境用于下载模型单个模型可能超过10GB。3.2 软件与工具栈我们将使用一套尽可能简单、统一的工具链。操作系统Ubuntu 22.04 LTS推荐或 Windows 11 WSL2。本文命令以Linux为例。Python环境使用conda或venv创建独立的Python环境避免依赖冲突。# 安装Miniconda (如已安装请跳过) wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh # 创建并激活环境 conda create -n ai-env python3.10 conda activate ai-env核心工具安装# 安装Ollama (最简模型运行工具) curl -fsSL https://ollama.com/install.sh | sh # 启动Ollama服务 ollama serve # 拉取一个常用模型例如Qwen2.5-7B的4-bit量化版 ollama pull qwen2.5:7bDocker与Docker ComposeDify等工具通常通过Docker部署。# 安装Docker sudo apt-get update sudo apt-get install docker.io docker-compose-v2 # 将当前用户加入docker组避免每次sudo sudo usermod -aG docker $USER # 需要重新登录生效4. 实战第一步本地大模型部署与对话让我们从最简单的开始在本地运行一个大模型并与它对话。4.1 使用Ollama运行模型Ollama管理模型就像docker pull和docker run一样简单。# 1. 查看已下载的模型 ollama list # 2. 与模型进行交互式对话 ollama run qwen2.5:7b # 进入对话界面后直接输入问题例如“用Python写一个快速排序函数。”4.2 通过API调用本地模型Ollama在本地提供了类似OpenAI的API接口方便集成到其他应用中。# 首先确保Ollama服务在运行ollama serve # 然后在一个新的终端使用curl测试API curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 请介绍一下RAG技术。, stream: false }更常见的是在Python代码中调用# 文件test_ollama_api.py import requests import json def ask_ollama(prompt, modelqwen2.5:7b): url http://localhost:11434/api/generate payload { model: model, prompt: prompt, stream: False, options: { temperature: 0.7, # 控制创造性越低越确定 num_predict: 512 # 生成的最大token数 } } response requests.post(url, jsonpayload) if response.status_code 200: return response.json()[response] else: return fError: {response.status_code} if __name__ __main__: question 解释一下神经网络中的反向传播算法。 answer ask_ollama(question) print(问题, question) print(回答, answer)运行这个脚本你就完成了与大模型的第一次程序化交互。这证明了模型已在本地正常运行为后续的RAG和Dify集成打下了基础。5. 实战第二步构建你的第一个RAG知识库现在我们让模型“读懂”你的私人文档。我们将使用LangChain和Chroma这两个流行的库来构建一个简易的RAG系统。5.1 安装依赖pip install langchain langchain-community chromadb pypdf sentence-transformers # 安装一个强大的开源嵌入模型 pip install -U sentence-transformers5.2 实现RAG全流程以下代码展示了从文档加载到问答的完整流程。我们假设你有一个名为product_manual.pdf的产品手册。# 文件simple_rag.py from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import Chroma from langchain.llms import Ollama from langchain.chains import RetrievalQA # 1. 加载文档 loader PyPDFLoader(./product_manual.pdf) # 替换为你的PDF路径 documents loader.load() # 2. 分割文本 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个片段约500字符 chunk_overlap50, # 片段间重叠50字符保持上下文 separators[\n\n, \n, 。, , , , , , ] ) texts text_splitter.split_documents(documents) print(f将文档切分成了 {len(texts)} 个片段。) # 3. 创建嵌入模型和向量数据库 # 使用开源嵌入模型无需API Key embedding_model HuggingFaceEmbeddings( model_nameBAAI/bge-small-zh-v1.5, # 中文小模型效果不错 model_kwargs{device: cpu}, # 可使用cuda加速 encode_kwargs{normalize_embeddings: True} ) # 将文本向量化并存入ChromaDB vectorstore Chroma.from_documents( documentstexts, embeddingembedding_model, persist_directory./chroma_db # 向量数据库本地存储路径 ) vectorstore.persist() # 持久化保存 # 4. 连接到本地Ollama模型 llm Ollama(modelqwen2.5:7b, base_urlhttp://localhost:11434) # 5. 创建检索式问答链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 将检索到的所有文档片段“塞”给模型 retrievervectorstore.as_retriever(search_kwargs{k: 3}), # 检索最相关的3个片段 return_source_documentsTrue, # 返回来源文档便于调试 verboseTrue # 显示详细过程 ) # 6. 进行问答 query 我们产品的主要优势是什么 result qa_chain.invoke({query: query}) print(\n 用户问题 ) print(query) print(\n 模型回答 ) print(result[result]) print(\n 参考来源前100字符 ) for i, doc in enumerate(result[source_documents]): print(f[{i1}] {doc.page_content[:100]}...)关键步骤解析加载与切分RecursiveCharacterTextSplitter是常用的切分器chunk_size是关键参数太小会丢失上下文太大会降低检索精度。对于中文500-1000是个不错的起点。嵌入模型BAAI/bge-small-zh-v1.5是智源研究院开源的优秀中文嵌入模型在中文语义相似度任务上表现接近OpenAI的API。这是RAG效果好的核心。检索器search_kwargs{“k”: 3}表示每次检索3个最相关的片段。K值需要权衡太少可能信息不全太多可能引入噪声并增加模型负担。链类型chain_type“stuff”是最简单直接的方式将所有检索到的上下文拼接后送给模型。对于更长的上下文可以考虑map_reduce或refine等复杂链。运行这个脚本你就拥有了一个能基于本地文档回答问题的智能助手。这是RAG最核心的雏形。6. 实战第三步使用Dify搭建可视化AI应用前两步我们通过代码实现了核心能力。现在我们用Dify这个平台以“低代码”的方式将模型和知识库包装成一个可分享的Web应用。6.1 使用Docker Compose快速部署Dify这是最推荐的部署方式能一键解决所有依赖。# 1. 创建一个工作目录并进入 mkdir dify cd dify # 2. 下载官方docker-compose配置文件 wget https://github.com/langgenius/dify/blob/main/docker/docker-compose.yaml # 如果下载失败可以直接创建该文件内容参考Dify官方GitHub仓库 # 3. 启动Dify docker-compose up -d启动后访问http://你的服务器IP:3000即可进入Dify控制台。首次进入需要创建管理员账户。6.2 在Dify中配置模型和知识库Dify的界面非常直观主要配置步骤如下模型配置进入“模型供应商” - “Ollama”。供应商名称Local Ollama模型类型文本生成基础URLhttp://host.docker.internal:11434这是Docker容器内访问宿主机Ollama服务的地址模型名称qwen2.5:7b点击“测试连接”成功即可保存。创建知识库进入“知识库” - “创建知识库”。输入名称如产品手册。在“数据处理方式”中选择“分段处理”这与我们代码中的TextSplitter原理一致。点击“创建”。上传文档并索引进入创建好的知识库点击“上传文件”。支持直接上传PDF、Word、TXT等文件也支持同步Notion、网站。上传后Dify会自动完成文本提取、切分、向量化使用其内置或你配置的嵌入模型和存入向量数据库的过程。这替代了我们之前写的所有文档处理代码。构建AI应用进入“应用” - “创建应用”选择“对话型应用”。在“模型”配置中选择你刚才配置的Local Ollama / qwen2.5:7b。在“提示词编排”中可以设计系统提示词例如“你是一个专业的客服助手请严格根据知识库内容回答问题。如果知识库中没有相关信息请如实告知不知道。”最关键的一步在“上下文”配置中开启“知识库检索”并选择你创建的产品手册知识库。还可以设置检索模式相似度/全文和返回数量。发布与测试点击右上角“发布”。Dify会生成一个独立的Web应用链接和API接口。你可以直接在提供的Web页面上与你的AI客服对话它现在能基于你上传的产品手册进行回答。通过Dify你无需编写前后端代码就拥有了一个功能完备的AI应用包括对话界面、历史记录管理、以及未来可扩展的工作流编排能力。7. 进阶模型微调实战以LoRA为例当你需要模型遵循特定格式、风格或RAG无法解决的复杂推理时微调就派上用场了。我们使用LLaMA-Factory这个强大的微调工具箱它封装了LoRA、QLoRA等多种技术极大简化了流程。7.1 准备微调环境与数据# 1. 克隆LLaMA-Factory仓库 git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory # 2. 安装依赖 pip install -r requirements.txt # 3. 准备数据集 # LLaMA-Factory支持多种格式这里使用简单的JSON格式 # 创建 data/demo_dataset.jsonl每行是一个对话样本 mkdir -p data cat data/demo_dataset.jsonl EOF {instruction: 将以下中文翻译成英文。, input: 今天天气真好。, output: The weather is really nice today.} {instruction: 总结下面文章的核心观点。, input: 人工智能的发展...文章内容, output: 本文核心观点是AI技术正从感知智能向认知智能迈进。} {instruction: 以技术支持的口吻回复用户。, input: 我的账号登录不上了。, output: 您好很抱歉听到您遇到登录问题。请您先检查网络连接并确认用户名和密码是否正确。如果问题依旧请提供更多信息以便我们进一步协助。} EOF7.2 使用Web UI进行微调推荐LLaMA-Factory提供了类似Dify的Web界面让微调变得可视化。# 启动Web UI CUDA_VISIBLE_DEVICES0 python src/train_web.py # 访问 http://localhost:7860在Web界面中按以下步骤操作模型选择在“Model”标签页选择“Model Path”输入模型名称如Qwen/Qwen2.5-7B会自动从Hugging Face下载。数据集配置在“Dataset”标签页选择“JSON”格式并指定你刚创建的demo_dataset.jsonl文件路径。可以预览数据。训练参数切换到“Training”标签页。Training Method: 选择LoRA。LoRA Rank (lora_r): 设置为8。这是LoRA适配器的内在秩通常8或16值越大能力越强但参数越多。LoRA Alpha (lora_alpha): 设置为32。这是缩放参数一般设为rank的2-4倍。Target Modules: 通常选择q_proj,v_proj即注意力层的查询和值投影矩阵这是最常用的设置。Learning Rate: 设置为2e-4。这是关键参数太大容易训飞太小收敛慢。Epochs: 设置为3。对于小数据集3-5个epoch通常足够。开始训练点击“Start Training”。如果使用GPU训练过程会自动开始。你可以在“Log”标签页查看损失下降情况。7.3 合并与使用微调后的模型训练完成后LoRA权重是独立保存的。你需要将其与基础模型合并才能像普通模型一样使用。# 使用LLaMA-Factory提供的脚本合并模型 # 假设你的LoRA权重保存在 ./saves/Qwen2.5-7B/lora_demo 下 export MODEL_NAMEQwen/Qwen2.5-7B export LORA_PATH./saves/Qwen2.5-7B/lora_demo export OUTPUT_PATH./merged_model python src/export_model.py \ --model_name_or_path $MODEL_NAME \ --adapter_name_or_path $LORA_PATH \ --template default \ --finetuning_type lora \ --export_dir $OUTPUT_PATH \ --export_size 2 \ --export_legacy_format False # 合并后的模型保存在 ./merged_model 目录下 # 你可以像使用原始模型一样使用它例如用Ollama加载 # 首先创建一个Modelfile cat Modelfile EOF FROM ./merged_model TEMPLATE {{ .Prompt }} PARAMETER temperature 0.7 EOF # 创建Ollama模型 ollama create my-tuned-model -f ./Modelfile # 运行 ollama run my-tuned-model现在你就拥有了一个经过个性化微调的模型。它可以用于替换之前RAG或Dify应用中的基础模型提供更符合你要求的回答风格。8. 常见问题与排查思路在实践过程中你一定会遇到各种问题。下表汇总了典型问题及其解决方法。问题现象可能原因排查方式解决方案Ollama拉取/运行模型慢或失败1. 网络问题。2. 磁盘空间不足。3. 模型名称错误。1. 检查网络连接。2. 使用ollama pull时观察进度。3. 去 Ollama官网 确认模型名。1. 配置网络代理或使用镜像源非本文讨论范围。2. 清理磁盘空间。3. 使用正确的模型标签如qwen2.5:7b。本地模型回答质量差、胡言乱语1. 模型太小或量化损失严重。2. 提示词Prompt没写好。3. 生成参数如temperature过高。1. 尝试更大的模型如14B, 72B。2. 在Prompt中明确指令和格式。3. 降低temperature如0.1增加确定性。1. 换用更强大的模型或在Ollama中尝试不同量化版本如qwen2.5:7b:q4_K_M。2. 使用更详细的系统提示词约束模型行为。3. 调整num_predict避免生成过长。RAG检索不到正确答案1. 文本切分Chunk不合理。2. 嵌入模型不匹配如用英文模型处理中文。3. 检索Top K值不合适。1. 检查切分后的片段是否破坏了句子完整性。2. 测试嵌入模型在相似任务上的表现。3. 查看检索返回的源文档是否相关。1. 调整chunk_size和chunk_overlap或尝试按标题、段落等语义切分。2. 换用针对你语种优化的嵌入模型如中文用BGE系列。3. 增大K值或尝试混合检索相似度关键词。Dify无法连接本地Ollama1. Docker网络隔离。2. Ollama服务未运行。3. 防火墙端口限制。1. 在Dify容器内执行curl http://host.docker.internal:11434。2. 在宿主机执行ollama list。3. 检查11434端口是否开放。1. 在Dify模型配置中使用http://host.docker.internal:11434作为Ollama地址。2. 确保宿主机Ollama服务已启动 (ollama serve)。3. 如果是远程服务器确保安全组开放了11434端口仅限内网访问切勿公开。微调训练时GPU显存溢出1. 模型太大。2. 批处理大小batch size太大。3. 未使用量化或LoRA。1. 使用nvidia-smi监控显存。2. 查看训练脚本的batch size参数。1. 换用更小的模型或更激进的量化如QLoRA 4-bit。2. 减小per_device_train_batch_size。3. 开启梯度累积 (gradient_accumulation_steps) 来模拟更大batch。微调后模型“失忆”或变笨1. 学习率过高。2. 训练数据太少或质量差。3. 训练轮数过多导致过拟合。1. 观察训练损失曲线是否剧烈震荡。2. 评估模型在通用任务上的表现。1. 降低学习率如从2e-4降到1e-5。2. 增加高质量、多样化的训练数据。3. 减少训练轮数或使用早停法Early Stopping。9. 最佳实践与工程化建议将实验原型转化为稳定可用的生产系统还需要遵循一些工程最佳实践。模型选型原则先小后大从7B参数模型开始实验验证流程。效果不足时再考虑13B、34B甚至70B模型。量化优先优先使用4-bit或5-bit量化版本在性能和精度间取得最佳平衡。q4_K_M是一个通用性很好的选择。中文场景对于中文任务优先选择原生中文模型或中英文双语模型如Qwen、Yi、DeepSeek等系列。RAG效果优化清单预处理文档清理无关字符、页眉页脚、水印。多粒度切分尝试不同chunk_size如256, 512, 1024甚至采用“小Chunk检索大Chunk生成”的两阶段策略。丰富元数据为每个文本片段添加来源、章节标题等元数据便于后续过滤和重排。检索后重排使用更精细的交叉编码器模型对检索出的Top K结果进行重排序提升送入模型的信息质量。评估检索效果构建测试集人工或自动评估检索到的文档是否包含正确答案。提示词工程技巧明确指令在系统提示词中清晰定义角色、任务和格式。提供示例在提示词中给出1-2个清晰的输入输出示例Few-shot Learning效果立竿见影。分步思考对于复杂问题指示模型“一步一步思考”可以提高答案的准确性和逻辑性。引用来源要求模型在答案中引用支持其结论的源文档片段编号增强可信度和可追溯性。生产环境部署考量服务化将模型服务封装成gRPC或HTTP API并使用Nginx等做负载均衡和反向代理。监控与日志记录请求量、响应延迟、Token消耗、错误率等关键指标。记录完整的对话日志用于分析和迭代。缓存策略对频繁出现的相似查询结果进行缓存大幅降低模型调用成本和响应延迟。限流与降级设置API调用频率限制并在后端服务异常时提供友好的降级回复。版本管理对模型、知识库、提示词模板进行版本控制便于回滚和A/B测试。安全与合规底线内容过滤在模型输入输出端部署敏感词过滤和内容安全审核机制。权限控制在Dify等平台设置严格的用户权限和知识库访问控制。数据脱敏用于微调和RAG的原始数据应去除个人隐私和商业机密信息。合规使用遵守开源模型的使用许可协议特别是商用条款。从在本地运行第一个开源大模型到构建起一个能理解私有文档的RAG系统再到通过微调定制模型行为最后用Dify将其打包成可交付的应用——这条路径清晰地勾勒出了当前AI应用开发的主流技术栈。它不再依赖于单一的巨头API而是将主动权交还给了开发者。技术的核心价值在于解决实际问题。本地部署解决了数据安全和成本问题RAG解决了知识更新和准确性问题微调解决了个性化适配问题而Dify这样的平台则解决了工程效率和产品化问题。这套组合拳的掌握意味着你拥有了将AI技术深度融入自身业务闭环的能力。下一步你可以选择一个具体的业务场景如内部知识库问答、智能客服初版、报告生成助手用本文介绍的工具链从头到尾实践一遍。过程中遇到的每一个错误和调优都会让你对这套系统的理解更加深刻。AI大模型的世界不再遥不可及它已经是一套可以安装在本地、可以根据需求定制、可以通过可视化工具编排的开发者工具箱。