特斯拉自动驾驶一面

1. 自我介绍

自我介绍不要按履历流水账去讲，直接围绕岗位匹配展开。比较稳的方式是先一句话说明自己主要做 RAG、Agent、AI 应用后端和推理服务，再挑两段最能打的经历展开：一段讲检索增强、知识入库、召回排序、长上下文记忆和评测闭环；另一段讲系统工程，比如高并发服务、索引构建、异步任务编排、可观测性和线上稳定性。最后补一句最近做得最深的方向，比如多路召回融合、长任务记忆回溯、RAG 事实性评估或者工具调用治理，把后面的追问引到自己准备过的区域。

2 RAG 摄入数据时，文档预处理最值得讲的几个难点是什么

难点通常不是“把文本读出来”，而是结构恢复和知识标准化。像 PDF、扫描件、网页、表格、工单、FAQ、代码文档这些来源结构完全不同，如果只是粗暴抽纯文本，后面切块和引用就已经被污染了。真正要做的是标题层级恢复、表格单元格展开、页码与段落锚点保留、正文/脚注分离、术语标准化、重复段去重、版本号与生效时间抽取。很多线上 bad case 看起来像生成幻觉，根因其实在摄入阶段就把证据打散了。

3. chunking 该怎么做，为什么“固定长度切块”在很多业务里会很差

固定长度切块简单，但会破坏语义边界，也会把一个完整知识单元硬拆成几段，导致检索召回时上下文不完整。更稳的做法通常是“结构优先 + 长度兜底”，先按标题、段落、表格、代码块、问答对这些天然边界切，再对过长块做二次切分，并保留父块、子块、章节路径、页码、实体标签等元信息。这样做的目的是让 chunk 既能被召回，又保持尽可能完整的语义闭包。

def split_chunks(paragraphs, max_len=400, overlap=80):
    chunks = []
    cur = []
    cur_len = 0
    for p in paragraphs:
        if cur_len + len(p) <= max_len:
            cur.append(p)
            cur_len += len(p)
        else:
            text = "\n".join(cur)
            chunks.append(text)
            tail = text[-overlap:] if overlap < len(text) else text
            cur = [tail, p] if tail else [p]
            cur_len = sum(len(x) for x in cur)
    if cur:
        chunks.append("\n".join(cur))
    return chunks

4. chunk 入库前除了切分，还应该做哪些预处理，不然后面很容易出脏召回

入库前至少要做去重、清洗异常符号、统一编码、术语归一、标题继承、时间版本打标、实体抽取、敏感信息过滤和质量打分。很多系统只做 embedding，然后把所有块直接塞进库，最后检索阶段就会被模板页、版权页、目录页、重复公告、空表格和 OCR 噪声占满。更成熟的做法是给每个 chunk 增加质量标签和来源可信度，用于后续召回过滤和排序特征。

5. RRF 的公式是什么，为什么它适合多路召回融合

RRF 的核心思想是不用关心不同召回器的原始分数分布，只使用它们各自排名位置做融合。常见形式是[RRF(d)=\sum_i \frac{1}{k + rank_i(d)}]其中 k 是平滑常数，rank_i(d) 是文档在第 i 个召回器中的名次。它之所以好用，是因为 BM25、向量召回、规则召回、知识图谱召回这些分数空间通常不可直接比较，硬归一化容易失真，而 RRF 只看相对名次，鲁棒性更好。

def rrf_fuse(rankings, k=60):
    score = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking, start=1):
            score[doc_id] = score.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(score.items(), key=lambda x: x[1], reverse=True)

bm25 = ["d1", "d2", "d3", "d5"]
dense = ["d3", "d2", "d4", "d1"]
print(rrf_fuse([bm25, dense]))

6. 多路召回里，BM25 和向量召回为什么谁都替代不了谁

BM25 擅长处理精确词、缩写、型号、告警码、版本号这类词法强约束场景，尤其适合错误码、配置项、类名、接口名这类关键字检索。向量召回则擅长语义近邻、同义改写、口语化提问和表达不一致的情况。真实业务里用户问题往往既有词法精确约束，又有语义模糊描述，所以单一路召回一定会漏。多路召回的价值不是“多一层保险”，而是覆盖不同失效模式。

7. reranker 真正解决的是什么问题，为什么召回够准了还不够

召回阶段目标是高覆盖，宁可多拿一些候选，也不追求排序绝对精细。reranker 解决的是“从这堆候选里把真正对当前 query 最有帮助的证据排到前面”。尤其在多路召回后，候选集里会混入大量“相关但不是最相关”的块，如果不做精排，模型看到的上下文很可能被噪声占满。reranker 其实在做 query-doc 的细粒度匹配，它决定生成阶段喂进去的是证据还是干扰项。

8. chunking 的 bad case 一般长什么样，怎么系统化修

最常见的 bad case 有几类：一个事实被切成两半导致检索只命中前半段；标题和正文分离导致语义悬空；表格跨页导致行列错位；同一文档不同版本混在一起导致时间冲突；目录页和正文一起入库造成伪高频召回；代码块和自然语言混切导致 embedding 失真。修法不能靠单点 patch，通常要回到切块策略、结构恢复、元数据过滤和评测集构建一起改。真正成熟的系统会维护 chunk 级 bad case 集合，而不是只看最终答案错没错。

9. harness 在 RAG 或 Agent 场景里该怎么理解

harness 可以理解为一套可重复、可批量、可对比的实验与评测框架。它不是简单脚本，而是把数据集、配置、链路版本、提示词、召回器、重排器、模型参数、日志和指标统一托管起来，使每次实验可回放、可复现、可归因。没有 harness，大家就会停留在“我感觉这版好像更好”，一旦线上坏了也不知道是切块变了、召回变了还是 prompt 变了。

10. RAG 项目落地时，数据量级和真实挑战一般在哪些地方暴露

数据量级一上来，最先暴露的不是“模型不够大”，而是索引构建周期、增量更新、版本切换、一致性和成本。比如文档几十万份、chunk 上千万时，重建索引时间、向量写入吞吐、元数据过滤性能、冷热分层和在线查询延迟都会变成真问题。再往真实业务走，还会遇到文档版本冲突、跨租户隔离、长尾问法、用户拼写错误、证据冲突和答案责任归属问题。RAG 上线后最难的是持续维护，而不是第一次搭出来。

11. 最新 Agent 架构如果不谈概念图，真正该怎么讲

更值得讲的是执行闭环：任务解析、计划生成、工具选择、参数填充、执行观察、状态更新、错误恢复和最终总结。现在成熟的 Agent 架构越来越像一个具备控制面的运行时，而不只是一个带工具调用的聊天机器人。重点不在“能不能调工具”，而在是否有显式状态、是否能回滚、是否支持中断恢复、是否能对长任务做阶段性压缩和记忆写入。