演示视频

范围

适用范围

本文档明确“aiWithDoc”的开发需求，详细阐述了本系统的外部接口需求、系统功能、性能需求、技术需求以及软件运行环境等。编写此需求规格说明书是为了使使用人员和开发人员对所开发的平台有一致的理解。通过阅读此文档开发人员可以了解当前业务的具体需求和要实现的主要功能，使用人员通过阅读此文档可以确认开发人员对其业务需求的认识是否正确并对系统要实现功能有初步的了解。

标识

软件产品名称

本软件产品名称为“aiWithDoc”管理平台。

设计约束

1） 硬件运行环境

PC服务器或云服务器，根据扩展需要，可部署在1至n台服务器上。

2） 操作环境

Windows 7/8/8.1/10以上操作系统（支持32位和64位），

浏览器（搜狗浏览器，FireFox，Chrome，IE 10以上版本）。

3） 软件环境

x64位的JDK 8或OpenJDK、Python 3.9、科学上网工具、服务器端操作系统可使用linux内核操作系统或Windows(建议使用CentOS 7以上版本)、客户端开发采用浏览器端技术进行开发。

4） 网络环境

局域网或广域网环境中。

5） 国际化

无国际化要求，软件界面及日志信息使用中文进行展示。

术语和缩略词

1) B/S：Browser/Server，浏览器/服务器模式

2) DBMS：DataBase Management System，数据库管理系统

3) IP：Internet Protocol，Internet协议

4) TCP：Transimission Control Protocol，传输控制协议

5) SSL：Secure Sockets Layer 安全套接字协议

概述

aiWithDoc可以帮助企业或个人进行文档管理，文档检索，文档学习等等。本项目1.0版本主要起到一个抛砖引玉的作用，互联网上大量的云服务存在文档安全问题。在公司内部或个人电脑上部署一套aiWithDoc，可解决很多关于电子文档的问题。未来考虑在后续版本中，添加摘要，图片内容识别，多文档对话，总结等等功能。

本软件采用B/S架构，人机交互界面采用浏览器端技术开发，aiWithDoc主要功能包括用户管理，角色管理，菜单管理，权限管理，文档管理，文档训练，文档对话等功能。

业务核心点

经过仔细研判，结合当前的现状及未来的业务扩展逐步梳理出系统的以下几个核心点：

1. 文档管理：让用户能够方便的上传电子文档。

2. 文档训练：把文档切片进行向量化存储。

3. 文档对话：让用户方便的与文档进行对话。

引用文档

1) 《可研分析》

需求规定

外部接口需求

目前大语言模型提供的都是云服务，且都是通过key进行认证，本项目中使用的LLM为OpenAI提供。

OpenAI API

1. "https://api.openai.com/v1/completions" 文本生成接口

2. "https://api.openai.com/v1/chat/completions" 对话接口

3. "https://api.openai.com/dashboard/billing/credit_grants" 账单接口

由于OpenAI目前禁止国内访问，因此需要用到科学上网工具，代码中配置代理，如下：

os.environ["http_proxy"] = "http://localhost:10809"   
os.environ["https_proxy"] = "http://localhost:10809"

内部接口需求

目前市场上进行AI相关应用开发的语言主要是Python和NodeJS，有非常多的第三方包提供支持，如果使用Java进行开发，则会存在很多重复造轮子的问题，关键是有些轮子也不好制造。因此本项目的中间层采用Python开发，通过Java调用对应的接口进行相关工作。

1. “http://localhost:8123/upload" 文件训练接口

2. “http://localhost:8123/chat" 文件对话接口

功能需求

功能描述

aiWithDoc从总体功能划分主要包括用户管理，角色管理，菜单管理，权限管理，文档管理，文档训练，文档对话等功能。

业务流程

首先通过系统管理设置相关的组织机构，人员，角色分配对应的权限；其次建立库房，初始化库存数据，建立相关账目的基础数据（例如账本，科目，产品，往来单位等等），

网络拓扑

本系统采用B/S架构，服务器采用自有服务器或者其他云服务器，未来可根据具体需求动态扩展。使用者需要在有网络的情况下进行访问，如果自有服务器在局域网内，则需要用到地址映射相关技术。网络拓扑图如下：

