用天壤小白搭建结构化文档集并创建问答应用

天壤小白是一个面向应用开发的大模型平台，它的核心能力之一是「文档集」：把企业或个人的文档上传进去，由平台完成解析、分片与语义索引，再让大模型基于这些内容回答问题。这样做的目的是把回答锚定在真实文档上，减少模型凭空编造的情况。这篇教程讲的是具体一件事：如何在天壤小白里建好一个结构化文档集，并基于它创建一个可用的问答应用。适合需要把表格、报告、图片资料变成可检索知识库的开发者与业务人员。平台入口与账号体系可参考天壤小白的工具页说明。

整篇内容围绕四个动作展开：上传并解析文档、设置字段类型与语义索引、创建应用并配置召回字段、调整上下文提示词模板。每一步都会给出可对照的配置项与判断依据，最后用一个从零到跑通的完整示例串起来。

准备工作

在动手之前，先把下面几件事确认清楚，能省掉后面大量返工。

账号与平台访问：需要在天壤小白开放平台注册并登录，文档集与应用开发都在平台内完成，不需要本地安装额外插件。
模型选择：平台提供不同成本档位的大模型，素材中出现的模型版本标识为 xiaobai-001、xiaobai-001-small、xiaobai-001-tiny。三者的差别主要在成本与能力档位，具体可用版本、计费方式与配额请以官网当前信息为准。
输入长度：该系列模型支持较长的文本输入，素材给出的长度是 3K。实际可用上限与计费口径同样以官网当前信息为准。
文档格式确认：平台支持上传的文件类型包括 xls、xlsx、csv、jsonl、pdf、html、htm、md、markdown、txt、doc、docx、jpg、jpeg、png、bmp、gif、tif。上传前先确认文件后缀在列表内，否则解析会失败。
内容整理：结构化文档的价值来自字段清晰。表格类文件建议先保证首行是字段名、每列含义单一，避免合并单元格与多层表头，否则字段识别容易错位。

操作步骤

第一步：上传文档

进入文档集功能后新建一个文档集，然后选择上传方式。平台提供两种来源：本地文件上传，以及从 URL 下载文档。

本地文件上传时，直接把准备好的文件拖入或选择上传即可。平台会自动完成格式解析，不需要手动转换。对于表格类文件（xls、xlsx、csv、jsonl），平台会按结构化文档处理，识别出字段；对于 pdf、doc、docx、md、txt 等文本类文件，则按普通文档解析。

如果资料在网页上，使用 URL 方式更省事：在文档集里选择从 URL 获取文档，填入目标网页地址，平台会自行抓取并解析页面内容。这种方式不需要安装任何浏览器插件，适合把公开的说明文档、公告页面、帮助中心文章快速纳入知识库。需要注意，抓取结果取决于页面本身的结构，正文被脚本动态渲染的页面可能抓不全，遇到这种情况改用本地保存后上传更稳妥。

第二步：处理图片与扫描件

图片类文件（jpg、jpeg、png、bmp、gif、tif）上传后，平台会自动执行 OCR 文字识别，把图片里的文字提取成可检索的文本。含图片的 PDF 报告同样适用，平台会识别其中的图片文字，不需要先把 PDF 拆成图片再逐张处理。

OCR 支持多种语言识别，素材明确提到的包括中文、英文、日语。这意味着同一份文档里混排中英文时通常不需要额外设置。识别质量受图片清晰度影响较大，扫描件建议保证分辨率足够、页面不要倾斜、避免大面积水印覆盖正文。

第三步：设置字段类型与语义索引

这是结构化文档集与普通文档集的关键差别。上传结构化文件后，平台会列出识别到的字段，你可以按需做两件事：

选择参与处理的字段：一份表格往往包含很多列，但并非每一列都对问答有用。比如一张产品表里有「内部编号」「创建人」「备注」这类字段，对回答用户问题帮助不大，可以只勾选真正承载信息的字段，例如「产品名称」「规格」「价格说明」。只保留必要字段能让后续的分片更干净。
决定是否加入语义索引：勾选后，该字段内容会进入语义检索范围，提问时能通过语义匹配召回相关片段，回答会更完整。不勾选则只作为普通上下文存在。对于需要被用户直接问到的字段，建议开启。

相比早期默认按固定长度分片存储的方式，基于字段的分类与字符分割更清晰合理：同一行记录的相关信息不会被切散到不同分片里，检索时召回的片段语义更完整。如果文档字段较多、含义差异大，优先使用字段级设置，而不是把所有列混在一起上传。

第四步：创建应用并设置召回字段

文档集准备好之后，进入应用开发环节新建一个应用，在知识来源处选择刚才建好的结构化文档集。

