带得科技 大模型应用开发 二面

1. 你们线上大模型应用的整体架构是怎样的？

常见架构就是这几层：

用户请求先进入 API 网关，再到业务服务层。业务服务层负责鉴权、限流、Prompt 拼装、会话管理、工具编排。如果有知识库，就先走检索链路；如果要调外部能力，就走工具调用；最后把上下文交给大模型生成结果。生成结果出来后，再做内容过滤、格式化、日志落库、监控上报。

核心链路一般是：

用户请求 -> 业务编排 -> 检索/工具 -> 模型推理 -> 后处理 -> 返回结果

2. 你们怎么做 Prompt 工程？

Prompt 不是简单写一句提示词，而是模板化管理。

常见做法是把 Prompt 拆成几部分：

• system prompt
• 业务指令
• 上下文
• few-shot 示例
• 输出格式约束
• 安全约束

线上一般不会把 Prompt 写死在代码里，而是做成配置化。这样方便灰度、A/B 测试、版本回滚。

Prompt 优化最常见的方向有三个：

• 角色设定清晰
• 输出格式明确
• 给足边界条件，减少自由发挥

3. 怎么减少大模型幻觉？

减少幻觉常见就这几种办法：

• 给模型真实上下文，不要裸问
• 明确告诉它不知道就说不知道
• 限制回答范围，只允许基于提供内容回答
• 给标准输出格式
• 对结果做引用和校验
• 高风险场景加规则兜底或人工审核

如果是知识问答场景，最常见就是：

检索增强 + 回答约束 + 结果校验

幻觉不能只靠模型自觉，必须靠上下文、Prompt 和校验一起压。

4. temperature、top_p 这些参数分别是干什么的？

temperature 控制随机性。越低，输出越稳定；越高，输出越发散。

top_p 是核采样。模型不是从所有词里采样，而是只从累计概率达到某个阈值的一小部分词里采样。top_p 越小，输出越保守。

常见经验：

• 问答、摘要、结构化提取：temperature 低一些
• 文案、创作、发散生成：temperature 高一些

一般线上不会同时把 temperature 和 top_p 调得太激进，不然结果容易飘。

5. Function Calling / Tool Calling 是怎么做的？

核心就是让模型别直接回答，而是先判断要不要调用工具。

常见流程：

模型先根据用户问题和工具描述决定是否调用工具。如果要调，就输出工具名和参数。业务层接到这个结构化结果后，真正执行工具。拿到工具结果后，再把结果回传给模型，让模型生成最终答案。

关键点有两个：

• 工具描述要清楚
• 参数校验要做严，不能直接信模型

一个简单例子：

tool_call = {
    "name": "get_weather",
    "arguments": {
        "city": "北京"
    }
}

6. 你们怎么做会话记忆？

会话记忆通常分两种：

短期记忆和长期记忆。

短期记忆就是当前几轮对话上下文，直接放在 prompt 里。长期记忆一般是把用户偏好、历史事实、重要事件提取出来，单独存储，必要时再召回。

线上不会无限拼接全部历史消息，因为：

• token 成本高
• 长上下文噪声大
• 很多历史内容根本没用

所以常见做法是：

• 保留最近 N 轮
• 对老对话做摘要
• 关键信息单独结构化存储

7. 流式输出是怎么实现的？

流式输出本质上就是模型边生成，服务边返回。不是等整段话生成完再一次性返回。

常见实现方式：

• 模型服务端按 token 或 chunk 推送
• 业务层用 SSE 或 WebSocket 转发给前端
• 前端一边接收一边渲染

这样做的好处：

• 首字返回更快
• 用户体感更好
• 长回答不容易让用户觉得卡死

如果是 Python 服务里，常见就是生成器逐段返回。

def stream_answer():
    chunks = ["你好，", "这里是", "流式输出结果。"]
    for c in chunks:
        yield c

8. 怎么控制大模