阿里国际 AI 应用研发 一面(暑期)

小伙伴投稿一面在5.10 二面在5.15 HR面在5.17, 211本+韩硕

1. 自我介绍

答案：我主要做大模型应用、RAG、Agent 编排、向量检索、Prompt 工程、模型微调和后端工程化相关方向。之前做过一个 跨境商家合规审核与风险问答平台，面向国际电商平台里的商品合规、商家风控、客服质检和运营审核场景。

这个系统接入了商品标题、商品详情、平台规则、违规案例、审核工单、商家申诉记录和多语言政策文档。用户可以问“这个商品为什么被判定为高风险”“某类商品在欧盟站点能不能上架”“这条申诉该怎么回复”，系统会先做 query 重写和意图识别，再通过混合检索召回规则和案例，最后由大模型生成带引用的审核解释。我的主要工作包括 RAG 核心链路、向量库索引、Query Rewrite、Prompt 模板、Agent 工具调用、模型评测和线上延迟优化。

2. HTTP 与 HTTPS 的核心差异是什么？

答案：HTTP 是明文传输协议，数据在传输过程中可能被窃听、篡改或伪造。HTTPS 是在 HTTP 和 TCP 之间加入 TLS/SSL，通过证书校验、密钥协商、对称加密、完整性校验来保证通信安全。

HTTPS 的核心不是“换了一个端口”，而是多了身份认证和加密传输。客户端会验证服务端证书是否合法，然后通过非对称加密或 ECDHE 协商出会话密钥，后续用对称加密传输数据。这样既保证安全性，也兼顾性能。

HTTP  默认端口 80   明文传输
HTTPS 默认端口 443  TLS 加密传输

HTTPS 解决：
1. 窃听：内容被加密
2. 篡改：有完整性校验
3. 伪造：证书验证服务端身份

3. 大文件、小内存场景下，排序方案怎么设计？

答案：小内存无法一次性把大文件全部加载进内存，通常使用外部排序。核心思路是先分块读取文件，每次只读取内存能承受的一部分，块内排序后写成临时有序文件，再用多路归并把这些有序文件合并成最终有序结果。

如果数据量极大，还需要考虑磁盘 IO、临时文件数量、归并路数、压缩格式和并行化。比如 100GB 文件、内存只有 1GB，可以每次读取 512MB 排序，生成多个 sorted chunk，再用小根堆做 k 路归并。

import heapq

def merge_sorted_files(files, output_path):
    fps = [open(f, "r") for f in files]
    heap = []

    for i, fp in enumerate(fps):
        line = fp.readline()
        if line:
            heapq.heappush(heap, (int(line.strip()), i))

    with open(output_path, "w") as out:
        while heap:
            value, idx = heapq.heappop(heap)
            out.write(str(value) + "\n")

            nxt = fps[idx].readline()
            if nxt:
                heapq.heappush(heap, (int(nxt.strip()), idx))

    for fp in fps:
        fp.close()

4. 数据库索引的作用和实现原理是什么？

答案：索引的作用是减少数据库扫描的数据量，提高查询速度。没有索引时，数据库可能需要全表扫描；有合适索引时，可以通过索引快速定位到目标数据或目标范围。

InnoDB 常用 B+ 树索引。B+ 树非叶子节点只存 key 和指针，叶子节点存完整索引项，并且叶子节点之间通过链表连接，所以既适合等值查询，也适合范围查询和排序。相比 Hash 索引，B+ 树更适合数据库里的范围条件、前缀匹配和 order by。

CREATE INDEX idx_user_time
ON order_record(user_id, created_at);

EXPLAIN
SELECT *
FROM order_record
WHERE user_id = 1001
  AND created_at >= '2026-01-01'
ORDER BY created_at DESC
LIMIT 20;

5. 事务的 ACID 特性与隔离级别有哪些？

答案：事务 ACID 分别是原子性、一致性、隔离性和持久性。原子性表示事务里的操作要么全部成功，要么全部失败；一致性表示事务前后数据满足约束；隔离性表示并发事务之间互不干扰；持久性表示事务提交后数据不会因为宕机丢失。

隔离级别包括读未提交、读已提交、可重复读、串行化。隔离级别越高，并发异常越少，但性能成本越高。MySQL InnoDB 默认是可重复读，通过 MVCC 和 Next-Key Lock 解决很多并发问题。

读未提交：可能脏读
读已提交：避免脏读，但可能不可重复读
可重复读：避免不可重复读，但仍需关注幻读
串行化：最强隔离，并发性能最低

6. 跨平台转账程序设计的核心逻辑是什么？

答案：跨平台转账最核心的是一致性、幂等性、可追踪和异常补偿。一次转账通常不是简单扣 A 加 B，而是包含下单、冻结资金、风控校验、渠道扣款、入账、状态回调、对账和补偿。

如果涉及外部支付渠道，不能依赖本地事务一次性完成。常见设计是使用状态机和最终一致性。每个阶段都有明确状态，所有请求都带幂等号，失败后可以重试，对账任务负责发现中间态异常并补偿。

transfer_state = {
    "INIT": ["FROZEN", "FAILED"],
    "FROZEN": ["DEBIT_SUCCESS", "REFUNDING"],
    "DEBIT_SUCCESS": ["CREDIT_SUCCESS", "COMPENSATING"],
    "CREDIT_SUCCESS": ["FINISHED"],
    "COMPENSATING": ["COMPENSATED", "MANUAL_CHECK"]
}

