AI数据工程师面试题库（核心题库必背）

AI数据工程师面试题库第1页共1页AI数据工程师面试题库解决「面AI数据工程师问不出真本事、评分全靠感觉」：45题覆盖基础认知·实操应用·项目追问·风险避坑·开放思辨，每题附参考答案与追问链，含评分表与红旗信号使用说明一、题库定位本题库面向AI数据工程师岗位（数据管道、清洗治理、文档解析、向量检索、数据资产化）的面试评估，共45题。题目的设计前提是：这个岗位的候选人极易"看起来都会"。原因是开源框架把链路封装得太好，任何人跟着教程都能在半天内搭出一个能跑的知识库。所以本题库的区分点不在"知不知道"，而在遇到真实脏数据时的判断力——解析错行时先怀疑哪一层、增量漏数时从哪个字段查起、召回率上不去时改召回还是改排序。题库不适用于：数据集构建师（考察规格设计）、算法工程师（考察训练）、平台运维（考察集群）。这三类岗位的评估重点不同，混用会失真。二、题目结构与建议用时部分题量建议用时考察目的适用轮次一、基础认知题1220分钟（抽6～8题）基本功是否扎实，是否只会调包一面二、实操应用题1030分钟（抽4～5题）能否给出可执行步骤，而非概念一面/二面三、项目经验题735分钟（深挖2题）真实经历与个人贡献边界二面四、风险与避坑题920分钟（抽4题）是否踩过坑、是否有防错意识二面五、开放思辨题715分钟（抽2题）权衡能力与工程判断三面合计45120分钟（两轮）——抽题原则：一面重基础与实操（比例6:4），二面重项目与避坑（比例5:5），三面只出开放思辨题并追问到底。同一候选人不要重复考察同一能力点超过两次。三、评分锚点（1～5分）分数表现特征判定5有具体数字与失败经验，能说清取舍理由，能指出自己方案的局限明显高于岗位要求4步骤完整可执行，指标有实测数据，边界情况有考虑符合要求3大方向正确，细节含糊，需追问才能补全基本符合，需带2只有概念与工具名，说不出参数与验证方法不符合1答非所问，或明显是背诵教程话术不符合，且学习能力存疑评分纪律：只记录候选人说出的内容，不替候选人补全。面试官心里"他应该知道"的部分不计分。四、面试官注意事项●必须带真实材料。二面准备一份有跨页表格的PDF、一段含重复的工单文本，让候选人现场说怎么处理，比问十道概念题有效。●追问要追到数字。"大概多少份""差不多95%"这类回答必须追问精确值与测算方法，这是本岗最重要的素质。●不要考工具版本号。问"Milvus2.3的某个参数默认值"没有意义，问"索引参数调大调小各自影响什么"才有意义。●允许说"我没做过"。候选人承认没做过某类版式，但能说出会怎么试，比硬编一个经历可信得多。●警惕过度流畅。本岗的回答通常带犹豫与条件限定（"要看文档类型""要看源系统有没有updated_at"），全程无停顿、无条件的回答往往来自背诵。●控制单题时长。基础题超过4分钟未触及要点即转下一题，避免时间被一道题吃掉。一、基础认知题（12题）Q1.你怎么理解AI数据工程师和数据集构建师的区别？参考答案要点：1.构建师交付"规格"：样本schema、标注规范、验收口径、多少条够用，本质是定义标准。2.本岗交付"产能"：把数据从源系统稳定、可重复、可追溯地送到训练与检索环节，本质是建生产线。3.判断标准：出问题时，改的是"标准"还是"链路"。改标准归构建师，改链路归本岗。4.协作关系：构建师定规则，本岗保证规则在十万份文档上执行结果一致。追问：如果构建师给的规格在真实数据上跑不通（例如要求"每条样本必须有明确出处"，但30%的老文档没有页码），你怎么办？Q2.为什么说企业里80%的时间花在"拿到干净数据"上？参考答案要点：1.源系统本身不干净：字段缺失、枚举不统一、软删除标记混乱、历史数据无主键。2.非结构化数据占比高：PDF、扫描件、Word混排，解析本身就要反复调。3.权限与合规成本：申请账号、脱敏、跨部门协调，往往比写代码耗时更长。4.这句话的工程含义是：管道设计要把"清洗"当成一等公民，而不是上线前临时补的脚本。追问：如果老板要求"两周上线知识库"，你会砍掉哪部分工作、保留哪部分？砍掉的风险怎么兜？Q3.增量同步有哪几种实现方式，各自的前提条件是什么？参考答案要点：1.CDC（读binlog/redo）：前提是数据库开启日志且有权限，能捕获insert/update/delete，延迟低。2.时间戳轮询：前提是有可靠且被业务代码正确维护的updated_at，无法捕获物理删除。3.全量比对：前两者都不具备时使用，按主键做差集，成本高、窗口长。4.选择顺序：CDC优先，其次时间戳，最后全量；无论哪种都必须有幂等写入。追问：源系统有updated_at，但业务代码在"状态变更"时忘了更新这个字段，你怎么发现、怎么补救？Q4.文档解析时，你怎么判断一份PDF该走哪条路径？参考答案要点：1.先抽取前两页文本，看字符数与是否乱码，判断有无文本层。2.检查页面是否只有一张大图，判断是否扫描件。3.看版面：单栏还是多栏、有无跨页表、有无页眉页脚、有无印章手写。4.按判断结果路由：文本层走版面分析，扫描件走OCR，复杂版式需栏检测与表格检测。5.判断错误的代价很大，60%的解析失败源于路径选错而非工具不好。追问：一份PDF前10页有文本层，后50页是扫描件，你的流水线怎么处理？Q5.分块为什么不能用一个固定大小打天下？参考答案要点：1.块是检索的最小单位，块的设计要匹配"用户会怎么问"。2.块太大：多个主题混在一起，向量被平均，检索不准，且浪费上下文token。3.块太小：指代丢失（"上述条款"无先行词），模型拿到也答不出。4.应按文档语义边界切：合同按条款、手册按小节、FAQ按问答对、法规按条目。5.通用区间300～800token、重叠10%～15%，但必须按类型改写并用抽检验证。追问：一份合同里有个条款写了1500字，超过你的块上限，你怎么切才不破坏语义？Q6.字面去重和语义去重分别怎么做，阈值怎么定？参考答案要点：1.字面去重：规范化（去空白、统一全半角、去页眉页脚、转小写）后算哈希，哈希相同即重复。2.语义去重：用Embedding算相似度，超过阈值判为重复。3.阈值不能拍脑袋，要用500对标注样本校准，画误删率与残留率曲线取平衡点。4.按文档类型分设：FAQ可低（0.92），合同要高（0.97），一字之差可能改变权责。5.去重只合并内容，来源记录必须保留。追问：语义去重把两份"看起来一样但生效日期不同"的制度合并了，这是错还是对？你怎么在设计上避免？Q7.向量检索和关键词检索各擅长什么？为什么企业场景通常要混用？参考答案要点：1.向量擅长语义相近、换说法；弱于精确编号、型号、人名、条款号。2.关键词（BM25）擅长精确串匹配；换说法就召不回。3.企业知识库里大量问题含编号与专有名词，纯向量在这些问题上召回明显偏低。4.混用方式：两路各取Top50，用RRF或加权融合；RRF不需分数归一化，更稳。5.混合是标配不是加分项，代价是链路复杂与权重需调。追问：融合权重你怎么定？定了之后怎么证明它比纯向量好？Q8.HNSW的M和efConstruction调大调小分别影响什么？参考答案要点：1.M控制每个节点的连边数，调大提升召回与鲁棒性，但内存占用与构建时间上升。2.efConstruction控制构建时的候选队列长度，调大提升图质量与召回，构建更慢。3.efSearch是查询时参数，调大提升召回、增加延迟，可在运行时调整。4.三者都是"召回与成本"的权衡，没有通用最优值，要按数据规模与延迟SLA实测。5.关键认知：索引参数不能弥补分块与Embedding选型的错误。追问：你的Recall@50只有0.82，你会先调efSearch还是先查分块？为什么？Q9.什么是数据血缘？在这个岗位里它能解决什么具体问题？参考答案要点：1.血缘记录数据的上游来源、处理链路、参数版本、生成时间，以及被谁消费。2.能回答三个问题：这条数据从哪来、经过了什么处理、被哪个索引/模型/应用用了。3.具体价值：线上效果下降时，能在小时级定位到"某次解析器升级"而不是"模型不稳定"。4.血缘要能追到原始文件与页码，否则回答无法给出引用。5.血缘与版本是一体两面：没有版本，血缘只能指向"最新"，无法回溯。追问：血缘要记录到什么粒度才算够用？记录太细会不会拖慢管道？Q10.多租户场景下，怎么保证A客户检索不到B客户的文档？参考答案要点：1.隔离层级选择：物理隔离（独立collection/独立库）最安全，成本高；逻辑隔离（tenant字段+强制过滤）成本低但依赖实现正确。2.过滤必须在检索层执行，不能只在应用层做（应用层可被绕过）。3.写入时强制注入tenant_id，且不允许为空；查询时由服务端注入，不接受客户端传参。4.必须有越权测试用例，验证跨租户查询返回0条。5.元数据、缓存、日志同样要隔离，缓存key漏了tenant会导致串数据。追问：如果用逻辑隔离，某次代码改动漏了过滤条件，你怎么在测试阶段发现？Q11.脱敏有哪几种方式？为什么"全部替换成某公司"是错的？参考答案要点：1.方式：替换、掩码、泛化、假名化、删除。2.全部替换成"某公司"会破坏实体对齐：同一实体在不同文档变成同一个模糊词，检索"甲乙公司的合同"永远查不到，也无法做实体聚合。3.正确做法是假名化：用稳定映射把实体映射为ORG_1024，全局一致，既可关联又不泄露。4.脱敏后要验证：实体对齐准确率、检索召回是否下降。5.脱敏在入库前完成，且要留规则表与审计记录。追问：假名化映射表本身就是敏感资产，你怎么保护它？Q12.数据卡（datasheet）你会写哪些内容？为什么"已知缺陷"必须写？参考答案要点：1.来源构成、条数、时间跨度、文档类型与版式分布、块数。2.清洗规则版本、分块策略、去重情况、脱敏方式。3.已知缺陷：哪类文档准确率低、哪年数据缺失、哪类问题覆盖不足。4.禁止用途：不得对外服务、不得跨租户混用等。5.写缺陷的原因：下游据此判断能不能用、用的时候要加什么兜底；只写优点的数据卡等于没有。追问：算法团队拿到你的数据卡后说"这批数据不能用"，你会怎么处理？二、实操应用题（10题）Q13.给一个MySQL表，有自增主键、有updated_at但部分为NULL、有is_deleted软删标记，请设计增量抽取方案。参考答案要点：1.增量条件：`updated_at>上次水位-5分钟`或`updated_atISNULLANDid>上次最大id`，两部分合并。2.水位存储：单独水位表，记录每次成功批次的时间上界与id上界，事务内更新。3.删除处理：抽取时不过滤is_deleted（要同步删除动作），在目标端按标记置为失效并从索引移除。4.幂等写入：以源标识+id+updated_at为唯一键做upsert。5.校验：每日一次行数与状态分布比对；抽样100条逐字段比对。6.分批：按id区间切片，单批≤10万，批间限速。追问：updated_at为NULL的行如果永远不更新，你的方案会不会每次都把它们全扫一遍？Q14.一份50页的扫描版合同，第12至13页是跨页报价表，第二页没有表头，你怎么处理？参考答案要点：1.先OCR，保留每行的坐标与置信度。2.表格检测：有线表用线检测，无线表用列对齐推断。3.跨页判断：比较两页表格的列数与首行列名相似度，列数一致且首行相似则判为同一表。4.合并：把第二页的行追加到第一页表体，表头用第一页的列名补齐。5.单元格：展开合并单元格，把合并值填到每个被合并格。6.验证：合并后行数应等于两页行数之和减表头行；抽3行与原文人工比对。7.若置信度低，标记为待人工确认，不静默输出。追问：如果第13页是横排（表格旋转90度），你的方案要怎么改？Q15.一份双栏排版的ProductManual，解析出来的句子是"左半句+右半句"拼接，你怎么修？参考答案要点：1.定位原因：按页面坐标从上到下全局排序，导致同一水平线的左右栏被连成一句。2.修法：先做栏检测（按文本块x坐标聚类，或用投影法找栏间空白），划分左右栏区域。3.再在每栏内按y坐标排序，栏内成段；最后按"左栏全部→右栏全部"合并。4.验证：抽10页，检查段落是否以完整句结尾，跨栏拼句应为0。5.若文档存在跨栏标题（横跨两栏的标题），需先识别并单独处理，否则会被误分到某一栏。追问：三栏排版、且中间栏有插图，你的栏检测会怎么失效？Q16.一个FAQ文档有800组问答，每组问题100字、答案300字，你怎么切块？参考答案要点：1.不切：一组问答为一个块，问题与答案必须在一起，切开就答不上。2.块结构：问题原文+答案正文+元数据（分类、生效日期、适用产品）。3.若答案超长（>800token），在段落边界切，但每块前缀重复问题原文。4.向量化时对"问题"单独算一个向量做问题-问题匹配，可提升同义问法的召回。5.验证：抽50组，用真实用户问法测试，看是否能召回对应问答对。追问：用户问法和FAQ问题措辞差异很大（"怎么退"vs"退款流程是什么"），你怎么提升召回？Q17.你的知识库上线后发现"含编号的问题"召回很差，怎么排查和改进？参考答案要点：1.先量化：把评测集按"含编号/不含编号"分组，分别算Recall@5，确认差距。2.查分块：编号是否被切断（如"GB/T19001"被切成两行）。3.查解析：编号中的特殊字符是否被清洗规则误删。4.查检索：纯向量对精确串不敏感，加BM25双路召回。5.查分词：编号被分词器拆碎，需加自定义词典或做字符级匹配。6.改进后重跑评测，报告分组指标变化。追问：加了BM25之后，非编号类问题的指标掉了2个点，你怎么调？Q18.一条DAG每天凌晨跑，某天发现下游索引里文档数比昨天少了3000份，你怎么定位？参考答案要点：1.先看DAG运行状态：哪个任务失败、是否被跳过、是否有重试记录。2.看各环节计数：接入数→清洗后数→解析成功数→分块数→入库数，找断崖点。3.常见原因：解析失败率飙升（解析器升级/文件损坏）、去重阈值变化误删、入库批次部分失败但被标记成功。4.查质量闸门：为什么没有阻断？阈值是否设得太松。5.处置：回滚到上一版配置、按日期区间补数、把该异常加入闸门规则。6.复盘：写清"为什么没在当天发现"，补监控。追问：如果每个环节的计数都正常，但索引里就是少了，你会查哪里？Q19.你要为一个3000万份文档的库设计索引，怎么规划？参考答案要点：1.先算规模：3000万文档×平均8块=2.4亿向量；按768维float32约需2.4亿×768×4B≈737GB，加索引开销约1.5倍。2.压缩：考虑float16或PQ量化，可降到1/2至1/4，需实测召回损失。3.分片：按租户或业务线分collection，避免单集合过大；按时间分片便于冷热分离。4.索引类型：HNSW适合高召回低延迟，内存占用高；IVF-PQ省内存但需训练且召回略低。5.增量：新文档走upsert，删除走软删+定期压实（重建或合并段）。6.容量规划：内存需覆盖热数据索引，冷数据可落盘或降精度。追问：预算只够原方案的三分之一内存，你的降级顺序是什么？Q20.检索评测集怎么建？300条够不够？参考答案要点：1.来源：从真实用户问题日志抽样，不能由工程师自编。2.覆盖：按业务场景、文档类型、问题类型（事实型/流程型/对比型/编号型）分层，每层不少于30条。3.标注：由懂业务的人标"正确块ID"，可多个；工程师不参与判定。4.300条是最小可用量，能支撑总体指标；若要分场景看，每场景需≥50条。5.维护：每月补充新出现的问题类型，剔除已下线文档对应的题。6.封闭：评测集不用于调参，调参用开发集。追问：业务方说"你们评测分很高但用户还是不满意"，你怎么查？Q21.一个客户要求"我们的文档不能出内网，也不能用公网Embedding"，你的方案怎么调整？参考答案要点：1.Embedding改为本地部署开源模型，选中文效果好的，先在自建评测集上验证Recall。2.向量库本地部署，注意离线安装与许可证。3.OCR与解析全部本地化，注意模型文件体积与CPU/GPU需求。4.依赖包走内网镜像，禁止运行时联网下载模型。5.若客户无GPU，评估CPU推理的吞吐，可能需要降低批量或改用更小模型。6.交付物要包含离线安装包与升级方案。追问：本地模型比原方案Recall低6个点，你怎么向客户解释并弥补？Q22.你怎么把"文档更新"这件事做成自动的，而不是每次人工重跑？参考答案要点：1.监听源系统变更：CDC事件或文件系统事件通知，落到消息队列。2.变更去重与合并：同一文档短时间多次变更，合并为一次处理（防抖窗口如5分钟）。3.增量处理：只重跑受影响文档的解析、分块、向量化，按文档ID删除旧块再写新块。4.版本管理：文档版本号递增，索引保留最新版，旧版软删。5.失败处理：进死信队列，告警，支持单文档重试。6.验证：改一份文档，10分钟内能在检索中看到新内容、旧内容不再召回。追问：如果一份文档被删除，但它的块已经被别的文档引用（如引用块），你怎么处理？三、项目经验题（7题）Q23.讲一个你从零搭建的数据链路项目，从接入到检索上线。追问链：1.这个项目有多少个源系统、多少份文档、扫描件占比多少？2.解析环节你们试过几种方案？最后为什么选这个？3.分块策略是怎么定的？有没有做过对比实验，指标差多少？4.上线后最严重的一次事故是什么？定位花了多久，靠什么定位的？5.如果重做一次，你会改哪三个决定？评分要点：●能给出文档量、扫描件占比、块数、召回率等具体数字（4分以上必备）。●能说出至少一次失败与修正过程，而非全程顺利。●能明确界定个人贡献（"解析器是我写的，检索调优是同事做的"）。●第5问能说出有洞察的反思（如"不该一开始就上混合检索，应该先跑通纯向量"）。红旗：全程只讲工具名与架构图，无数字；被追问"多少份"时回答"挺多的"；把团队成果全说成个人成果。Q24.讲一次解析质量导致的效果问题。追问链：1.用户反馈的具体现象是什么？2.你是怎么从"回答错"定位到"解析错"的？中间看了哪几个东西？3.受影响的范围有多大？怎么统计出来的？4.修复后怎么验证？重跑了多少文档，花了多久？5.之后你加了什么机制防止同类问题？评分要点：●排查路径清晰：先看检索命中，再看块内容，再看解析结果，逐层收敛。●能量化影响范围（"涉及2022年之前的1.2万份扫描件"）。●有机制性改进（加闸门、加回归集），而不是只修个案。红旗：直接说"重新解析一遍就好了"，说不出定位过程；没有影响范围统计。Q25.讲一次检索指标优化的经历。追问链：1.优化前的Recall@5是多少？评测集多大、怎么建的？2.你先改的是召回层还是排序层？依据是什么？3.混合检索的权重或RRF参数怎么定的？试了几组？4.rerank带来多少提升，延迟增加多少？业务方能接受吗？5.有没有出现过"指标涨了但用户体感没变"？为什么？评分要点：●能分层报指标（Recall@50与Recall@5分开）。●能说清延迟代价与业务SLA的权衡。●第5问能答出"评测集分布与线上不一致"或"长尾问题未被覆盖"，说明有反思。红旗：只有端到端准确率一个数；说不出评测集来源；把rerank当万能药。Q26.讲一次增量同步或数据一致性的事故。追问链：1.事故是怎么被发现的？用户投诉还是监控告警？2.数据错在哪一类：漏数、重复、还是旧值覆盖新值？3.根因是什么？是设计缺陷还是代码bug？4.怎么修的？修完之后怎么补历史数据？5.有没有加防止复发的检查？现在跑多久没再出过？评分要点：●能区分"漏/重/覆盖"三类，说明对边界有真实认知。●有补数方案（按日期区间回补、幂等重跑）。●有防复发机制（水位校验、行数环比闸门）。红旗：说不清是漏还是重；补数据靠"手动导一遍"；没有防复发措施。Q27.讲一次权限或合规相关的落地经验。追问链：1.你们有几级密级？谁定的？2.过滤做在哪一层？应用层还是检索层？3.怎么验证没有越权？有没有测试用例？4.多租户是物理隔离还是逻辑隔离？为什么这么选？5.出过越权事件吗？如果没有，你怎么证明现在不会出？评分要点：●明确"检索层强制过滤"这个关键点。●有可执行的验证方法（越权用例、跨租户查询返回0条）。●第5问能答出"用测试用例覆盖+审计日志抽查"，而不是"我们没出过事"。红旗：权限只在应用层做；说不出密级怎么划分；把"签了保密协议"当成技术措施。Q28.讲一次成本优化的经历。追问链：1.优化前的月成本是多少？构成是什么（存储/计算/调用）？2.你改了什么？全量改增量、还是降精度、还是缓存？3.省了多少钱？有没有带来效果损失？4.怎么证明效果没退化？5.如果预算再砍一半，你下一步砍哪里？评分要点：●能拆成本构成，不是笼统说"省了钱"。●优化有验证（重跑评测集，指标波动在容差内）。●第5问能说出优先级（先砍冷数据存储、再降向量精度、最后才动rerank）。红旗：说不清成本构成；优化后没做效果回归；把"换了更便宜的云"当成本优化能力。Q29.讲一次你和算法团队或应用团队的分歧。追问链：1.分歧的具体内容是什么？2.双方各自的理由是什么？3.最后怎么解决的？谁拍板？4.事后看谁是对的？5.之后你们怎么避免同类分歧？评分要点：●能客观描述对方立场，不把分歧说成"对方不懂"。●解决方式基于数据而非职位（跑一次对比实验）。●有机制性改进（提前约定接口契约、数据卡写清限制）。红旗：把分歧描述成对方无理；解决方式靠"领导压下来"；无反思。四、风险与避坑题（9题）Q30.只做一次性导入、不做增量更新，会出什么问题？参考答案要点：1.新文档永远搜不到，用户逐渐弃用，最后结论是"AI没用"。2.已废止的制度仍被引用，产生合规风险（如按旧版流程办事）。3.数据团队沦为"每次需求都要人工导一遍"的运维，无法规模化。4.修复成本随时间上升：越晚补增量，历史欠账越多。5.正确做法：上线第一天就带增量，哪怕先用最简单的定时轮询。追问：如果源系统根本不支持增量，你的兜底方案是什么？Q31.不做数据质量监控，脏数据会怎么"静默"流入？参考答案要点：1.解析器升级后页眉剔除失效，每块都带页眉，向量被污染，指标缓慢下降无人察觉。2.源系统字段含义变更（如状态码新增枚举），映射表未更新，数据被归到"其他"。3.去重阈值调整后误删增加，知识覆盖悄悄变窄。4."静默"的本质是没有闸门、没有环比、没有告警，问题只能靠用户投诉暴露。5.对策：三道闸门（接入后、解析后、入库前）+环比告警+每日质量日报。追问：闸门阈值怎么定？定太严会天天误报，定太松等于没有。Q32.向量库不设元数据过滤，会导致什么问题？参考答案要点：1.检索串场景：问A产品的参数，召回了B产品的段落，答案看似合理实则错误。2.越权：用户检索到无权限部门的文档。3.时效错误：召回了已废止版本，回答按旧规执行。4.根因是把所有文档塞进一个无差别索引，只靠语义相似度排序。5.对策：元数据必填（产品线、密级、版本、生效日期、部门），检索时前置过滤而非事后剔除。追问：前置过滤会不会降低召回？过滤条件很复杂时性能怎么保证？Q33.忽略权限会导致什么后果？技术上怎么防？参考答案要点：1.后果：越权检索属数据安全事件，可能触发监管通报与合同违约。2.技术上：密级打标、检索层强制过滤、服务端注入用户身份（不接受客户端传）、多租户隔离、审计日志。3.流程上：权限矩阵由业务与合规共同确认，变更走审批。4.验证：越权测试用例纳入回归，每次发版必跑。5.兜底：异常访问量告警（某用户突然检索大量不同部门文档）。追问：如果业务方要求"临时开放全库检索给某项目组"，你怎么处理？Q34.为什么"评测集由工程师自己编"是不可接受的？参考答案要点：1.工程师编的问题会不自觉地贴合自己实现的方案（用文档里的原词提问）。2.真实用户用口语、缩写、错别字、跨主题提问，分布完全不同。3.自编评测集分数虚高，上线后体感落差大，团队会失去对指标的信任。4.正确做法：从真实日志抽样，业务方标注，工程师不参与判定。5.评测集要封闭，不能用于调参，否则等于训练集泄漏。追问：冷启动阶段没有用户日志，怎么办？Q35.分块时把表格按行切散，会有什么后果？参考答案要点：1.检索到的单行数据没有表头，模型不知道每列是什么，容易张冠李戴。2.数值类问题（报价、参数、限额）答错率显著上升，且错误很隐蔽。3.跨行计算类问题（合计、对比）完全无法回答。4.正确做法：整表成块；超长表格按行分组但每组重复表头；表格保留行列坐标。5.验证：构造20个表格类问题专门测试，单列指标。追问：一张表有200行，整表成块超过模型上下文，你怎么办？Q36.解析器升级后整体效果下降，你怎么防？参考答案要点：1.升级前跑解析回归集（覆盖各类版式，≥50份），对比字符准确率与结构正确率。2.灰度：先处理10%文档，观察检索指标与人工抽检。3.双写对比：新旧解析结果并存，抽样比对差异。4.版本绑定：解析器版本写入块的元数据，出问题可定位到版本。5.回滚预案：保留旧版镜像与旧索引快照，30分钟内可回退。追问：回归集里的版式覆盖不全，新版本在没见过的版式上出问题，怎么办？Q37.数据脱敏过度会带来什么反效果？参考答案要点：1.实体对不齐：所有公司名变成"某公司"，无法按实体检索与聚合。2.语义损失：地址全泛化成"某地"，地域类问题无法回答。3.关联断裂：同一人在不同文档中脱敏成不同代号，无法串联。4.正确做法：假名化（稳定映射）+分级脱敏（按用途决定粒度）。5.验证：脱敏后重跑评测集，召回下降应控制在3个点以内。追问：假名化映射表泄露等于没脱敏，你怎么保护它？Q38.管道没有幂等设计，重跑会发生什么？参考答案要点：1.重复写入：同一文档出现多份块，检索结果里同一内容占满Top5。2.计数失真：文档数虚高，质量指标全部失真。3.索引膨胀：存储与内存成本上升，检索变慢。4.补数困难：出问题不敢重跑，只能人工修数据。5.正确做法：幂等键（源标识+文档ID+版本+块序号）+upsert+重跑前按批次删除。追问：如果历史数据已经重复了，你怎么清理而不误删？五、开放思辨题（7题）Q39.业务方要求"知识库要能回答任何问题"，你怎么回应？评分要点：●高分：不直接拒绝，而是把"任何问题"拆成可测的几类（有文档支撑的事实型、需跨文档推理的、文档里根本没有的），分别说明可行性与代价。●高分：主动提出"拒答"设计——检索不到时明确说不知道，而不是让模型编。●高分：给出分期方案（第一期覆盖80%高频问题，第二期扩长尾）。●低分：直接说"做不到"或直接承诺"可以"。●低分：只谈模型能力，不谈数据覆盖度。追问：如果业务方坚持要"什么都能答"，并且这是签约条件，你怎么办？Q40.你会不会用大模型来做数据清洗（如自动抽取字段、自动打标）？边界在哪？评分要点：●高分：明确适用场景（非结构化抽取、分类打标、生成摘要），明确不适用场景（精确数值计算、需要100%一致性的主键生成、合规判定）。●高分：提出"用模型产出候选+规则校验+抽样人工复核"的三层结构，而不是全自动。●高分：能量化成本（每条多少钱、每天多少条）与稳定性（同一输入多次调用结果不一致怎么处理）。●低分：全盘否定或全盘接受。●低分：不考虑一致性与可复现性。追问：模型打标的结果每次略有不同，你怎么保证索引可复现？Q41.数据团队应该"接需求"还是"做产品"？评分要点：●高分：区分两类工作——临时取数接需求，核心链路做产品（有SLA、有监控、有自助能力）。●高分：提出把重复需求产品化（数据目录、自助检索、模板化接入），把人力释放到架构。●高分：承认现实约束（小团队只能先接需求，但要有意识沉淀）。●低分：只谈"服务意识"或只谈"平台化"，不谈取舍。●低分：把"做产品"理解成"做个界面"。追问：你怎么判断一个需求该产品化还是该一次性做掉？Q42.效果不好时，怎么判断是数据问题还是模型问题？评分要点：●高分：给出分层排查法——先看检索是否命中（Recall@50），命中但排序靠后是排序问题，未命中是数据覆盖或分块问题，命中且排第一但答错才是模型问题。●高分：强调用日志与评测集定位，而不是靠讨论。●高分：能说出"多数情况是数据问题"这个经验判断，但要求用证据确认。●低分：直接归因给模型或直接归因给数据。●低分：没有分层方法，只有"再调调看"。追问：如