真实面经题目 · 原创解析
用 Prompt Engineering 构造评测或训练数据效果不理想时,如何迭代任务定义、样本分布和质检标准?
这题考 Prompt Engineering 构造数据的迭代能力:先判断数据用途,再从任务定义、prompt 模板、样本分布、人工质检、失败切片和真实数据混合上优化。
真实面经题目 · 原创解析
这题考 Prompt Engineering 构造数据的迭代能力:先判断数据用途,再从任务定义、prompt 模板、样本分布、人工质检、失败切片和真实数据混合上优化。
我会先确认 PE 这里指 Prompt Engineering,并把“构造的数据效果不理想”拆成评测数据和训练数据两种情况。如果是评测数据不理想,重点看它是否能稳定区分模型好坏;如果是训练数据不理想,重点看它是否让模型学到正确行为而不是学到模板痕迹。排查顺序上,第一步回到任务定义:输入、输出、约束、正负例、边界场景和不可接受答案是否写清楚。第二步检查生成 prompt,是否过度单一、暗示答案、缺少难例、多样性不足,或者生成样本与真实用户语言不一致。第三步看样本分布,按意图、难度、长度、领域、语言、风险等级和长尾场景切片,判断是不是只覆盖了简单样本。第四步做质检和标注标准,建立人工抽检、规则校验、去重、冲突样本仲裁和 golden set,而不是让模型生成后直接入库。第五步基于 badcase 迭代:哪些样本导致模型误学,哪些样本无法区分模型,哪些样本与线上不匹配。最后要把合成数据和真实数据混合使用,并设置版本化评估,看新数据是否提升目标切片,同时不伤害原有能力。成熟回答不是“换 prompt 再生成一批”,而是把数据生产当成可度量、可审计、可回滚的产品流程。
同样是 Prompt Engineering 构造数据,用途不同,优化目标不同。评测数据要求覆盖真实任务、难度分层、标准稳定、能区分模型;训练数据要求示范正确行为、减少噪声、避免模板化和标签泄漏。如果不先区分用途,就会把“分数不好看”和“模型学不好”混成一个问题。
构造数据前要明确输入形式、输出格式、用户意图、限制条件、正例标准、反例标准和边界场景。很多 PE 数据效果差,是因为 prompt 只说“生成一些样本”,没有说明用户真实表达、答案质量标准、不可接受内容和难例类型,导致数据看起来丰富但不可用。
如果生成 prompt 过于固定,数据会出现模板痕迹,模型可能学到句式而不是能力。应通过场景变量、角色变量、难度变量、语言风格、输入长度、噪声表达和反例约束来增加多样性;同时避免在 prompt 中暗示标签或答案,防止评测数据泄漏。
数据效果不理想时,要统计分布而不是凭感觉改 prompt。可以按意图类别、领域、难度、长短文本、用户表达方式、风险等级、是否需要知识库、是否多轮上下文等维度切片。若某些高价值或高风险切片缺失,即使总样本量大,也无法支撑可靠评测或训练。
PE 生成的数据必须经过质检。常见动作包括去重、格式校验、敏感内容过滤、人工抽检、golden set 对齐、标注一致性检查、争议样本仲裁和错误样本回收。质检标准要版本化,否则后续无法解释数据效果变化来自 prompt、标注还是模型本身。
调整不是简单重写 prompt,而是看 badcase 属于任务定义错、分布缺口、标注错、生成样本不真实还是模型能力不足。修正后要用保留集、真实线上样本和人工复核验证;训练数据还要看是否引入能力退化,评测数据还要看是否仍能区分不同模型版本。
看语言风格、输入长度、错别字、上下文缺失、模糊表达、领域词和意图分布是否接近真实日志。也可以让人工标注员或业务专家盲评,比较合成样本和真实样本的可区分度。
通常不应完全替代。合成数据适合补长尾、构造边界、扩充冷启动场景,但真实数据能反映用户表达和线上分布。更稳的是混合使用,并用真实保留集验证收益。
如果难例比例远高于真实场景,总分会低估线上体验,也可能让团队只优化极端问题。难例应该单独成集或分层计分,不要掩盖主流场景表现。
不应该先加量。要先看标签是否正确、任务是否清楚、分布是否合理、样本是否重复和模型错在哪个切片。低质量数据加量通常会放大错误。
生成 prompt 不要直接暴露目标标签或标准答案模式;评测题和答案应分离质检;训练集、开发集和测试集要去重;对相似样本做 embedding 或规则查重,降低模板泄漏。