此时会出现「召回字段」的设置项。它的作用是明确告诉系统：回答问题时应该从哪些字段里取内容。有两种用法：

作为上下文输入：把选定字段的内容拼进提示词上下文，让模型在生成回答时参考。
直接用作搜索内容：把选定字段作为检索目标，系统召回与之强匹配的原始片段。

两种方式可以配合使用。配置得当的话，系统既能召回高度匹配的原始片段，也能在此基础上让大模型组织出更准确的回答。字段选得越贴近用户实际提问的角度，召回效果越好；如果用户会问「某个型号多少钱」，那么价格与型号字段就应当被纳入召回范围。

第五步：自定义上下文提示词模板

应用默认会使用一套提示词模板来组织上下文与指令。如果业务场景有特殊要求，可以自行调整模板内容，让模型输出更符合预期。常见的调整方向包括：

限定回答语言与语气，例如要求统一用简体中文、面向非技术读者解释。
规定回答结构，例如先给结论再列依据，或按条目输出。
约束边界，例如文档中没有的信息明确说明「未找到相关内容」，而不是自行推测。
指定引用方式，例如要求在回答中标注信息来自哪个字段或哪段原文。

模板中的变量用于插入检索到的文档片段与用户问题，调整时保留这些占位符，只改写指令部分，避免破坏上下文注入逻辑。

一个完整示例

下面用一个具体场景把上面的步骤串起来：假设手上有一份产品价格表 products.xlsx，希望做一个能回答「某型号产品多少钱、有哪些规格」的问答应用。

第 1 步，准备文件。确认表格首行是字段名，例如：

型号,产品名称,规格,单价,备注
A-100,标准传感器,量程 0-10m,1200,常规款
A-200,标准传感器,量程 0-50m,2400,常规款
B-300,防水传感器,量程 0-10m,1800,IP68

去掉合并单元格、空行与多余的表头层级，另存为 xlsx 或 csv。

第 2 步，上传。在文档集里新建集合，上传 products.xlsx。平台解析后应能识别出「型号」「产品名称」「规格」「单价」「备注」五个字段。

第 3 步，设置字段。勾选「型号」「产品名称」「规格」「单价」四个字段参与处理，并为它们开启语义索引；「备注」字段视情况保留，如果备注里常有关键信息（如防护等级）也一并开启。

第 4 步，建应用。新建应用，知识来源选择该文档集。召回字段选择「型号」「产品名称」「规格」「单价」，让系统在用户提到型号或产品名时能定位到对应行。

第 5 步，改提示词。在上下文提示词模板中加入类似指令：

你是产品信息助手。请仅依据下方检索到的文档内容回答用户问题。
如果文档中没有相关信息，直接回答「文档中未找到该信息」，不要推测。
回答时先给出型号与单价，再补充规格说明。

文档内容：
{context}

用户问题：
{question}

其中 {context} 与 {question} 代表平台注入的检索片段与用户提问，具体占位符名称以平台界面显示为准，不要自行改名。

第 6 步，验证。在应用调试界面提问「A-200 多少钱」，预期回答能命中 2400 这一行并给出规格；再问一个文档里没有的型号，预期回答是「文档中未找到该信息」。两个方向都通过，说明字段选择与提示词约束都生效了。

如果还想把一份带图的 PDF 说明书也纳入同一个应用，可以再建一个文档集上传该 PDF，OCR 会自动提取图片中的文字，然后在应用里同时挂载两个文档集。注意不同文档集的字段结构可能不同，召回字段需要分别设置。

注意事项

格式白名单：只有素材列出的那些后缀能被解析。上传前核对扩展名，尤其是 markdown 与 md 两种写法都支持，但 rtf、ppt 之类不在列表内。
OCR 不是万能的：识别准确率再高也依赖原图质量。低分辨率截图、手写体、严重倾斜的扫描页都可能出错，重要文档建议上传后抽查提取结果。
URL 抓取的边界：从 URL 获取文档适合结构清晰的静态页面。需要登录才能访问的页面、依赖前端脚本渲染的页面，抓取结果可能不完整。
字段设置影响召回：没有开启语义索引的字段不会参与语义检索，只作为普通上下文。如果发现某些问题总是答不上来，先回头检查对应字段是否被排除在索引之外。
提示词模板不要破坏占位符：自定义模板时保留上下文与问题的注入位置，否则模型拿不到检索内容，回答会退化成凭空生成。
版本与计费信息会变：模型版本、输入长度上限、可用文件类型、配额与价格都可能随平台迭代调整，实际以官网当前信息为准。本文涉及的模型标识与 3K 输入长度来自特定版本说明，不保证长期有效。