如果凭直觉给国内几家 AI 的联网回答写采集和入库配置，第一版多半是这样：

```text
timeout      = 120s            # 各家一样
answer       VARCHAR(4000)     # 四千字应该够了
citations    NOT NULL          # 联网回答都该有引用，空了就当解析失败
```

拿真实记录一对，这三行都有问题。智谱的成功回答里有 30% 超过 120 秒，元宝有 14%。超过 4,000 字的回答，智谱占 23.6%，DeepSeek 占 8.9%。引用为空的，讯飞是 97%，Kimi 是 80%，按第三行的规则，这两家几乎条条都算解析失败。

下面把 8 家各算一遍：耗时、长度、引用条数、Markdown 写法，再看 26 天里这些数稳不稳。最后把结果写成一份按平台区分的配置。代码用 pandas，输出原样贴出来。

## 数据：40 道题，8 家，26 天

数据是一份监测记录。MaxAEO 每天拿自家品牌做监测，我在这个团队负责监测数据。题目固定 40 道，都属于「AI 搜索监测、GEO 工具」这个品类，有怎么选工具的，也有「同一网站不同页面的引用如何归并」这类偏技术实现的。每道题每天在 8 家各问一次，时间是 2026-09-27 到 10-22。

8 家在数据里的写法：deepseek、doubao（豆包）、kimi、qianwen（通义千问）、wenxin（文心一言）、xunfei（讯飞星火）、yuanbao（腾讯元宝）、zhipu（智谱清言）。

这篇用到 5 个字段：`状态`、`耗时(ms)`、`原始回答`、`引用数量`、`引用详情`。有两点要先说。第一，`耗时` 是采集任务记下的单条总耗时，采集端自己的重试也算在里面，比平台纯生成的时间长。第二，`原始回答` 是采集一侧做过初步整理之后存下的文本，格式上的差别，有一部分是这一步带来的。你自己接的时候，格式要按你实际拿到的返回再核一遍，耗时、长度、引用条数这些分布可以直接参考。

```python
import pandas as pd

df = pd.read_json("rows.jsonl", lines=True)
print(len(df), "行,", df["日期"].nunique(), "天,", df["平台"].nunique(), "个平台,", df["查询词"].nunique(), "道题")
print(df["状态"].value_counts().to_dict())
print("失败最多的三天:", df[df["状态"] == "failed"]["日期"].value_counts().head(3).to_dict())

ok = df[df["状态"] == "success"].copy()
ok["秒"] = ok["耗时(ms)"] / 1000
ok["字数"] = ok["原始回答"].fillna("").str.len()
```

输出：

```text
8320 行, 26 天, 8 个平台, 40 道题
{'success': 8232, 'failed': 88}
失败最多的三天: {'2026-10-21': 41, '2026-10-22': 31, '2026-10-20': 8}
```

8,320 次请求里失败 88 次，占 1.1%。失败不是平均分在 26 天里，10-21 和 10-22 两天就占了 72 次。下文只统计 8,232 条成功记录。

## 耗时：中位数差 4 倍，长尾差得更多

```python
g = ok.groupby("平台")["秒"]
t = pd.DataFrame({
    "P50": g.median(),
    "P90": g.quantile(0.90),
    "P95": g.quantile(0.95),
    "P99": g.quantile(0.99),
    "最长": g.max(),
    ">120s占比%": g.apply(lambda s: (s > 120).mean() * 100),
}).round(0).astype(int)
print(t.sort_values("P50"))

# 耗时跟什么走：回答长度，还是引用条数（Spearman）
r = ok.groupby("平台").apply(lambda x: pd.Series({
    "跟字数": x["秒"].corr(x["字数"], method="spearman"),
    "跟引用数": x["秒"].corr(x["引用数量"], method="spearman"),
}), include_groups=False).round(2)
print(r.T)
```

输出：

```text
          P50  P90  P95  P99   最长  >120s占比%
平台                                         
deepseek   26   58   65   78  120         0
kimi       28   55   67   93  307         0
wenxin     33   46   54   77  132         0
xunfei     41   73   86  123  154         1
qianwen    54   87  100  117  246         1
yuanbao    54  136  208  307  551        14
doubao     75  103  116  165  232         4
zhipu     104  141  151  247  315        30
平台    deepseek  doubao  kimi  qianwen  wenxin  xunfei  yuanbao  zhipu
跟字数       0.21    0.46  0.64     0.22    0.29    0.88     0.18   0.33
跟引用数      0.34    0.13  0.49     0.05    0.16    0.05     0.62   0.27
```

