From 66472e843af006194505ce2c8a6f6fddf4c2f27e Mon Sep 17 00:00:00 2001 From: kfjdgnf123 Date: Fri, 26 Sep 2025 22:08:19 +0800 Subject: [PATCH] =?UTF-8?q?delete:=20=E5=88=A0=E9=99=A4=E6=96=87=E4=BB=B6?= =?UTF-8?q?=20openGauss-AIEval/=E7=BB=93=E9=A1=B9=E6=8A=A5=E5=91=8A.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: kfjdgnf123 --- openGauss-AIEval/结项报告.md | 76 -------------------------------- 1 file changed, 76 deletions(-) delete mode 100644 openGauss-AIEval/结项报告.md diff --git a/openGauss-AIEval/结项报告.md b/openGauss-AIEval/结项报告.md deleted file mode 100644 index 737d1448..00000000 --- a/openGauss-AIEval/结项报告.md +++ /dev/null @@ -1,76 +0,0 @@ -

结项报告

- -org-LOGO_2532761e1a394fb0ab413f932f608632 - -
-

项目名称：openGauss 向量数据库 AI 评估框架对接最佳实践输出

-

项目主导师：ce

-

申请人：张凌浩

-

时间：2025.09.26

-

邮箱：lh.zhang.work@gmail.com

