构建企业内部知识库系统RAG全栈项目

我最近做了个很时髦的项目，内部知识库系统，主要是为了解决企业内部资料无法公开，大模型无法根据企业内部情况回答专业问题的难题。用户问普通问题，大模型自己回答，用户问企业内部相关问题，大模型会根据数据库数据整理出相关答案，再由大模型归纳总结输出答案，大致架构模型如上图，简单介绍一下这个项目架构。项目核心分为五个部分：

1. 本地ollama大模型服务

2. 上传文档进行向量化的python项目

3. 根据知识库数据和用户问题生成答案的gin项目

4. 前端界面vue3项目

5. 向量数据库

目前这个项目用的模型是这两个：qwen3-embedding:4b和qwen2.5:3b ，其他几个模型之前也用过，目前来说基于我的电脑配置这两个模型还不错，我的电脑是mac mini m4芯片 16g内存。第一个是把文档向量化的模型，第二个是根据检索到的数据生成回答的模型

这个是上传文档生成向量化数据的项目，是个python langchain 项目，我为什么要把上传文档和返回数据分为两个项目呢？我主要是有以下考虑：

• AI项目大多都是python项目，生态很完善

• python语言太慢，而且我喜欢go语言，刚开始用python那叫一个难受啊！一边写一边骂，什么垃圾语言？fuck！但是没有办法，它就是这个领域的老大

• 上传文档这个功能对性能速度不敏感，

• 生成答案对性能很敏感，快就是快，慢就是慢，go语言我熟悉啊，

  这是gin项目的大致文件目录，目前第一版功能很少，后续想到了再加

  这是前端对话问答项目，目前比较简单，vue3项目，把问答界面单独分出来一个独立项目主要是考虑到后续可以做个electron桌面软件，只要做个壳，这个前端项目可以直接放进去，哈哈哈哈

这是向量数据库的可视化界面，使用docker-compose一键启动

 复制代码version: '3.5'services:  etcd:    container_name: milvus-etcd    image: quay.io/coreos/etcd:v3.5.23    environment:      - ETCD_AUTO_COMPACTION_MODE=revision      - ETCD_AUTO_COMPACTION_RETENTION=1000      - ETCD_QUOTA_BACKEND_BYTES=4294967296      - ETCD_SNAPSHOT_COUNT=50000    volumes:      - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd    command: etcd -advertise-client-urls= -listen-client-urls  --data-dir /etcd    healthcheck:      test: ["CMD", "etcdctl", "endpoint", "health"]      interval: 30s      timeout: 20s      retries: 3    networks:      - milvus-network  minio:    container_name: milvus-minio    image: minio/minio:RELEASE.2023-03-20T20-16-18Z    environment:      MINIO_ACCESS_KEY: minioadmin      MINIO_SECRET_KEY: minioadmin    ports:      - "9001:9001"      - "9000:9000"    volumes:      - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/minio:/minio_data    command: minio server /minio_data --console-address ":9001"    healthcheck:      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]      interval: 30s      timeout: 20s      retries: 3    networks:      - milvus-network  standalone:    container_name: milvus-standalone    image: milvusdb/milvus:v3.0-beta    command: ["milvus", "run", "standalone"]    security_opt:    - seccomp:unconfined    environment:      ETCD_ENDPOINTS: etcd:2379      MINIO_ADDRESS: minio:9000      MINIO_ACCESS_KEY_ID: minioadmin      MINIO_SECRET_ACCESS_KEY: minioadmin    volumes:      - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus    ports:      - "19530:19530"      - "9091:9091"    depends_on:      etcd:        condition: service_healthy      minio:        condition: service_healthy    networks:      - milvus-network  attu:    container_name: milvus-attu    image: zilliz/attu:v2.4    environment:      MILVUS_URL: standalone:19530    ports:      - "3000:3000"    depends_on:      - standalone    networks:      - milvus-networknetworks:  milvus-network:    name: milvus-network    driver: bridge

下面说说对这个项目的一些思考

1，为什么使用的是本地ollama模型？

主要是经济问题，在线大模型的token消耗太快了，看着心疼，但是用docker跑的ollama容器又有点慢，主要是我的mac系统对docker性能有限制，之前我也是用的docker运行的ollama容器，ollama虽然不是性能最好，但是足够方便

2，我对AI编程的感受

我最先用的是豆包，在豆包里问问题，它生成代码，再复制粘贴，感觉差点意思，它生成的代码不满意，还总是漏掉不少，如果有下划线_它还会价格转译附

后来就用deepseek，这个用了很长时间，生成代码质量不错，速度快，但是后来我发现它写python很糟糕，有时候一段代码报错了，它反复的改反复报错，有时候整了一天，代码越改越糟糕，我算是服了，deepseek写python真的不行

说说字节的TRAE，这个我也用了，还行，主要是我感觉参与感不强，我一般会自己设计好项目架构，把架子搭起来，再让它改，也会遇到deepseek那种绕弯子的现象，有时候一个问题反复改，反复报错，

cloud code 也用了，我都忘记了，都都充钱了，忘记用了，后续深入用用了再说，

这个项目是阿里百炼大模型生成的代码，很棒，我只要把项目架构描述清楚，它写的代码还是很不错的，直接就跑起来了，给阿里百炼点个赞，目前用的还不深，不做过多评价，

3，前端的困境

我是前端开发出身，一直想做全栈，但是一直没有扎进去，深度使用了AI编程后我有切身体会，AI写前端很容易，写出来的代码都不用改，直接出效果，整的我心慌的一批。AI写后端还行，但是差点意思，有时候还需要自己改改，或者告诉AI，哪里需要改改，所以AI对前端的挤压是最严重的，如果你也是个前端，多给自己想个出路，除非你在一些内网开发的环境里工作，那里对技术更新不敏感，

项目仓库

python项目

gin项目

前端项目