中位数从 DeepSeek 的 26 秒到智谱的 104 秒，相差 4 倍。长尾更不一样：元宝的 P95 是 208 秒，P99 是 307 秒，最长一条 551 秒，比其他几家的最长值都高出一截。统一设 120 秒的话，智谱 30%、元宝 14% 本来能拿到的回答，会被超时切掉。

输出里的第二张表是相关系数，能看出时间大致花在哪里。讯飞的耗时和回答字数的相关系数是 0.88，基本是字写得越多越慢，时间主要花在生成上。元宝的耗时和引用条数的相关系数是 0.62，和字数只有 0.18，引用越多越慢，更像是时间花在检索和读网页上。所以讯飞的超时可以按预期回答长度来放宽；元宝的问题在长尾，超时调得再大也只是让慢的那部分接着占资源，最好给它单开一个队列，免得拖住其他几家。

超时之后要记成「超时」，不要存成一条空回答。否则统计提及率时，这条会被当成「回答了，没提到」。

## 回答多长，引用多少

```python
g = ok.groupby("平台")
t = pd.DataFrame({
    "字数P50": g["字数"].median(),
    "字数P99": g["字数"].quantile(0.99),
    "字数最长": g["字数"].max(),
    "引用P50": g["引用数量"].median(),
    "引用P90": g["引用数量"].quantile(0.90),
    "引用最多": g["引用数量"].max(),
    "零引用%": g["引用数量"].apply(lambda s: (s == 0).mean() * 100),
}).round(0).astype(int)
print(t.sort_values("字数P50"))
print("26 天回答原文 UTF-8 共",
      round(ok["原始回答"].fillna("").str.encode("utf-8").str.len().sum() / 2**20, 1), "MB")
```

输出：

```text
          字数P50  字数P99   字数最长  引用P50  引用P90  引用最多  零引用%
平台                                                     
wenxin     1166   1908  18457     29     36    79     0
xunfei     1394   3325   4223      0      0     8    97
qianwen    1631   4013   5813     14     19    26    18
kimi       1768   4663   6648      0     13    50    80
doubao     2073   3507   4380     18     28    47    27
yuanbao    2415   4962   7048     20     49    98    17
deepseek   2914   5302   6906     18     20    90    11
zhipu      3284   5756   8369     25     39    71     7
26 天回答原文 UTF-8 共 36.2 MB
```

`字数` 是原始回答的字符数，Markdown 符号也算在里面。中位数最短的是文心，1,166 字；最长的是智谱，3,284 字。有 5 家的 P99 超过 4,000 字，所以开头那个 `VARCHAR(4000)` 不能用。

最长值不能拿来定字段长度。文心最长的一条有 18,457 字，是它中位数的 15.8 倍，属于个别异常回答，正常回答写不到这么长。稳妥的做法是字段直接用 `TEXT`，不设上限，再按 P99 的 1.5 倍设一条告警线，超过就打标，留给人看。

存储量很小。26 天、8,232 条回答，原文按 UTF-8 一共 36.2 MB，每条平均约 4.5 KB，每天约 1.4 MB。所以原文没必要截断，也没必要只存清洗后的版本，原样存一份，以后换解析规则时还能重跑。

引用条数各家差得更远。中位数从 0 到 29，最多一条有 98 个引用（元宝）。条数这么不固定，引用最好单独建一张子表，一条引用存一行，记下回答 ID、序号、标题、URL。存成几个固定列肯定不够；整段塞进 JSON 字段也行，但后面要按来源站点做聚合时，会比子表麻烦。

## 引用为空，先分清是哪种空

讯飞 97%、Kimi 80% 的回答没有引用，这两个比例高到不像个别失败。再按题目拆开看：

```python
howto = [
    "如何从 AI 回答中提取所有被提及的品牌？",
    "同一个品牌有不同写法时如何做名称归一？",
    "同一网站不同页面的引用如何归并？",
    "如何聚合 AI 回答里的引用 URL 并统计来源？",
    "如何发现 AI 回答中的品牌错误信息？",
]
ok["题型"] = ok["查询词"].isin(howto).map({True: "技术实现类(5题)", False: "其他(35题)"})
z = ok.assign(零引用=ok["引用数量"] == 0)
print((z.pivot_table(index="平台", columns="题型", values="零引用", aggfunc="mean") * 100).round(0).astype(int))

# 按行数一数引用详情的条数，和「引用数量」字段对一下
n_lines = ok["引用详情"].fillna("").str.count(r"(?m)^\d+[.] ")
bad = ok[n_lines != ok["引用数量"]]
print("对不上:", len(bad), "条", bad["平台"].value_counts().to_dict())
```

