资讯动态

基于 Opik G-Eval 与 OpenRouter 的推理模型对比评测实战:gpt-oss-vs-qwen3 项目全解析

发布时间:2026/9/10 13:27:55 来源:尧图企业网站定制
基于 Opik G-Eval 与 OpenRouter 的推理模型对比评测实战gpt-oss-vs-qwen3 项目全解析【免费下载链接】ai-engineering-hubIn-depth tutorials on LLMs, RAGs and real-world AI agent applications.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-hub本文以 ai-engineering-hub 仓库中的gpt-oss-vs-qwen3项目为主体系统讲解如何借助 LiteLLM OpenRouter 同时驱动两套推理模型默认对比 GPT-oss 与 Qwen3-Thinking并利用 Comet Opik 的 G-Eval 指标对回答进行四维打分。读完本文你将掌握一套双模型并跑 实时流式展示 LLM-as-a-Judge 自动评分 可视化对比的推理能力评测流水线的完整搭建方法可以直接复用到任意模型对比评测场景。项目定位与核心思路推理模型reasoning model区别于普通对话模型的关键在于它会先产出隐藏的思考过程reasoning tokens再输出最终答案。GPT-oss、Qwen3 等模型均具备该能力但如何公平、可量化地比较它们的推理质量一直是实践难点。gpt-oss-vs-qwen3项目给出的答案是同一问题双模型并行作答 → 展示各自思考过程与最终回答 → 使用 Opik 的 G-Eval 指标自动评测 → 输出分数与可视化图表。整个流程围绕四个支柱技术构建见 README技术在本项目中的职责LiteLLM统一模型编排层屏蔽不同厂商 API 差异OpenRouter通过单一网关访问 OpenAI GPT-oss、Qwen3 等多个模型OpikComet提供 G-Eval 等评测指标与可观测性Streamlit构建交互式对比 UI项目采用uv作为包管理器依赖声明位于 pyproject.toml要求python 3.12。核心依赖包括litellm1.71.1、opik1.8.13、streamlit1.45.1、plotly6.1.2、pandas2.2.3、python-dotenv1.1.0以及nest-asyncio、anthropic等。快速开始环境配置与启动1. 拉取代码并安装依赖该目录位于 ai-engineering-hub 仓库内若需独立运行先克隆仓库并进入目标目录git clone https://gitcode.com/GitHub_Trending/ai/ai-engineering-hub cd ai-engineering-hub/gpt-oss-vs-qwen3确保本机安装 Python 3.12 及以上版本然后用 uv 同步依赖uv syncuv sync会依据pyproject.toml与已锁定的 uv.lock 创建虚拟环境并安装全部依赖。2. 配置环境变量将项目中的.env.example复制为.envcp .env.example .env该文件内容只有两项见 .env.exampleOPENROUTER_API_KEYyour_api_key OPENAI_API_KEYyour_api_keyOPENROUTER_API_KEY必需的运行凭据。模型推理调用经 OpenRouter 网关转发model_service.py中通过os.getenv(OPENROUTER_API_KEY)读取后传给 LiteLLMOPENAI_API_KEY评测阶段必需。Opik 的 G-Eval 默认以 OpenAI GPT-4o 作为打分模型app.py 中评测结果区标题即注明 generated with GPT-4o using Opik。3. 配置 OpikREADME 要求在项目根目录查找.opik.config文件并填入你的 Opik 凭据。该文件为 ini 格式虽然当前目录未附带该文件但同仓库的minimaxm2-vs-sonnet4-5-vs-kimik2-vs-gemini3等评测项目带有可直接参考的 .opik.config 样例其结构为[opik] url_override https://www.comet.com/opik/api/ workspace project_name 你的 Opik 项目名 api_key 你的 Opik API Key其中url_override指向 Opik 托管版Comet的 API 端点api_key从 Comet Opik 控制台获取。若使用自托管 Opik则将url_override改为自建服务地址。正确配置后每次评测结果与 LLM 调用轨迹会自动上报到对应project_name下的 Opik 项目供后续在 Web 控制台审计。4. 启动应用streamlit run app.py启动后浏览器默认打开http://localhost:8501。5. 运行自检脚本可选项目附带 test_system.py可对模型服务与评测系统做冒烟测试uv run python test_system.py需要说明的是从当前仓库源码看该测试脚本第 6 行导入的validate_model_name、get_model_mapping并未出现在 model_service.py 中该文件当前仅提供get_model_response_async、get_parallel_responses、get_all_model_names三个函数直接运行可能触发导入错误说明测试脚本可能滞后于模块演进。可将其视为评测系统预期数据结构的参考其中对返回结构detailed_metrics / overall_score / passed的断言test_system.py与评测函数实际输出完全吻合。支持的模型与双模型并行调用机制内置模型注册表模型的可用清单集中定义在 model_service.pyAVAILABLE_MODELS { GPT-oss-20B: openrouter/openai/gpt-oss-20b, Qwen3-Thinking: openrouter/qwen/qwen3-235b-a22b-thinking-2507, GPT-oss-120B: openrouter/openai/gpt-oss-120b, }UI 显示名OpenRouter 模型标识说明GPT-oss-20Bopenrouter/openai/gpt-oss-20bOpenAI 开源推理模型 20BQwen3-Thinkingopenrouter/qwen/qwen3-235b-a22b-thinking-2507Qwen3 235B-A22B Thinking 版GPT-oss-120Bopenrouter/openai/gpt-oss-120bOpenAI 开源推理模型 120B目录名gpt-oss-vs-qwen3点明的正是项目最常见的用法——在 GPT-oss 与 Qwen3-Thinking 之间做同题对比。得益于注册表 下拉框设计任何两个已注册模型都可自由组合。单模型调用显式索取思考过程get_model_response_async 是底层调用函数其关键实现response await acompletion( modelmodel_path, messagesmessages, api_keyos.getenv(OPENROUTER_API_KEY), max_tokens2000, reasoning{effort: high}, ) ... if hasattr(message, reasoning_content) and message.reasoning_content: reasoning message.reasoning_content elif hasattr(message, reasoning) and message.reasoning: reasoning message.reasoning三个值得注意的细节reasoning{effort: high}显式要求模型启用高强度的推理模式以便拿到更完整的思考轨迹max_tokens2000限制单次输出规模兼顾推理深度与响应时长reasoning 内容兼容两种字段优先读取message.reasoning_contentOpenAI 系否则回退到message.reasoning从而兼容不同模型在 OpenRouter 网关上的返回格式差异。函数最终返回{content: 最终答案, reasoning: 思考过程}结构。错误处理也做了分类API Key 缺失时提示检查OPENROUTER_API_KEY配额不足时提示稍后重试model_service.py。双模型并行真正的同时作答get_parallel_responses 对同一 prompt 发起两次相互独立的调用并原样返回两个协程async def get_parallel_responses(prompt, model1, model2): response1 get_model_response_async(prompt, model1) response2 get_model_response_async(prompt, model2) return response1, response2在 UI 层app.py通过asyncio.gather将两个协程并发执行确保两个模型同时开工保证对比在相同的负载与时间条件下进行final_response1, final_response2 await asyncio.gather( process_response1(model1_container), process_response2(model2_container), )使用流程一次完整的对比评测选择模型页面主体提供两个下拉框Select First Model/Select Second Model候选来自get_all_model_names()。切换模型会清空上一轮的响应与评测结果app.py避免新旧数据混淆提出问题在底部What reasoning question would you like to ask?聊天输入框输入推理题即可触发双模型并跑并排查看结果回答区域被等分为两栏st.columns(2)每栏按模型分别渲染。若返回了 thinking 内容会先展示一个默认折叠的Thinking process展开区可见的reasoning其下再用粗体标注Final Answer后展示最终答案——这让你能同时对比两个模型的解题思路与最终结论可选填写参考答案左侧边栏的Reference Answer (Optional)文本域高 200px可填入期望的标准答案用于给评测提供对照基准触发评测侧边栏点击Evaluate Reasoning Responses按钮。需先确认两个模型均已生成响应否则会提示 Please generate responses from both models firstapp.py评测期间显示 spinner完成后提示Evaluation complete!查看对比结果页面下方输出分组柱状图与两份逐指标明细表见下节。评测指标体系四维 G-Eval 评分指标定义评测层由 code_evaluation_opik.py 实现入口函数为evaluate_reasoning(generated_response, reference_answerNone)。它用 Opik 的 G-Eval 构建了四个相互独立的打分维度指标考察内容Logical Reasoning逻辑推理逻辑步骤与结论的一致性和有效性是否识别出逻辑谬误或自相矛盾结论是否由前提有效推出整体推理结构与流畅度Factual Accuracy事实准确性事实性陈述的正确性是否含误导或错误信息主张是否有据可依、论证充分引用信息来源的可靠性Coherence连贯性回答的组织结构与编排观点与概念间的衔接是否清晰行文清晰度与可读性是否遵循逻辑顺序Depth of Analysis分析深度分析的深度与充分度是否体现批判性思维与洞见是否在恰当之处兼顾多视角是否超越表面观察0–10 分制与通过阈值每个指标满分 10 分分档解释如下分数段通用解读0–2存在重大问题逻辑谬误、事实错误、结构混乱、分析肤浅3–5具备基本能力但存在显著缺口6–8表现良好仅有少量瑕疵9–10表现优异满足全部准则综合得分overall score取四个指标的算术平均值通过阈值passed为 7.0 分即 70%。该口径同时被三处代码锁定评测函数内的passed: overall_score 7.0code_evaluation_opik.py、README 的评分说明以及 UI 中以/ 7.0 (70% threshold)形式展现。Rubric 如何在 G-Eval 中生效每个 G-Eval 指标都由task_introduction裁判角色设定evaluation_criteria分步评估与打分规则name组成。以逻辑推理为例code_evaluation_opik.pylogical_reasoning_metric GEval( task_introduction( You are an expert judge evaluating the logical reasoning quality of a response. The response to evaluate is under ACTUAL_RESPONSE. Assess the logical consistency, validity of arguments, and reasoning flow. Use the following rubric to assign scores: ), evaluation_criteria( EVALUATION STEPS:\n 1. Check for logical consistency throughout the response.\n 2. Identify any logical fallacies or contradictions.\n 3. Evaluate the validity of conclusions drawn from premises.\n 4. Assess the overall reasoning structure and flow.\n\n SCORING RUBRIC:\n Score 0-2: Response contains major logical fallacies or contradictions\n Score 3-5: Response has basic logical structure but with some flaws\n Score 6-8: Response demonstrates sound logical reasoning with minor gaps\n Score 9-10: Response shows exceptional logical consistency and validity\n\n Return only a score between 0 and 10, and a concise reason that references the rubric. ), nameLogical Reasoning, )注意 prompt 中Return only a score between 0 and 10的约束它让打分 LLM 输出带原因的整数/数值分随后代码统一做一次尺度换算——Opik 内部对GEval(...).score()返回的value归一化到 0–1因此实现中把四个result.value各自乘以 10 还原为 0–10 分code_evaluation_opik.py再取平均得到overall_score。评测输入的上下文组装评测对象不是裸文本而是把被测回答与可选的参考答案包进带标记的上下文字符串让裁判 LLM 一目了然code_evaluation_opik.pycontext fACTUAL_RESPONSE:\n\n{generated_response}\n if reference_answer: context f\nEXPECTED_RESPONSE:\n\n{reference_answer}\n当reference_answer存在时四个指标提示词中都会追加一句 The expected response is under EXPECTED_RESPONSE for comparison.把有参考答案的对照评测与无参考答案的纯质量评测区分开。另外code_evaluation_opik.py 保留了evaluate_code作为兼容旧调用的包装函数说明该评测层脱胎于代码生成评测场景后泛化为通用推理评测。评测结果的呈现与解读评测完成后UI 会先对返回结构做严格校验validate_evaluation_result检查detailed_metrics是否齐备四个指标及各自score见 app.py再渲染两类可视化分组柱状图基于 Plotly Express 生成横轴为 Logical Reasoning、Factual Accuracy、Coherence、Depth of Analysis 及 Overall Score 五项纵轴为分数两个模型以不同颜色并列深色主题下的青色与粉色便于一眼看出谁在哪一维度占优app.py逐模型明细表每个模型各输出一张Metric / Score / Reasoning三列的数据表前三行显示四维分数末行以 Final weighted average 汇总综合得分。其中Reasoning 列是裁判 LLM 给出的文字理由它引用了 rubric 的具体分档——这是把打多少分落到为什么这样打分的关键证据也是复盘模型短板最有价值的信息app.py。所有评测调用与轨迹都会同步上报至 Opik 平台可回到 Web 控制台按project_name查看历史评测、追踪每次打分调用的输入输出形成本地看结论、云端做追溯的完整闭环。关键设计经验小结复盘该项目以下设计点最值得在同类评测系统中复用思考过程与最终答案分离展示推理模型的价值一半在可解释的思考链上。将reasoning_content折叠展示、content直出既保留完整信息又不抢占版面并发对称对比asyncio.gather保证两模型在同一时间窗内作答配合统一prompt、统一max_tokens、统一reasoning effort是公平对比的底线评分口径统一G-Eval 底层 0–1 与业务层 0–10 的换算、四维平均与 7.0 阈值的一致性被写入评测函数、README 与 UI 三处避免口径漂移评测可追溯G-Eval 每个分数都附带 rubric 引用的 reason配合 Opik 上报让自动打分不再是黑盒数字UI 状态即评测状态机切换模型即清空旧结果、未生成回答不允许评测、结果结构先校验再渲染——这些守卫逻辑app.py 会话状态相关实现保证了交互流不会进入无效状态。以此四维 G-Eval 框架为基底你可以仅替换AVAILABLE_MODELS注册表与打分 rubric便可将同一套流水线迁移到代码生成、文本摘要、数学解题等其他推理评测任务中。若希望进一步深入可直接查阅该目录下的 app.py、code_evaluation_opik.py 与 model_service.py 三份核心源码理解每一层的完整实现细节。【免费下载链接】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),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价