几个月前，我给团队搭内部知识库的时候，遇到了个瓶颈。我们需要一个能基于私有文档回答问题的聊天机器人，但又绝不能把这些专有数据传给外部 API。我研究了 OpenAI 的 Assistants API——它在检索和函数调用方面做得很棒——但供应商锁定和数据隐私问题成了致命伤，直接被我 pass 了。我需要的是一个能跑在我们自己基础设施上的工具，而且等以后有更好的模型出来时，能灵活替换。
就在这时候，我偶然发现了 Dify。它是一个开源的 LLMOps 平台，提供了一个可视化界面来构建 AI 应用，并且背后还有能集成到任何地方的 API。最赞的是什么？你可以完全自托管（self-host）。在花了几个周末部署它并搭建了实际应用后，我对它的底层运作机制已经有了扎实的把握。来，我带你捋一捋。
让 Dify 跑起来
在本地跑起 Dify 最快的方式就是通过 Docker Compose。开始之前，确保你的机器上已经装好了 Docker 和 Docker Compose。
首先，克隆代码库：
git clone https://github.com/langgenius/dify.git
然后进入 docker 目录并启动它：
cd dify/docker
docker compose up -d
这会拉取好几个容器——一个 PostgreSQL 数据库、一个 Redis 实例、一个 Weaviate 向量数据库、Dify API 以及 Web 前端。我第一次跑的时候，真被它底层运作的复杂程度惊到了。按我的网速，大概花了五分钟才把所有东西拉下来。
容器跑起来后，打开浏览器访问 http://localhost/install 来设置管理员账号。你会看到一个注册页面，在那里创建最初的管理员凭证。搞定之后，你就会进入主控制台。
我早期踩过的一个坑： 我在安装步骤完成前直接访问了 http://localhost，结果只看到白屏。一定要先访问 /install——Dify 需要先初始化它的数据库模式（schema），UI 才能正常渲染。
接入你的模型
这是 Dify 相比其他平台真正大放异彩的地方。它不会把你死死锁定在单一的模型提供商上。开箱即用，它就支持 OpenAI、Anthropic，以及像 Llama 2 这种可以在本地运行或通过模型即服务（MaaS）提供商访问的开源模型。
要配置模型，去 Settings > Model Providers。你会看到一长串支持的供应商列表。如果是 OpenAI，你直接粘贴 API 密钥就行。但如果你想跑本地的 Llama 2 实例，你可以把 Dify 指向你自己的推理端点。
我用在 Ollama 上本地部署的 Llama 2 模型测试了一下。在模型供应商设置里，我添加了一个自定义供应商，地址指向 http://host.docker.internal:11434（因为 Dify 跑在 Docker 里，你需要用这个特殊的主机名才能访问你的宿主机）。保存之后，我在创建应用时就能从下拉菜单里选择我本地的 Llama 2 模型了。
这种多模型支持是真的实用。一开始我用 OpenAI 的 GPT-4 做测试，因为生成的回复更干净；然后到了生产环境，我就切到本地模型，这样数据就能留在我们自己手里。切换过程也就是选个下拉菜单的事——完全不需要改代码。
搭建你的第一个应用
Dify 支持好几种应用类型：聊天机器人、文本补全工具和 Agent。我来带你走一遍搭建知识库聊天机器人的流程，毕竟这也是我最初的需求。
第一步：创建应用
在控制台，点击 Create App，然后选择 Chat App。给它起个名字——我起的是 "Internal Docs Assistant"。
第二步：编写提示词
Dify 提供了一个可视化的提示词编排界面。这可不仅仅是个文本框——你有结构化的区域，分为系统提示词、查询前指令和查询后指令。我写了一段系统提示词，指示机器人只能基于提供的上下文回答问题，如果上下文里没包含答案，就说“我没有足够的信息”。
这个可视化界面还允许你用双花括号语法在提示词里插入变量，比如 {{company_name}}。这样就能很方便地为不同用例做提示词模板，而不用每次都重写。
第三步：添加你的知识库
这是真正让我决定用 Dify 的功能。在应用配置里点击 Context，然后点 Add Dataset。你可以直接上传文档——PDF、文本文件、Word 文档，甚至 CSV 都行。Dify 会自动处理所有的文本预处理、分块和嵌入（embedding）。你完全不需要懂向量数据库或嵌入流水线。
我上传了我们团队的 Confluence 导出文件（大概 50 个 markdown 文件）。Dify 不到两分钟就处理完了。在底层，它在切分文本、生成嵌入，并把它们存进 Docker 部署自带的 Weaviate 向量数据库里。向量数据库的那套复杂性被彻底屏蔽了。
第四步：在测试区试玩
在发布之前，用内置的测试区（playground）测试一下你的应用。我问了它类似“我们的生产环境部署流程是什么？”以及“我们在系统中如何处理客户数据？”这样的问题。答案直接从我们的文档里提取出来，还附带了来源引用，标明了使用了哪些文档块。
当机器人给出了关于我们 VPN 配置的错误答案时，我可以点进日志，看到底检索到了哪些上下文块，并弄明白它为什么会搞混。这种透明度是我直接调用 OpenAI 原始 API 时从未体验过的。
在你自己的应用中使用 API
一旦你的应用在测试区跑得很溜了，你肯定想把它集成到你实际的产品里。Dify 为你创建的每一个应用都提供了后端即服务（Backend-as-a-Service）API。
点击应用左侧边栏的 API Access。你会看到 API 端点和自动生成的 API 密钥。Dify 甚至还提供了多种语言的示例代码。
这是我把它集成到 Python 脚本里的写法：
import requests
API_URL = "http://localhost/v1/chat-messages"
API_KEY = "app-your-api-key-here"
response = requests.post(
API_URL,
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json"
},
json={
"inputs": {},
"query": "What's our deployment process?",
"response_mode": "blocking",
"conversation_id": "",
"user": "test-user"
}
)
result = response.json()
print(result['answer'])
API 支持阻塞（blocking）和流式（streaming）两种响应模式。对于我们的内部工具，为了简单起见我用了阻塞模式，但如果你在搭一个聊天界面，流式模式能给你那种用户期待的打字机效果。
数据标注与改进
直到机器人跑了一周后，我才真正体会到数据标注系统的好。Dify 会记录每一段对话，你可以在 Logs & Annotations 部分查看它们。
当机器人给出了一个差强人意的答案时，你可以直接标注正确的回复。这些标注会变成训练数据，随着时间推移不断提升机器人的表现。我花了一周时间，每天花大概 30 分钟纠正答案，效果提升非常明显——幻觉少了，引用也更精准了。
对于生产级应用来说，这个反馈闭环至关重要。原始的大模型输出在第一天绝对不可能是完美的，而 Dify 给了你一套工具，让你不用改代码就能系统性地改进它们。
实用技巧与客观局限
在生产环境跑了 Dify 几个月后，以下是我的心得总结：
技巧：
- 开发环境用 Docker Compose 起步就行，但如果是生产环境，建议看看代码库里的 Kubernetes 配置。Docker Compose 对小团队来说没问题，但要扩容的话，你需要更正规的容器编排。
- 上传文档时，留意分块（chunking）设置。默认的分块大小对大多数情况都适用，但我发现，对我们的技术文档来说，把分块大小降到 300 个 token 能提高回答的精准度。
- 利用对话变量功能在多轮对话中保持上下文。这对处理复杂查询的帮助极大。
- 敲定方案前多测几个模型。我发现简单的问答用 GPT-3. Turbo 就够了，而重逻辑推理的任务则必须上 GPT-4。在可能的地方用更便宜的模型，能大幅削减我们的成本。
局限：
- 自托管版本需要你自己管理基础设施。如果凌晨两点容器崩了，那就是你自己的锅。开源版本目前没有托管选项。
- 插件系统还在完善中。虽然 Dify 计划支持兼容 ChatGPT 的插件，但与 OpenAI 的生态系统相比，目前的插件能力还比较有限。
- 文档更新不是自动的。当我们的文档有变动时，我得重新上传文件并重建数据集。目前还没有与外部知识库的实时同步功能。
- 混合使用 AGPL+MIT 许可证意味着你需要搞清楚其中的意味。AGPL 组件要求，如果你将软件作为服务分发，就必须开源你的修改。如果你打算基于 Dify 构建商业产品，请仔细阅读许可证。
尽管有这些局限，Dify 已经成了我构建大模型应用的首选。可视化的提示词编排省去了数小时的迭代，RAG 流水线不用你去折腾向量数据库就能直接用，而自托管选项意味着数据由我自己掌控。对于任何需要构建 AI 应用、又不想把专有数据发送给第三方服务的团队来说，Dify 绝对值得认真考虑。