输出：

```text
题型        其他(35题)  技术实现类(5题)
平台                          
deepseek        1         84
doubao         21         69
kimi           78         89
qianwen        15         44
wenxin          0          0
xunfei         99         85
yuanbao        10         68
zhipu           1         51
对不上: 10 条 {'doubao': 10}
```

那 5 道技术实现类的题，比如怎么做名称归一、怎么聚合引用 URL，DeepSeek 有 84% 的回答没有引用，其他 35 道题只有 1%。智谱是 51% 对 1%，元宝是 68% 对 10%。遇到这类技术问题，这几家多半没去联网搜索，直接凭模型自己的知识作答。这种空是平台的正常行为，算不上故障。

讯飞两类题都在 85% 以上，原因就不在题目上了。单看这份数据，分不清是讯飞没给引用，还是采集没拿到。所以引用字段不要只存「有」和「无」，最好加一个状态，分成四种：有引用、平台没给、采集没拿到、解析失败。按单条回答判不出是哪一种，就按平台看比例：每家先定一个「零引用基线」，某天的零引用比例明显偏离基线，再去查。

上面输出的最后一行是另一个坑。按「行首是数字加点」来数引用详情，豆包有 10 条和 `引用数量` 对不上，数出来的都比字段多。原因是有些引用的标题本身带换行（比如抖音视频的文案），换行后的下一行又刚好以「3.」这类编号开头。所以拆引用详情时，要按每条末尾的「站点 | URL [类型]」来切，不能按行切。

## 格式：同样是 Markdown，写法各家不同

```python
rules = {
    "标题": r"(?m)^\s{0,3}#{1,6}\s",
    "列表": r"(?m)^\s*(?:[-*•]|\d{1,2}[.、)）]|\d{1,2}\x5c[.])\s*\S",
    "表格": r"(?m)^\s*[|].*[|]\s*$\n\s*[|]?\s*:?-{3,}",
    "表情": r"[\U0001F300-\U0001FAFF\u2600-\u27BF]",
    "转义": r"\x5c[-.*_#]",
    "内嵌链接": r"[]][(]https?://",
}
text = ok["原始回答"].fillna("")
for name, pat in rules.items():
    ok[name] = text.str.contains(pat, regex=True)
ok["纯段落"] = ~(ok["标题"] | ok["列表"] | ok["表格"])
ok["结尾追问"] = text.str[-120:].str.contains(r"需要我|要不要我|我可以帮你|我可以为你")
cols = list(rules) + ["纯段落", "结尾追问"]
print((ok.groupby("平台")[cols].mean() * 100).round(0).astype(int))
```

输出：

```text
           标题   列表  表格  表情  转义  内嵌链接  纯段落  结尾追问
平台                                             
deepseek  100   99   2  55  94    87    0    14
doubao    100  100  23  67   0     1    0    27
kimi       79   98  50  20   1     3    0    30
qianwen    95  100  85   8   1     2    0    70
wenxin    100  100  13  93   0     0    0    94
xunfei     59   99   6  28   0     1    1     0
yuanbao    96   99  74  21   2     1    1    28
zhipu      88   88  86  14   2     1   11     2
```

除了智谱，各家几乎每条回答都有列表，不带标题、列表、表格的「纯段落」回答几乎没有。差别主要在下面几处：

- **表格**：千问 85%、智谱 86%、元宝 74% 的回答带表格，DeepSeek 只有 2%。如果入库前把 Markdown 剥成纯文本，表格会变成一串挤在一起的单元格，列和列之间的对应关系就没了。要从表格里抽信息，得在剥格式之前做。
- **转义和内嵌链接**：DeepSeek 94% 的回答里有 `1\.`、`\-` 这类反斜杠转义，87% 的回答把引用直接写在正文里，形如 `[\-5](网址)`。不先去掉转义和这些标记，按字数统计、按句子切分都会出错。
- **表情**：文心 93% 的回答带表情符号，常放在小标题前面。按标题切段时，匹配标题文字要先去掉表情。
- **智谱的两种格式**：智谱有 11% 的回答没有标题、列表和表格。我翻了这部分记录：一共 114 条，表格被压成了一整行，引用以「域名+2」这样的小尾巴夹在句子里，111 条都带这种标记。最后一次出现是 10-19。同一个平台的同一个字段，混着两种格式。
- **结尾追问**：文心 94%、千问 70% 的回答，最后会问一句「需要我帮你……吗」。要拿「回答的最后一段」当结论，或者要统计正文长度，得先把这句去掉。