系统页面

系统页面由顶部logo及通知栏、左部菜单栏、中部内容区域栏等三部分组成。目前市面上的管理系统大体都是该页面布局方式，这种布局用户已经形成习惯，因此本系统页面布局还是采用该方式。下图为UI示意图：

功能模块

系统管理

系统管理为本系统的基础功能模块，例如字典管理，字典分类管理，日志管理，菜单管理，角色管理，人员管理等等都属于系统管理模块下。

字典分类及字典管理是为了方便系统日后的扩展以及系统的相关统计功能，理论上所有需枚举的数据都应当放入到此模块中进行管理。

日志管理按照类别分又可分为登录日志、操作日志及错误日志，日志的追踪是运维系统的核心手段之一，需要对日志进行分类分级。

菜单管理也是系统管理的常规功能之一，随着时间的推移及业务的演进，未来将会纳入各种功能点到系统当中，因此功能菜单应该是灵活可配的。菜单管理的目的就是方便日后功能的扩展，菜单管理应该采用树型结构方式，基本属性字段应该有菜单名称，url，是否可用，描述，顺序，编号等等字段。

角色管理

系统实际运行中，会存在各类人员使用本系统，随着系统的不断升级，角色可能会进行调整，因此需要对角色进行管理。角色和人员应该是多对多的关系。角色的属性字段包括角色名称，顺序，描述。另外角色管理功能下应该有人员绑定功能。

人员管理

使用本系统的人员的管理，属性字段应该有姓名，性别，工号，账号，密码，手机号，email，状态，入职时间等等。

权限管理

为满足不同的人员或角色使用不同的功能点，因此需要对系统的菜单进行权限分配。权限分为数据级权限和菜单级权限。菜单级权限相对比较好实现，数据级权限要看做到什么粒度，本系统暂时不考虑数据级的权限实现。

菜单级权限：简单讲就是是否能使用该功能菜单。

数据级权限：此权限管理比较复杂，例如张三能看见武汉的数据但不能看见北京的数据。

操作级权限：例如有些人员只能看相关数据而不能修改相关数据。

日志管理

此处管理的日志是用户使用系统时所产生的操作型日志，该功能点主要是方便相关人员查询使用本系统的操作记录，不建议提供删除的功能。如果日志量非常大，需要考虑日志的存储，备份，检索问题。

文档管理

文档上传

此功能点是用来管理需要进行对话的文档，支持word,txt,pdf,md格式。同时可以删除和修改相关的文件附属信息。

文档训练

要向与文档进行对话，目前看有二种方式，一种是使用模型的微调功能，这需要消耗大量的token同时所有的相关数据，都需要存入到LLM的服务器中。另外一种方式就是把文档切片进行向量化，所谓训练就是指向量化，但如果想要效果更好，可以在训练的同时进行语义分析、关键字提取、摘要性总结等等，后期的版本需求中将会考虑更完善的功能。

文档对话

本项目的核心功能，通过调用中间层的接口实现与word文档，pdf文档，文本文档，MD文档进行对话的功能。

性能需求

主要是技术选型上应该可以满足未来性能扩展的需求，尽量使用成熟的相关技术框架。例如内存数据库，消息队列，前后端分离等等。

根据前期的讨论，本系统拟采用前后端分离技术，spring boot框架技术，redis内存数据库技术，Ngnix集群部署技术，mysql数据库主从配置技术等满足现阶段的性能需求。未来如果性能出现瓶颈点，可考虑通过微服务的方式把更细节的功能集群化部署。

安全和保密需求

本项目使用时需通过https协议，保证数据传输过程中进行加密数据。另外从管理角度看，相关的参与人员需要签署相应的保密协议。

其他硬件的安全，网络的安全，操作系统的安全，中间件的安全等等可以考虑用云平台提供的服务。

可靠性需求

通过集群部署方式保证平台的稳定性，另外如果需要保证非常高级别的可靠性，则考虑增加相关的硬件，同时需把平台部署到不同地点的云节点上。