7. 什么是数据库回表？

答案：回表指的是通过二级索引查到主键后，还需要再去聚簇索引里查询完整数据。InnoDB 中主键索引的叶子节点存整行数据，二级索引的叶子节点通常存索引列和主键值。如果查询字段不在二级索引里，就需要回表。

减少回表的一种方式是覆盖索引，也就是查询所需字段都包含在索引里。这样数据库只查二级索引就能返回结果，不需要再查聚簇索引。

CREATE INDEX idx_user_status_amount
ON payment_order(user_id, status, amount);

-- 如果只查 user_id、status、amount，可能走覆盖索引
SELECT user_id, status, amount
FROM payment_order
WHERE user_id = 1001
  AND status = 'SUCCESS';

8. RAG 的应用场景有哪些？

答案：RAG 适合知识更新快、需要接入私有数据、要求答案可追溯的场景。比如企业知识库问答、客服辅助、法务合规、风控审核、医疗问答、运维排障、售后工单分析、代码知识库检索和多语言政策解释。

在跨境合规场景里，平台规则经常更新，不适合完全依赖模型参数记忆。RAG 可以把最新规则、历史违规案例和审核说明放进知识库，用户提问时先检索，再生成答案，并给出引用来源。

rag_scene = {
    "query": "这个商品在德国站点为什么不能上架",
    "retrieval_sources": ["平台规则", "历史违规案例", "欧盟合规文档"],
    "output": "审核原因 + 规则引用 + 修改建议"
}

9. RAG 的核心流程是什么？

答案：RAG 的核心流程是文档接入、清洗切分、向量化、索引构建、查询理解、检索召回、rerank、上下文构造、大模型生成和答案校验。线上系统还要补充权限过滤、缓存、评测、日志追踪和版本管理。

真正影响效果的不是某一个步骤，而是整条链路。文档切分不好会导致证据碎片化，embedding 不合适会导致召回偏差，rerank 不好会把无关内容塞给模型，prompt 不好会导致答案不引用证据。

def rag(query):
    rewritten = rewrite_query(query)
    candidates = hybrid_retrieve(rewritten, top_k=50)
    docs = rerank(rewritten, candidates, top_k=8)
    context = build_context(docs)
    answer = llm_generate(query, context)
    return verify_with_citations(answer, docs)

10. Query 重写的目的是什么？

答案：Query 重写的目的是提升检索召回质量。用户原始问题经常口语化、指代不清、关键词缺失，直接拿去检索可能召回不到正确文档。Query 重写会把问题补全成更适合检索的形式，比如补充实体、站点、时间范围、业务术语和同义表达。

但 Query 重写不能改变用户原意。工程上通常会保留原 query，同时生成多个 rewritten query，分别用于关键词检索和向量检索，再做融合。对于高风险场景，重写结果还需要可解释和可回退。

def rewrite_query(query, state):
    if "这个商品" in query and state.get("product_id"):
        return f"{query} 商品ID:{state['product_id']} 站点:{state.get('site', '')}"
    return query

11. Prompt 的标准写法是什么？

答案：一个稳定的 Prompt 通常要包含角色、任务目标、上下文、约束条件、输出格式和拒答规则。对于 RAG 场景，还要明确要求答案只能基于给定证据，不能编造引用，证据不足时要说明无法判断。

Prompt 不应该写成一大段散文，而应该结构清晰。尤其是企业应用里，输出格式最好固定成 JSON、表格或分段文本，方便后处理和评测。

你是跨境电商合规审核助手。
任务：根据给定规则和案例，解释商品被拦截的原因。
约束：
1. 只能使用上下文中的证据。
2. 不允许编造规则编号。
3. 证据不足时回答“当前证据不足以判断”。
输出：
- 结论
- 命中的规则
- 风险原因
- 修改建议

12. 提升 RAG 检索准确率的策略有哪些？

答案：提升检索准确率可以从数据、索引、召回、重排和评测几个方面入手。数据侧要清洗重复、过期、低质量文档；切分侧要按语义结构切 chunk；召回侧使用向量检索和 BM25 混合；重排侧使用 cross-encoder 或 LLM rerank；评测侧用真实问题集持续看 Recall@K 和证据命中率。

如果 query 包含商品 ID、规则编号、错误码、站点名称这类强实体，关键词检索权重应该更高。如果 query 是自然语言描述，向量检索更重要。不要指望一种检索方式解决所有问题。

def weighted_score(vector_score, bm25_score, has_code=False):
    if has_code:
        return 0.35 * vector_score + 0.65 * bm25_score
    return 0.7 * vector_score + 0.3 * bm25_score

13. RAG 检索出无关内容时该如何处理？

答案：无关内容不能直接塞给模型，否则模型会被错误证据带偏。工程上可以做相似度阈值过滤、rerank 截断、意图分类、metadata 过滤和答案前校验。如果 top 文档分数都很低，应该触发拒答或追问，而不是强行生成。

另外要排查是 query 问题、文档问题还是索引问题。如果是 query 太短，可以做 query rewrite；如果文档 chunk 噪声太大，要重新切分；如果 embedding 不适配业务术语，要换模型或微调 embedding。

def filter_retrieval_results(results, min_score=0.45):
    filtered = [r for r in results if r["score"] >= min_score]
    if not filtered:
        return {
            "action