入库时原文一列不动，另存一列清洗后的文本。清洗函数按平台写，每家只处理自己那几种情况。

## 26 天里稳不稳

回答长度、耗时、引用条数，日常的波动都不大。真要提防的是某一天突然整体变了。我的判断规则是：拿每天的中位数和前 7 天的中位数比，连续两个采集日往同一个方向越过阈值，就记为一次跳变。

```python
daily = ok.groupby(["平台", "日期"]).agg(
    秒=("秒", "median"),
    字数=("字数", "median"),
    引用=("引用数量", "mean"),
    零引用=("引用数量", lambda s: (s == 0).mean()),
)
# 每个指标：相对变化阈值、绝对变化下限（防止 0.5 条变 1 条这种小数被当成翻倍）
LIMIT = {"秒": (0.3, 5), "字数": (0.3, 200), "引用": (0.3, 3), "零引用": (None, 0.2)}

def steps(s):
    """和前 7 天中位数比，连续两个采集日往同一方向越线，记一次跳变"""
    rel, absd = LIMIT[s.name]
    base = s.shift(1).rolling(7, min_periods=3).median()
    d = s - base
    out = d.abs() >= absd
    if rel:
        out &= (d / base).abs() > rel
    sign = d.where(out).apply(lambda x: 0 if pd.isna(x) else (1 if x > 0 else -1))
    hit = (sign != 0) & (sign == sign.shift(-1)) & (sign != sign.shift(1))
    return [(t, base[t], s[t], s.shift(-1)[t]) for t in s.index[hit]]

for plat, g in daily.groupby(level=0):
    g = g.droplevel(0)
    for m in g.columns:
        for t, b, x1, x2 in steps(g[m]):
            print(f"{plat:9s}{m:4s} {t}  前7天 {b:.2f} → {x1:.2f}，之后 {x2:.2f}")
```

输出：

```text
deepseek 秒    2026-10-20  前7天 26.12 → 47.75，之后 49.86
deepseek 引用   2026-10-20  前7天 15.95 → 45.55，之后 34.92
doubao   引用   2026-10-21  前7天 13.03 → 20.88，之后 24.55
kimi     秒    2026-10-16  前7天 24.11 → 38.87，之后 35.45
kimi     引用   2026-10-16  前7天 1.12 → 6.35，之后 7.35
kimi     零引用  2026-10-16  前7天 0.88 → 0.55，之后 0.50
qianwen  秒    2026-10-14  前7天 64.49 → 35.32，之后 28.24
xunfei   秒    2026-10-01  前7天 60.40 → 37.53，之后 36.35
xunfei   秒    2026-10-20  前7天 36.72 → 72.41，之后 67.46
xunfei   字数   2026-10-01  前7天 2139.50 → 1372.00，之后 1252.00
yuanbao  秒    2026-10-20  前7天 43.81 → 93.56，之后 93.73
yuanbao  引用   2026-10-20  前7天 20.82 → 32.65，之后 38.08
```

26 天里有 12 次跳变，落在 6 家上，文心和智谱一次都没有。挑几次说一下：

- 讯飞 10-01：回答字数从 2,140 降到 1,372，耗时同一天从 60 秒降到 38 秒，两个变化对得上，像是回答写法变了。
- 千问 10-14：耗时从 64 秒降到 35 秒，字数没变。
- Kimi 10-16：耗时变长，零引用比例从 88% 降到 55%，平均引用条数从 1 条多涨到 6 条多。从这一天起，Kimi 带引用的回答多了不少。
- 10-20：DeepSeek、讯飞、元宝三家同一天变慢，DeepSeek 和元宝的引用条数也一起涨了。（DeepSeek 10-21 没有成功记录，所以它「之后」的数取的是 10-22。）

几家在同一天一起变，我会先查自己这边，比如网络、并发、采集脚本有没有改过，再去猜是不是平台改了。不管原因在哪边，这份跳变清单都说明一件事：基于固定一段时间算出来的阈值，过一两周就可能不准了。

