搜索中文正文和常见中英文技术词,按教程、项目、面试题筛选。
「RAG 排错」找到 11 条内容
按专题浏览 →匹配正文:RAG 回答错了,最常见的第一反应是什么? 改 Prompt,换大模型,或者把 Top-K 调大。 这三个动作都可能有用,但它们不应该成为排查起点。 因为最终答案只是链路最后一层。错误可能早在文档解析时就发生,也可能是 Query 被改写带偏、过滤条件挡掉了正确文档、向量召回没找到、融合时被压下去,或者 Rerank 把正确证据排到了后面。 如果连正确证据在哪一层消失都不知道,改参数更像碰运气。 排查前,为什么先要有“正确证据”? 如果只知道“答案错了”,排查没有参照物。 系…
匹配正文:…需要复核。后面发现漏字时,团队才能知道是 OCR 本身失败,还是页面一开始就被分到了错误路线。 OCR 之后,还有哪几步才能进入 RAG? 一条完整的 PDF 解析流程,会包含图像、文字识别、版面、表格和文本合并等环节。放到扫描件上,可以按下面的顺序理解。 第一步,渲染和预处理页面。 系统把目标页转成适合识别的图像,并检查方向、倾斜、清晰度、对比度和噪声。旋转页如果方向不对,后面的文字识别很可能整页失败。低清页面可以受控提高渲染质量,但不能无限放大,因为处理时间和资源占用也会…
匹配正文:…。 第一套仍然区分章节标题、列表前导句和正文,第二套却把它们全部压成同一级文本。若只按字符是否出现计算,两套结果可能很接近;进入 RAG 后,第二套的片段却不知道自己属于哪个章节,例外条件也可能离开它约束的正文。 再看重复问题。同一段内容被解析器输出两次,字符覆盖甚至会显得更高,但检索前几条可能被近重复 Chunk 占满。只统计“提取了多少字”,既看不出层级丢失,也会把重复内容误当成完成度提升。 所以解析质量至少要拆成四层。 第一层,文字覆盖 检查应该出现的正文有没有被提取,…
学习内容与项目面试,在同一条路上。