case
发表于|更新于
|总字数:134|阅读时长:1分钟|浏览量:
通过指定query 为其构造生成选择题的评测集prompt 让他生成对应的选择题选项 并且标注上选项的错误原因以及正确答案
通过prompt将大模型输出的内容再度美化成为json格式
将这个json格式的数据做一定的清晰后进行乱序 提取其中问题选项
与原query结合 构造出一道完整的选择题
调用大模型尝试写这道题 同理流程 得到最终答案
文章作者: Ivorysillegal
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Ivorysillegal's Blog!
相关推荐

2025-05-09
MCP不完全指北
在偶然的学习中接触到了近期炙手可热的MCP 于是在学习之后草率写一点自己的体会 笔者对AI学习了解主要停留在应用方面 这里也主要MCP在这上的作用和修改 When it comes to MCP 的概念,个人认为从AI工具的使用现状、其的作用和能带来的改善作为角度切入会更好理解. 那么 MCP是什么生态协同 AI与MCP(?)从21年的gpt3.5开始 ai技术不断进步 各种各样的效果评测 也能实打实得说明其无论是在计算 编码 搜索等领域上都有了很大的进步 但是相比之下 其本身集成速度(AI+)应用发展的很慢 3.5时代 我们的使用方法停留在文字对话 语句文字补全 仅chat对话和completion两模式 在以CloseAI为主的(那时还是Open的)独角兽厂商的推动下 人们通过他们提供的api 初步实现了多载体上使用api ide上 chrome插件上 在ds-r1横空出世之后 也是在国内掀起了一模一样的热潮 然后为了想让ai更好的完成任务 人们通过prompt 预训练 rag等方法 尝试通过加强某部分知识在ai“心目中的地位” 事实证明也确实起到了很好的效果...
2025-05-07
意图评测方案
本文介绍在实习中接触到的 交通场景下大模型的意图评测 什么是意图本质是讲用户输入的query 在进行规整化 改写等操作之后 高度抽象的 且具有强烈倾向性的问题 换句话来说 就是将用户输入的query改写为大模型更易接受的形式 这一过程需保证不修改用户的问题原意 且改写后询问的效果显著提升(不然改写就没有意义了) 这一效果可以体现在回答的内容倾向性、回答的格式、自然语言的风格等多个方面 那么 意图识别的难点在于? 输入不规范、输入形式多样化:使用自然语言查询,甚至非标准的自然语言。比如上面提到的“附近的特价酒店” 、“上海到扬州高速怎么走”都是自然语言查询的例子,又如 “披星 ( ) 月”、“吾尝终日而思矣, 下面“ 查询词表现出多意图:单个词在不同领域有多个意思 此时意图无法准确识别到用户的需求 eg:mac是指macbook还是mac地址 意图强度:和上一点类似 同义词表现出多个意图 且在此基础上不同用户的需求不一样 此时需要根据上下文和所有搜索数据进行综合判断 存在时效性变化:随时间推移某些词的意图强度存在变化...
2025-05-09
问答评测方案
这里或多或少会涉及到RAG 此处会简单介绍 比较详细相关可见此 背景场景1: 知识库 这里所说的RAG是比较狭义且普遍的用法 将原始文档切片后转换成为向量 存储在数据库中 带着input-query查询的时候 来到同一个向量空间 向量化后计算他们的相似度 然后输入LLM生成etc 场景2:function call 使用一段描述性prompt设定模型的能力、背景、人设相关信息,让大模型可以访问数据源,网络搜索等。获取自己拿不到的数据 评测维度这里参考RAG的相关论文设置评测的一些维度和指标 1、噪声鲁棒性(Noise Robustness)模型能从噪声文档中提取有用信息。噪声文档定义为与问题相关但不包含任何相关信息的文档。在与”谁获得了2022年诺贝尔文学奖”问题相关的噪声文档包括有关2021年诺贝尔文学奖的报道。为此,噪声鲁棒性测试根据所需的噪声比,将外部文档包含一定数量噪声文档的实例包含在内。2、否定拒绝(Negative...

2025-05-28
Go服务分布式链路追踪系统的设计
why 首先 为什么需要有这个链路追踪系统? 首先先从业务的角度来进行思考 某些业务情境下 例如说是消息下发 支付 或者等等 当我们需要在发起执行业务的请求后 需要获取业务的执行情况、执行进度的时候 可以通过这个链路追踪系统中的信息获取 然后也是最主流的使用情景 —— 在运维、开发、测试的时候 假如某个程序报了始料未及的错误 由于是微服务情境下 多台机器的使用会导致很难纠错 而这个分布式链路追踪系统则可以很直观的告诉开发者 是哪里报了错 快速的定位错误 定性错误 这样的轮子现在已经有很多了 这里所体现的是在具体场景下的一些优化 首先就是 在应用体量很大 数据量很多的时候 这时候应该怎么进行处理 这时候会带来很多问题 首先就是数据量大 想要查询日志的话 本身的耗时成本 查询时所带来的CPU成本 假如是业务功能的话 这个查询的频率会更高 所带来的劣势也会更大 还有一个最显而易见的存储成本的问题 不同的云存储成本 如何优化呢? 首先一种方式就是 流处理 + 批处理 利用Spark或者是Flink等组件 还有一种思路 也就是这里所主要进行的优化是 摒弃完全的中心化存储...