## 落成一份配置

最后把前面几项落成按平台区分的配置。超时取「26 天 P99」和「最近 7 天 P99」里大的那个，乘 1.2，向上取整到 10 秒。长回答告警线取字数 P99 的 1.5 倍。零引用基线只用最近 7 天的数据算，因为 Kimi 10-16 那次跳变之后，旧的基线已经不对了。

```python
import math

last7 = ok[ok["日期"] >= "2026-10-16"]
cfg = {}
for plat, g in ok.groupby("平台"):
    r = last7[last7["平台"] == plat]
    p99 = max(g["秒"].quantile(0.99), r["秒"].quantile(0.99))
    cfg[plat] = {
        "timeout_s": math.ceil(p99 * 1.2 / 10) * 10,
        "long_answer_alert": math.ceil(g["字数"].quantile(0.99) * 1.5 / 500) * 500,
        "empty_cite_baseline": round(float((r["引用数量"] == 0).mean()), 2),
    }
for k, v in cfg.items():
    print(k, v)
```

输出：

```text
deepseek {'timeout_s': 100, 'long_answer_alert': 8000, 'empty_cite_baseline': 0.04}
doubao {'timeout_s': 210, 'long_answer_alert': 5500, 'empty_cite_baseline': 0.28}
kimi {'timeout_s': 140, 'long_answer_alert': 7000, 'empty_cite_baseline': 0.53}
qianwen {'timeout_s': 150, 'long_answer_alert': 6500, 'empty_cite_baseline': 0.06}
wenxin {'timeout_s': 120, 'long_answer_alert': 3000, 'empty_cite_baseline': 0.0}
xunfei {'timeout_s': 180, 'long_answer_alert': 5000, 'empty_cite_baseline': 0.97}
yuanbao {'timeout_s': 380, 'long_answer_alert': 7500, 'empty_cite_baseline': 0.16}
zhipu {'timeout_s': 310, 'long_answer_alert': 9000, 'empty_cite_baseline': 0.06}
```

和开头那三行比：超时从统一的 120 秒，变成 100 到 380 秒不等；回答字段不设上限，只设告警线；引用为空也不再一律当成失败，而是和各家的基线比。这些数由脚本算出来，不写死在代码里。每天先跑一遍 `steps()`，哪家报了跳变，就用最近 7 天的数据把那一家的配置重算一次。



拿真实记录一对，这三行都有问题。智谱的成功回答里有 30% 超过 120 秒，元宝有 14%。超过 4,000 字的回答，智谱占 23.6%，DeepSeek 占 8.9%。引用为空的，讯飞是 97%，Kimi 是 80%，按第三行的规则，这两家几乎条条都算解析失败。

接国内 8 家 AI 的联网回答，超时、字段和引用该怎么设？用 26 天 8,232 条记录算了一遍（附 pandas）

40 道题在 8 家国内 AI 上连问 26 天，统计耗时、回答长度、引用条数、写法和逐日跳变。统一 120 秒超时会切掉智谱三成回答，讯飞 97% 的回答没有引用，6 家出现过跳变。

人工智能

数据库

大数据

国内8家AI联网回答的采集配置需按平台差异化设置：超时从100秒到380秒不等，回答字段不设上限但按P99的1.5倍设告警线，引用为空需区分平台行为而非一律判失败。耗时中位数从DeepSeek的26秒到智谱的104秒相差4倍，零引用比例从文心的0%到讯飞的97%差距悬殊。建议按26天监测数据动态调整配置，并单独处理表格、表情符号、结尾追问等格式差异。

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

国内8家AI联网回答的采集配置需按平台差异化设置：超时从100秒到380秒不等，回答字段不设上限但按P99的1.5倍设告警线，引用为空需区分平台行为而非一律判失败。耗时中位数从DeepSeek的26秒到智谱的104秒相差4倍，零引用比例从文心的0%到讯飞的97%差距悬殊。建议按26天监测数据动态调整配置，并单独处理表格...

接国内 8 家 AI 的联网回答，超时、字段和引用该怎么设？用 26 天 8,232 条记录算了一遍（附 pandas）-腾讯云开发者社区-腾讯云

接国内 8 家 AI 的联网回答，超时、字段和引用该怎么设？用 26 天 8,232 条记录算了一遍（附 pandas）

接国内 8 家 AI 的联网回答，超时、字段和引用该怎么设？用 26 天 8,232 条记录算了一遍（附 pandas）

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