-
- -## 1. 项目信息 - -### 1.1 方案描述 -本项目旨在将 openGauss 向量数据库（DataVec）与主流 AI 评估框架（如 Arize Phoenix、DeepEval 和 FiftyOne）进行对接，并输出最佳实践教程。方案包括： -- 基于 openGauss Docker 部署指导，完成数据库实例的部署。 -- 参考 Milvus 和 Weaviate 等向量数据库的对接文档，设计并实现 openGauss 与 Arize Phoenix（用于 RAG 管道评估）、DeepEval（用于检索器和生成器评估）和 FiftyOne（用于数据集管理和视觉搜索）的集成。 -- 编写详细教程文档，包括环境准备、RAG 管道定义、测试流程和评估实践，并将文档提交至 [openGauss 社区仓库](https://gitcode.com/opengauss/examples)。 -- 核心技术栈涉及 Python 编程、Docker 部署、向量嵌入模型（如 Qwen/Qwen3-Embedding-0.6B）和 LLM（如 DeepSeek），确保教程的可复现性和实用性。 -- 项目产出以 Markdown 格式的教程文件为主，包含代码示例、流程图和结果展示，旨在帮助开发者快速构建高效的 RAG 系统和视觉搜索应用。 - -### 1.2 时间规划 -项目总时长预计 400 小时，分阶段规划如下： -- **阶段 1: 准备与部署（约 80 小时，Week 1-2）**：学习 openGauss 部署，安装 Docker 并配置数据库实例；调研 Arize Phoenix、DeepEval 和 FiftyOne 的 API 和对接要求。 -- **阶段 2: 框架对接与代码实现（约 200 小时，Week 3-6）**：分别实现三个框架的集成，包括 RAG 类定义、嵌入计算、检索评估和视觉搜索；编写测试脚本并调试。 -- **阶段 3: 文档编写与优化（约 80 小时，Week 7-8）**：整理代码为教程文档，添加流程图、结果示例和注意事项；进行多次测试以确保可复现。 -- **阶段 4: 提交与审阅（约 40 小时，Week 9）**：提交文档至社区仓库，响应反馈并迭代。 - -实际执行中，时间分配基本符合规划，总耗时约 380 小时，略提前完成。 - -## 2. 项目进度 - -### 2.1 已完成工作 -根据原定方案，我已全面完成项目要求的工作成果： -- **openGauss 部署**：成功使用 Docker 部署 openGauss 7.0.0-RC1 版本实例，参考[官方文档](https://docs.opengauss.org/zh/docs/latest-lite/docs/InstallationGuide/容器镜像安装.html)。配置了数据库连接参数（如 host、port、user、password），并验证了向量扩展（DataVec）的可用性。 -- **框架对接与教程输出**： - - **Arize Phoenix 对接**：实现了 RAG 管道的构建，使用 openGauss 作为向量存储。教程包括环境准备、RAG 类定义（load、retrieve、answer 方法）、测试流程，以及使用 Phoenix 进行幻觉评估和问答评估。输出文件：`arize-phoenix-opengauss-tutorial.md`，包含代码示例、仪表盘截图和 CSV 结果展示。 - - **DeepEval 对接**：集成 DeepEval 评估检索器（上下文精确度、召回率、相关性）和生成器（回答相关性和忠实性）。教程提供了自定义 LLM（DeepSeek）的配置方法，并附带评估流程图。输出文件：`deepeval-opengauss-tutorial.md`。 - - **FiftyOne 对接**：将 openGauss 注册为 FiftyOne 的相似性后端，实现图像数据集的嵌入计算和视觉相似性搜索。教程包括后端服务类注册、数据集加载和搜索可视化。输出文件：`fiftyone-opengauss-tutorial.md`，包含命令行输出和仪表盘截图。 -- **社区提交**：所有教程文档已提交至 [openGauss 社区仓库](https://gitcode.com/opengauss/examples)。文档采用中文撰写，支持 AArch64 架构，并确保代码的可执行性。 -- **额外优化**：在教程中添加了错误处理（如依赖安装报错的解决方案）和可视化元素（如流程图），提升了文档的实用性。总计输出三个完整 Markdown 文件与对应的代码文件夹，覆盖从部署到评估的全流程。 - -这些成果严格遵循原定方案，确保教程的自包含性和易用性，帮助开发者快速上手 openGauss 在 AI 场景中的应用。 - -### 2.2 遇到的问题及解决方案 -在项目执行过程中，我遇到了一些挑战，主要集中在环境配置和框架兼容性上： -- **问题 1: Docker 部署 openGauss 时端口冲突和权限问题**。 - - **解决方案**：通过修改 Docker 命令中的端口映射（e.g., -p 8888:5432）避免冲突；使用 --privileged 参数授予容器 root 权限，并参考官方 Issue 调试日志。最终成功启动实例，并通过 psql 客户端验证连接。 -- **问题 2: Python 依赖冲突（如 uvicorn 版本不兼容 Arize Phoenix）**。 - - **解决方案**：参考 GitHub Issue（e.g., Arize-ai/phoenix #9569），降级 uvicorn 到 0.34.0 版本（pip install uvicorn==0.34.0）。 -- **问题 3: FiftyOne 后端注册失败，脑键（brain_key）配置无效**。 - - **解决方案**：深入阅读 [FiftyOne 文档](https://docs.voxel51.com/brain.html#similarity-backends)，自定义 OpenGaussSimilarityConfig 类，并手动编辑 ~/.fiftyone/brain_config.json 文件。多次测试后，确保索引创建和搜索正常。 - -这些问题通过查阅官方文档、Stack Overflow 和 GitHub Issue 得到解决，提升了我的调试能力和问题定位技能。 - -### 2.3 总结与心得 -通过这个项目，我深刻体会到开源数据库在 AI 生态中的潜力。openGauss 的向量存储能力与 AI 框架的结合，不仅提升了 RAG 系统的性能，还为视觉搜索提供了高效后端支持。最初，我对向量数据库和评估框架较为陌生，但通过调研和实践，掌握了从部署到集成的全链路知识，包括 psycopg2 的数据库交互、LangChain 的 LLM 集成和 FiftyOne 的计算模块。 - -心得方面： -- **技术成长**：学会了 Docker 容器化、Python 高级编程（如类继承和 SQL 注入防范）和 AI 评估指标（如幻觉评估、上下文相关性）。这让我从单纯的编码转向系统级设计。 -- **开源精神**：参与 openGauss 社区让我理解了贡献的重要性。文档的编写过程强调了清晰性和社区友好性，我学会了使用 Markdown 工具（如 Typora）和流程图软件（如 Draw.io）来增强可读性。 -- **挑战与收获**：项目中遇到的兼容性问题让我养成了阅读源代码的习惯（如分析 FiftyOne 的 SimilarityIndex 类），这远比表面学习更有价值。同时，项目让我意识到 AI 评估的复杂性——不仅仅是准确率，还涉及忠实性和相关性。 -- **建议**：未来类似项目可增加单元测试框架（如 pytest），以自动化验证教程代码；同时，探索更多框架（如 LangSmith）以扩展 openGauss 的生态。 - -总体而言，这个项目不仅是技术实践，更是开源贡献的起点，我对数据库 + AI 的交叉领域充满热情。 - -### 2.4 后续工作安排 -项目已基本完成，无需大幅调整工作计划。但为进一步完善，我计划： -- **短期（1-2 周）**：监控社区反馈，修复潜在 Bug；添加更多示例数据集（如自定义图像集）。 -- **中期（1 个月）**：扩展教程，支持更多 LLM和嵌入模型；提交 PR 到 openGauss 官方文档仓库。 -- **长期**：探索 openGauss 在生产环境中的优化（如 HNSW 索引参数调优），并撰写一篇博客分享经验。 - -如果社区有新需求（如支持其他评估框架），我愿意继续迭代，无需调整原计划。 - -## Pull Requests \ No newline at end of file