硅基铁匠AI / 系统 / 写作
← 返回全部文章
技术与 AI约 5 分钟

第1天：先把 RAG 的基础设施跑起来

第一天先不碰向量检索和问答，先用 Docker Compose 把 FastAPI、PostgreSQL、OpenSearch、Airflow 和 Ollama 跑起来。

这套项目最后会用到 RAG 、向量检索、任务调度和本地模型，但第一天先不碰这些功能，先把运行环境搭起来。

原因很简单。一个 AI Demo 只接模型接口当然很快，但只要准备长期往下做，数据库、搜索、定时任务、日志和服务状态这些东西都绕不过去。与其做到一半再补，不如一开始就把基础服务放好。

这次会用到 FastAPI 、 PostgreSQL 、 OpenSearch 、 Airflow 、 Ollama，统一用 Docker Compose 启动。

FastAPI 负责对外提供接口；论文标题、摘要、正文和其他信息放在 PostgreSQL；搜索交给 OpenSearch；每天抓论文这种任务以后放到 Airflow；Ollama 负责本地模型。第一天 Ollama 只要求服务能起来，不需要急着下载大模型。

整个项目准备分 7 篇做

  1. 把基础服务跑起来。
  2. 抓论文，处理 PDF 、限流、重试和去重。
  3. 用 OpenSearch 做 BM25 搜索。
  4. 做文档切片、 Embedding 和混合检索。
  5. 接本地模型，完成 RAG 。
  6. 加 Redis 和 Langfuse 。
  7. 最后再加 LangGraph 和 Telegram 。

今天只做第一步。

环境准备

README 里要求 Python 3.12 以上，同时需要 Docker Desktop 和 UV 。机器最好有 8GB 以上内存，并留出至少 20GB 磁盘空间。

项目拉下来以后：

cd production-agentic-rag-course
cp .env.example .env
uv sync

Windows PowerShell 下可以把第二条换成：

Copy-Item .env.example .env

.env 暂时不用改太多，现在主要是本地运行。后面用到外部 Embedding 、 Langfuse 或 Telegram 时，再加相应配置。

密钥、 Token 之类也别直接写到代码里，更不要提交到 Git 。

启动

直接执行：

docker compose up --build -d

第一次会下载镜像，时间可能稍长。

启动以后先看：

docker compose ps

不过这里要注意，容器显示 Up 只能说明进程起来了，并不能说明里面的服务已经可以正常访问，所以还得继续检查。

先打开：

http://localhost:8000/docs

这是 FastAPI 自动生成的接口文档。

如果健康检查接口是：

/api/v1/health

可以直接测试：

curl http://localhost:8000/api/v1/health

如果你拿到的代码版本路径不一样，就在 /docs 页面搜 health，没必要自己猜。

接着看 OpenSearch：

curl http://localhost:9200

有正常返回就行。

Airflow 打开：

http://localhost:8080

OpenSearch Dashboards：

http://localhost:5601

Ollama：

http://localhost:11434

这几个地址最好都实际访问一次。

Ollama 暂时不用拉大模型

第一天只检查服务，不要求本地模型已经下载。

如果想顺手测试，可以先拉一个小模型：

make ollama-pull MODEL=llama3.2:1b
make ollama-test MODEL=llama3.2:1b

用 1B 做环境测试已经够了。现在直接拉 8B 、 14B 没什么意义，还会白占磁盘和内存。

Docker 这里有两个地方容易搞混

第一个是地址

比如你在自己电脑浏览器里访问 FastAPI，用：

localhost:8000

但 FastAPI 如果也运行在 Docker 里，它访问 PostgreSQL 时一般不能写 localhost。

因为对 FastAPI 容器来说，localhost 指的是它自己。

容器之间通过 Compose 创建的网络通信，通常直接使用服务名。假设数据库服务叫 postgres，连接地址里就应该写 postgres。

这个问题后面很容易遇到：浏览器明明能访问接口，但程序就是连接不上数据库。先查这里通常没错。

第二个是数据卷

普通执行：

docker compose down

只是停止容器，数据库和 OpenSearch 的数据不会因此消失。

但：

docker compose down --volumes

会把 Volume 一起删除。

如果 PostgreSQL 和 OpenSearch 的数据都放在 Volume 里，这条命令基本相当于把本地数据也重置了。

所以服务起不来时，不要习惯性执行 down --volumes。除非本来就是准备清空环境。

出问题先看日志

例如 API 不正常：

docker compose logs --tail=100 api

OpenSearch 有问题就看 OpenSearch 的日志。

比较常见的情况就是端口占用、配置写错、数据库地址不对，或者 Docker 分配的内存不够。

常用的几个端口是：

8000
8080
5432
9200
5601
11434

电脑本身如果已经安装了 PostgreSQL，5432 就很容易冲突；8080 也经常被其他程序占用。

Windows 用户另外还要注意，PowerShell 、 CMD 、 Git Bash 和 WSL 的命令并不完全一样。有时候提示“命令不存在”，只是 Shell 不一样，并不是项目有问题。

今天做到这里就可以

第一天不用做问答，也不用做 Embedding 和向量检索。

能确认下面几件事就算结束：

  • Docker Compose 正常启动；
  • FastAPI 文档能打开；
  • 健康检查正常；
  • PostgreSQL 、 OpenSearch 、 Airflow 和 Ollama 都能正常运行。

最后再试一下：

docker compose down
docker compose up -d

确认重新启动也没有问题。

后面的论文入库、全文搜索、向量搜索和 RAG 都建立在这些服务上。今天看起来没做什么 AI 功能，但基础环境稳定以后，后面会省不少排查问题的时间。