用 RAG 对比评测 OpenAI o3 与 Claude 3.7 Sonnet基于 GitHub 代码检索的端到端评测与可观测性实战【免费下载链接】ai-engineering-hubIn-depth tutorials on LLMs, RAGs and real-world AI agent applications.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-hub导读本项目以对 GitHub 开源仓库做 RAG 检索增强问答为统一基准让 OpenAI o3-mini 与 Claude 3.7 Sonnet 两款模型回答同一批代码生成类问题并借助 CometML Opik 构建从链路追踪Tracing到自动化评测Evaluation的端到端可观测流水线。读完本文你将掌握如何用 LlamaIndex 将 GitHub 仓库切分成可检索的代码节点、如何搭建可切换模型的 Streamlit 问答界面以及如何用 Opik 的 LLM-as-a-Judge 指标对两个模型的生成结果做量化对比。一、项目定位为什么要在代码 RAG上做模型对比o3-vs-claude-code目录围绕一个核心问题展开针对真实开源仓库的代码问答场景OpenAI o3-mini 与 Claude 3.7 Sonnet 谁的生成质量更高官方 README 给出了明确定位——Compare Claude 3.7 Sonnet and OpenAI o3 using RAG over code (GitHub)同时强调该项目leveraged CometML Opik to build an e2e evaluation and observability pipeline for a RAG application借助 Opik 为 RAG 应用构建端到端评测与可观测性流水线。换句话说它把两件事结合在了一起一个可控的对比实验环境同一个检索管线、同一份上下文、同一组问题仅替换底层 LLM从而把模型能力差异从应用实现差异中剥离出来一套可复现的评测机制用带人工标注参考答案ground truth的测试集配合 LLM 裁判打分量化比较两个模型的输出质量而不是靠肉眼观感下结论。二、整体架构与工作流从 app.py 与 Opik for LLM evaluation.ipynb 的源码结构看整个链路可分为四个阶段GitHub URL → 克隆仓库 → 按文件类型解析与切分(CodeSplitter / MarkdownNodeParser) → 向量化(FastEmbed bge-base-en-v1.5) → 建索引(Qdrant / 内存) → 检索(similarity_top_k4) → 流式问答(o3-mini 或 Claude 3.7 Sonnet) → Opik 追踪(LlamaIndexCallbackHandler) → LLM Judge 评测打分交互阶段由 Streamlit 应用承载streamlit run app.py评测阶段由 Notebook 承载Opik for LLM evaluation.ipynb评测数据在 data/test.csv 中。两个阶段复用同一套解析、切分、索引与查询逻辑保证了评测的差异只来自模型本身这一实验前提。三、环境准备与安装1. 获取 API Key按 README 的说明运行本项目需要三个密钥密钥用途Opik API Key将追踪与评测结果上报到 Opik 平台使用云端版时必需OpenAI API Key调用 o3-mini 模型以及评测阶段作为裁判模型gpt-4oAnthropic API Key调用 Claude 3.7 Sonnet将这些密钥写入项目根目录的.env文件。README 中提示参考.env.example当前仓库副本中未包含该文件但结合源码中的load_dotenv()调用可推断典型的键名形如OPIK_API_KEY、OPENAI_API_KEY、ANTHROPIC_API_KEYapp.py 第 29 行与 Notebook 均通过python-dotenv加载环境变量。2. 安装依赖要求Python 3.11 或更高版本Notebook 的元数据中也标注了 Python 3.11.11README 给出的安装命令如下pip install opik llama-index llama-index-agent-openai llama-index-llms-openai llama-index-llms-anthropic --upgrade --quiet除上述包外从 app.py 的导入语句还可以看到实际运行还依赖以下组件streamlit交互界面、python-dotenv环境变量、nest_asyncioNotebook 中异步兼容、qdrant-client与llama-index-vector-stores-qdrantQdrant 向量库、llama-index-embeddings-fastembed本地嵌入模型、llama-index-embeddings-huggingfaceNotebook 中的备选嵌入方案。建议使用虚拟环境安装避免与系统 Python 环境冲突。四、运行交互式对比应用安装完成后在o3-vs-claude-code目录下启动streamlit run app.py启动后在侧边栏可以完成三个关键操作对应 app.py 第 102-192 行的侧边栏逻辑选择模型在OpenAI o3-mini与Claude 3.7 Sonnet之间切换第 105-108 行的model_options字典输入 GitHub 仓库 URL例如https://github.com/Lightning-AI/LitServe点击 Load触发克隆、解析、建索引、构建查询引擎的完整流程。页面顶部标题即为 Claude 3.7 Sonnet vs OpenAI o3!并在右侧提供 Clear ↺ 按钮一键清空会话对应reset_chat()函数。五、核心实现剖析app.py 逐模块解读1. 模型抽象一个函数支持双 Providerst.cache_resource def load_llm(model_name, provideropenai): if provider anthropic: return Anthropic(modelmodel_name) elif provider openai: return OpenAI(modelmodel_name) else: raise ValueError(fUnsupported provider: {provider})app.py 第 32-39 行st.cache_resource保证同一模型实例在多次交互中复用避免重复初始化造成的资源浪费。这是实现同一个 RAG 管线、仅换模型的关键抽象点——后续只需在Settings.llm上覆盖赋值即可无缝切换推理后端。2. GitHub URL 解析与仓库克隆def parse_github_url(url): pattern rhttps://github\.com/([^/])/([^/]) match re.match(pattern, url) return match.groups() if match else (None, None) def validate_owner_repo(owner, repo): return bool(owner) and bool(repo)app.py 第 43-53 行URL 解析通过正则提取owner与repo随后调用git clone将仓库克隆到当前工作目录第 130-131 行若本地目录./{repo}不存在则克隆已存在则直接复用。克隆失败或 URL 不合法时界面会分别提示 Error occurred while cloning the repository, carefully check the url 与 Invalid owner or repository。3. 按文件类型解析与切分代码 RAG 的关键def parse_docs_by_file_types(ext, language, input_dir_path): files glob.glob(f{input_dir_path}/**/*{ext}, recursiveTrue) if len(files) 0: loader SimpleDirectoryReader( input_dirinput_dir_path, required_exts[ext], recursiveTrue ) docs loader.load_data() parser ( MarkdownNodeParser() if ext .md else CodeSplitter.from_defaults(languagelanguage) ) nodes parser.get_nodes_from_documents(docs) return nodes return []app.py 第 55-73 行应用默认处理五类文件第 134-140 行扩展名解析器语言参数.mdMarkdownNodeParser—按 Markdown 结构切分.pyCodeSplitter.from_defaults(languagepython)python.ipynbCodeSplitterpython.jsCodeSplitterjavascript.tsCodeSplittertypescript值得说明的是代码文件与自然语言文档的切分策略完全不同CodeSplitter会尽量在类、函数等逻辑边界处切分保留代码的语义完整性MarkdownNodeParser则按标题层级组织节点。这正是对代码仓库做 RAG区别于普通文档 RAG 的核心技术点。每个扩展名处理完成后会打印Found N files ... / Processed N nodes ...日志便于排查仓库是否有可检索内容。4. 向量化与索引构建Settings.embed_model FastEmbedEmbedding(model_nameBAAI/bge-base-en-v1.5) try: index create_index(nodes) # Qdrant 向量库路径 except: index VectorStoreIndex(nodesnodes) # 内存索引兜底app.py 第 150-154 行嵌入模型采用BAAI/bge-base-en-v1.5通过FastEmbedEmbedding本地运行无需单独部署 Embedding 服务。索引构建有两条路径首选 Qdrantcreate_index()第 77-86 行会为每个会话生成一个uuid4()唯一集合名chat_with_docs_{uuid}通过QdrantVectorStore与StorageContext写入向量库天然支持会话隔离与持久化兜底内存索引从源码结构看app.py 第 152 行调用create_index(nodes)时未传入client参数而函数签名要求该参数因此该调用会抛出TypeError并被except捕获实际大多走VectorStoreIndex(nodesnodes)的内存索引路径Notebook 中的评测流程则直接使用内存索引。这一点体现了可插拔存储的设计向量库不可用时应用仍可运行。5. 检索与生成参数query_engine index.as_query_engine(streamingTrue, similarity_top_k4)app.py 第 159 行streamingTrue开启流式输出前端逐 token 渲染similarity_top_k4检索阶段取与问题最相似的 4 个节点作为上下文注入 Prompt。6. 自定义 Prompt 模板qa_prompt_tmpl_str ( Context information is below.\n ---------------------\n {context_str}\n ---------------------\n Given the context information and your knowledge, I want you to think step by step to answer the query in a crisp manner, incase case you dont know the answer say I dont know!.\n Query: {query_str}\n Answer: ) qa_prompt_tmpl PromptTemplate(qa_prompt_tmpl_str) query_engine.update_prompts( {response_synthesizer:text_qa_template: qa_prompt_tmpl} )app.py 第 162-175 行该模板要求模型基于上下文step by step思考并简洁作答无法回答时明确输出I dont know!——这一约束对评测尤其重要可以抑制模型的幻觉式作答。而 Notebook 中的评测版模板更进一步见下文第八节强制要求回答必须包含代码片段与代码生成评测的定位完全对齐。7. 流式聊天界面streaming_response query_engine.query(prompt) for chunk in streaming_response.response_gen: full_response chunk message_placeholder.markdown(full_response ▌) message_placeholder.markdown(full_response)app.py 第 231-239 行用户输入通过st.chat_input捕获追加到st.session_state.messages维护会话历史回答期间用▌光标模拟打字效果完成后将完整回答写回历史记录。reset_chat()则负责清空messages与context并触发gc.collect()释放内存。六、评测数据集data/test.csv评测样本存放在 data/test.csv采用question,answer两列结构question是待评测问题answer是人工编写/认可的参考答案ground truth。从数据内容看测试集围绕LitServe 框架Lightning AI 的推理服务库设计覆盖了五种典型场景SimpleLitAPI输入一个数返回平方与立方的和server.py完整示例文本嵌入 API基于 SentenceTransformerBAAI/bge-large-en-v1.5 LitServe 构建RAG APILlamaIndex Qdrant 向量库 Ollama 本地 llama3.2 的组合Whisper 私有 API将 OpenAI Whisperlarge模型、GPU 加速封装为推理服务随机森林部署加载model.pkl并封装为分类 API。设计精巧之处在于所有问题都是描述性需求 具体约束如指定模型、端口、批大小、加速器等答案要求产出完整可运行的代码。这种设定对模型的能力区分度很高——不仅能检验是否理解需求还能检验是否产出符合约束的语法正确代码天然适配 LLM-as-a-Judge 的自动打分。七、用 Opik 构建端到端可观测性1. 初始化与配置import opik opik.configure(use_localFalse)Notebook 第一个代码单元use_localFalse表示使用 Opik 云端需在.env中配置 Opik API Key若要本地部署 Opik 服务可改为use_localTrue并指向本地地址。2. 追踪 RAG 全链路调用from llama_index.core.callbacks import CallbackManager from opik.integrations.llama_index import LlamaIndexCallbackHandler opik_callback_handler LlamaIndexCallbackHandler() Settings.callback_manager CallbackManager([opik_callback_handler])这是整个可观测性体系的基石LlamaIndexCallbackHandler会自动把LlamaIndex 内部所有操作文档加载、节点切分、embedding、检索、LLM 调用、响应合成以 Trace/Span 的形式上报到 Opik。开发者无需在业务代码中埋点就能在 Opik 平台看到一次问答从检索到哪 4 个节点到模型生成了什么的完整调用链极大降低了 RAG 应用的调试成本。3. 在评测中复用同一套 RAG 管线Notebook 中的setup_chat_engine(github_url, model_provider...)与 app.py 高度同构解析 URL → 克隆 → 按文件类型切分 → 建索引 → 配置 LLM → 构建streamingTrue, similarity_top_k4的查询引擎。值得注意的两点差异支持Claude 3.5 Sonnetclaude-3-5-sonnet-20240620作为第三个可选项评测版 Prompt 强制要求代码输出Given the context information above, you must always include a code snippet in your response. Think step by step to answer the query, and then provide a relevant code example that demonstrates the concept. ... If you dont know the answer, say I dont know! but still provide a minimal code example of what you think might work.Notebook 示例中以https://github.com/Lightning-AI/LitServe作为评测仓库与 test.csv 的题目主题一致调用方式为model_name Claude 3.7 Sonnet query_engine setup_chat_engine(github_url, model_providermodel_name) response query_engine.query(What is this repo about?)八、LLM-as-a-Judge自动化评测实现1. 创建评测数据集from opik import Opik client Opik() dataset client.get_or_create_dataset(nameEval Code Generation)评测前需要把 test.csv 中的问答对导入该数据集Notebook 已创建名为Eval Code Generation的数据集。2. 包装评测任务from opik import track track def my_llm_application(input: str) - str: response query_engine.query(input) return str(response) def evaluation_task(x): return {output: my_llm_application(x[input])}track装饰器让每次评测调用也被记录到 Opik实现评测本身可观测。3. 自定义 LLM Judge 指标Notebook 定义了一个完整的LLMJudgeMetric类继承opik.evaluation.metrics.base_metric.BaseMetric核心逻辑如下裁判模型默认gpt-4o通过openai客户端调用打分维度正确性是否实现相同功能、完整性是否包含必要组件、效率实现方式是否同样高效并明确只要功能等价就给高分、只关注代码与功能忽略文本输出格式强制要求裁判返回严格的 JSON{score: 0~1之间的数}其中 0 表示完全不相关/错误1 表示与参考答案功能等价落库通过score_result.ScoreResult(name..., value...)将分数封装为 Opik 指标。code_quality_metric LLMJudgeMetric()4. 运行评测实验from opik.evaluation import evaluate evaluation evaluate( datasetdataset, taskevaluation_task, experiment_namemodel_name, # 用模型名区分实验 scoring_metrics[code_quality_metric], experiment_config{model: gpt-3.5-turbo} )这就是整个对比实验的收敛点为每个模型各跑一次evaluateexperiment_name分别设为 OpenAI o3-mini 与 Claude 3.7 Sonnet即可在 Opik 平台同一数据集上并排对比两个模型的平均分、逐样本得分分布与失败案例。experiment_config记录实验元信息如推理模型保证实验可复现、可追溯。九、对比实验的设计要点与落地建议综合整个项目这套代码 RAG 双模型对比 Opik 评测的方案在工程上有几个值得借鉴的设计决策控制变量解析、切分、嵌入、检索、Prompt 全部固定唯一变量是底层 LLM使得分差异能归因到模型本身面向代码的评测口径测试题要求产出完整可运行代码裁判按功能等价性而非文本相似度打分避免传统 ROUGE/BLEU 在代码场景的失效问题评测与交互解耦交互看效果用 Streamlitapp.py批量量化用 NotebookOpik for LLM evaluation.ipynb两者共享核心管线代码可独立演进可观测性贯穿始终追踪Callback Handler与评测Judge 指标、实验管理都收敛到 Opik 单一平台链路视图 得分视图 数据集管理一站式完成。注意事项与前提本方案依赖 OpenAI、Anthropic 与 Opik 三方服务的 API Key且需要能访问外网以克隆仓库与下载模型/依赖嵌入模型与切分参数similarity_top_k4对结果有影响若要横向对比其他评测集建议保持这些参数一致并记录在experiment_config中。十、在仓库中继续深入如果你想进一步研究或复用本方案可在仓库内继续查看以下文件o3-vs-claude-code/app.pyStreamlit 交互应用完整实现模型抽象、仓库解析、代码切分、向量检索、流式问答o3-vs-claude-code/Opik for LLM evaluation.ipynbOpik 追踪与 LLM Judge 评测的完整 Notebook含自定义指标类与evaluate调用o3-vs-claude-code/data/test.csv评测数据集问题 参考答案可自行扩充更多代码生成场景o3-vs-claude-code/data_prep.ipynb数据准备 Notebook当前为空可结合 data/test.csv 自行补充生成逻辑仓库中还有多个可交叉参考的项目deploy-agentic-ragLitServe 部署 RAG API、github-rag本地代码仓库问答、eval-and-observabilityOpik 评测与可观测性专项等可与本项目的评测管线相互印证。通过本项目的实践你将同时掌握两条硬技能基于 LlamaIndex 对代码仓库构建 RAG以及用 Opik 搭建追踪 评测 实验对比的端到端可观测体系——这两者正是当前 RAG 应用从原型走向生产的必备能力。【免费下载链接】ai-engineering-hubIn-depth tutorials on LLMs, RAGs and real-world AI agent applications.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-hub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考