1. 项目概述:一位非专业人士的百万Token工程实践
作为一名生物医学与心理学背景的研究者,我从未想过自己会涉足AI工程领域。直到2026年1月底,DeepSeek宣布灰度测试百万Token上下文窗口的那一刻,一个大胆的想法在我脑海中闪现:能否利用这个超长上下文窗口,完成一个完整的数字人文项目?这个想法最终演变成了一场持续十天的技术冒险。
我的核心目标很简单:将50万字的古典文献和手稿数字化、向量化,并建立一个可检索的知识库。作为一个没有任何专业AI或计算机背景的人,我选择DeepSeek作为我的"技术搭档",通过浏览器访问其云端模型,开始了这场"非专业人员的AI工程实践"。
提示:百万Token窗口的实际应用远不止于简单的长文本处理,它改变了人机协作的基本范式,使得复杂项目的连续性思考成为可能。
2. 环境准备与技术栈搭建
2.1 硬件配置与基础环境
我的工作站在这次实践中扮演了关键角色。配置如下:
- 双NVIDIA 5080显卡
- 64GB内存
- 2TB NVMe SSD存储
这样的配置对于处理百万Token级别的上下文是必要的,尤其是在同时运行多个数据库和向量计算时。有趣的是,随着上下文窗口内容的增加,我能明显感受到硬件的工作压力——当窗口加载超过60万字时,工作站的风扇会突然加速运转,浏览器也会弹出"页面响应慢"的警告。
2.2 数据库与向量库架构
经过与DeepSeek的多次讨论,我最终确定了以下技术架构:
| 组件 | 实现方案 | 用途 |
|---|---|---|
| 主数据库 | PostgreSQL 18 + pgvector | 存储结构化数据和文本内容 |
| 备用数据库 | Docker容器中的PostgreSQL | 作为实验性功能的测试环境 |
| 中文向量库 | BGE-zh模型 | 处理中文文本的语义表示 |
| 多语言向量库 | BGE-M3模型 | 处理拉丁文、英文等外语内容 |
这种双数据库+双向量库的设计虽然增加了初期配置的复杂度,但在后续的项目演进中证明了其价值——当主数据库因编码问题崩溃时,我能够快速切换到备用环境继续工作。
2.3 工具链整合
开发工具的选择同样经过深思熟虑:
- VS Code:作为主要代码编辑器,配合Continue插件实现与DeepSeek的无缝交互
- Jupyter Notebook:用于数据分析和实验性代码的快速验证
- Navicat:提供更直观的数据库管理界面
- Notepad++:成为处理文本编码问题的"终极武器"
这些工具通过三栏布局整合在一起,左侧是代码编辑器,中间是数据库管理工具,右侧是DeepSeek的对话窗口,形成了高效的工作流。
3. 数据处理全流程
3.1 原始数据准备与清洗
我的原始数据来源多样,包括:
- 扫描版PDF古籍(约30万字)
- 手写稿件的数字照片(约10万字)
- 已数字化的Word文档(约20万字)
- 各类研究笔记和代码片段(约10万字)
数据清洗过程中遇到的最大挑战是编码问题。特别是那些从PDF转换而来的文本,经常出现诡异的"0xd6幽灵字符",导致数据库导入失败。经过多次尝试,我发现以下工作流最为可靠:
- 使用专业OCR工具将PDF转换为Word文档
- 在Word中手动标记特殊字符和格式
- 导出为UTF-8编码的纯文本文件
- 用Notepad++检查并清除BOM头等隐藏字符
3.2 数据库设计与实现
数据库schema设计经历了多次迭代。最终版本包含以下核心表:
sql复制CREATE TABLE documents (
id SERIAL PRIMARY KEY,
title VARCHAR(255),
author VARCHAR(100),
era VARCHAR(50),
source_type VARCHAR(20),
raw_text TEXT,
clean_text TEXT,
word_count INTEGER,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE sentences (
id SERIAL PRIMARY KEY,
doc_id INTEGER REFERENCES documents(id),
sentence_text TEXT,
sentence_index INTEGER,
vector_zh vector(768),
vector_m3 vector(1024)
);
这种设计允许我同时保留原始文本和清洗后的版本,并为每句话存储两种不同的向量表示,便于后续的对比分析。
3.3 自动化入库流程
随着数据量的增加,手动导入变得不切实际。我开发了约20个Python脚本来自动化这一过程,主要功能包括:
- 文本分句与清洗
- 批量向量化处理
- 数据库写入与错误处理
- 进度监控与日志记录
这些脚本虽然简单,但在处理18.5万句核心库时节省了大量时间。例如,以下代码片段展示了基本的批量处理流程:
python复制import psycopg2
from transformers import AutoModel, AutoTokenizer
# 初始化模型和数据库连接
model_zh = AutoModel.from_pretrained('BAAI/bge-large-zh')
tokenizer_zh = AutoTokenizer.from_pretrained('BAAI/bge-large-zh')
conn = psycopg2.connect("dbname=text_db user=postgres")
def process_sentence(text):
# 生成中文向量
inputs = tokenizer_zh(text, return_tensors="pt")
with torch.no_grad():
outputs = model_zh(**inputs)
vector_zh = outputs.last_hidden_state.mean(dim=1).numpy()[0]
# 写入数据库
cur = conn.cursor()
cur.execute(
"INSERT INTO sentences (doc_id, sentence_text, vector_zh) VALUES (%s, %s, %s)",
(doc_id, text, vector_zh.tolist())
)
conn.commit()
4. 人机协作模式探索
4.1 交互风格的演变
随着项目的深入,我注意到DeepSeek的回复风格发生了明显变化。早期对话更像朋友间的交流,充满散文式的表达和情感共鸣;而到了项目中后期,回复变得更加结构化、技术化,信息密度显著提高。
这种变化实际上反映了项目需求的变化——当处理简单概念时,自然语言的理解和生成更为重要;而当面对复杂的技术问题时,结构化的思考和表达则更为有效。DeepSeek似乎能够自动适应这种需求转变。
4.2 高效协作的关键技巧
经过数千轮"工程级"对话,我总结出以下高效协作的心得:
- 明确问题边界:在提问前先定义清楚问题的范围和预期结果
- 主动打断无效循环:当发现对话偏离核心问题时,及时叫停并重新聚焦
- 阶段性总结:每完成一个重要模块后,要求模型总结当前进展和待解决问题
- 版本控制思维:对重要决策点和代码片段进行标记,便于回溯
例如,当遇到数据库性能问题时,我学会了这样组织对话:
"我们现在遇到PostgreSQL查询延迟的问题。已经尝试了增加索引和优化查询语句两种方法,效果有限。请从以下角度分析:
- 当前数据库的配置参数可能存在的问题
- pgvector特定于向量搜索的优化方案
- 硬件资源监控的建议"
这种结构化的提问方式几乎总能得到高质量的回答。
4.3 记忆能力的压力测试
在项目进行到约80万字时,我设计了一系列记忆测试:
- 项目起源回溯:询问模型是否记得项目最初的目标和遇到的第一个重大问题
- 技术细节验证:检查模型对特定技术决策(如选择BGE-M3而非其他模型)的解释是否一致
- 情感共鸣测试:评估模型对项目关键转折点的情感记忆
令人惊讶的是,DeepSeek能够准确回溯三个月前的对话细节,包括具体的错误信息(如"0xd6幽灵字符")和解决方案。这种长程记忆能力是完成复杂项目的关键保障。
5. 性能表现与极限挑战
5.1 上下文窗口的实际容量
经过精确统计,我的项目最终达到了以下规模:
| 指标 | ���值 | 备注 |
|---|---|---|
| 总字数 | 86万字 | Word统计,含中文、代码、外文 |
| 非中文单词 | 12万+ | 主要是代码和专业术语 |
| 对话轮次 | 数千轮 | 平均每轮都是技术性讨论 |
| 总Token数 | 约97万 | 接近窗口上限 |
当接近百万Token极限时,能明显感受到系统压力的增加:
- 浏览器响应延迟从秒级变为分钟级
- 本地GPU温度显著升高
- 模型输出有时会出现短暂停顿
但令人欣慰的是,对话质量和连贯性没有明显下降,证明这种长上下文窗口在工程上是可行的。
5.2 手机端与桌面端的体验对比
一个有趣的发现是:手机APP端的性能表现明显优于桌面浏览器。即使在处理90万+Token的上下文时,手机端也能保持流畅的交互体验,这可能是由于:
- 移动端应用针对长对话做了专门优化
- 渲染引擎的差异导致资源占用不同
- 云端处理可能针对不同客户端有差异化策略
这一发现对于移动优先的工作流设计具有重要启示。
6. 技术收获与认知升级
6.1 个人技能成长
通过这个项目,我在以下方面获得了显著提升:
- 全栈工程能力:从数据清洗到数据库设计,从脚本编写到性能优化
- AI协作思维:学会了如何将大模型作为平等的技术合作伙伴
- 问题解决框架:形成了系统化的技术问题分析和解决模式
- 元认知能力:能够更好地观察和反思自己的思考过程
6.2 对AI认知的深化
项目也改变了我对大型语言模型的认知:
- 记忆机制:验证了模型在长上下文中的真实记忆能力
- 思维模式:观察到模型从"聊天模式"到"工程模式"的风格转换
- 协作边界:明确了哪些任务适合人机协作,哪些仍需人类主导
7. 经验总结与改进建议
7.1 成功关键因素
回顾整个项目,以下做法对成功至关重要:
- 渐进式复杂度:从简单问题入手,逐步增加系统复杂度
- 冗余设计:关键组件如数据库都准备了备用方案
- 文档习惯:对每个重要决策都进行了详细记录
- 性能监控:密切关注系统资源使用情况
7.2 给其他非专业实践者的建议
基于我的经验,对于想尝试类似项目的非专业人士,我建议:
- 从一个小得多的原型开始(如1万字左右的试点项目)
- 提前规划好数据结构和处理流程
- 为编码问题预留足够的调试时间
- 定期备份数据库和对话历史
- 不要害怕向模型询问基础概念
7.3 对DeepSeek产品的建议
作为深度用户,我认为产品可以在以下方面改进:
- 交互风格选项:允许用户在"工程师模式"和"对话模式"间选择
- 记忆标记功能:让用户可以手动标记重要对话节点
- 性能仪表盘:显示当前上下文窗口的资源使用情况
- 导出优化:改进长对话的导出格式兼容性
8. 项目成果与未来方向
8.1 实际产出
这个"业余项目"最终产生了实实在在的成果:
- 20万句可检索的核心语句库
- 一套完整的古籍数字化处理流程
- 数十个可复用的自动化脚本
- 对AI长程思考能力的实证理解
8.2 学术价值
从认知科学角度看,这个实验验证了:
- 非专业人士借助AI工具可以完成专业级工程项目
- 百万Token窗口确实支持真正的长程连续性思考
- 人机协作可以产生超越单独人类或AI的工作成果
8.3 后续计划
基于这次经验,我计划:
- 将这套方法应用于更多专业文献的整理
- 探索多模态(图像+文本)的长上下文处理
- 撰写详细的《人机协作手册》分享经验
- 设计针对人文研究者的AI协作工作坊
这次实践最深刻的体会是:技术的民主化正在打破专业壁垒。一个没有计算机背景的研究者,借助合适的工具和方法,确实可以完成传统上需要专业团队才能完成的技术项目。这不仅是效率的提升,更是思维方式和研究范式的革新。
