Лого на 91. НЕГ „Проф. Константин Гълъбов“

Избираем модул · Урок 16

Съхраняване на разговорите

Схема за разговори и съобщения, свързване с източниците, обратна връзка от потребителя и срокове на съхранение.

Защо изобщо се пази

Услугата не помни нищо (11. клас, урок 24). Ако искате потребителят да продължи разговора утре, историята трябва да е у вас. Но паметта е само едната причина.

  • Продължаване на разговор и връщане към стар.
  • Измерване: колко въпроса получава системата и на колко отговаря добре.
  • Отчет за разхода по потребител и по функция.
  • Материал за набора от тестове — реалните въпроси са най-добрите тестове.
  • Разследване, когато нещо се обърка.

Схемата

CREATE TABLE razgovori (
    id            SERIAL PRIMARY KEY,
    potrebitel_id INT NOT NULL REFERENCES potrebiteli(id),
    zaglavie      TEXT,
    zapochnat_na  TIMESTAMP DEFAULT NOW(),
    posleden_na   TIMESTAMP DEFAULT NOW()
);

CREATE TABLE sabshtenia (
    id            SERIAL PRIMARY KEY,
    razgovor_id   INT NOT NULL REFERENCES razgovori(id) ON DELETE CASCADE,
    rolya         TEXT NOT NULL CHECK (rolya IN ('user', 'model', 'system')),
    tekst         TEXT NOT NULL,
    model         TEXT,
    versia_prompt TEXT,
    tokeni_vhod   INT,
    tokeni_izhod  INT,
    ms            INT,
    sazdadeno_na  TIMESTAMP DEFAULT NOW()
);

CREATE TABLE sabshtenie_iztochnici (
    sabshtenie_id INT NOT NULL REFERENCES sabshtenia(id) ON DELETE CASCADE,
    parche_id     INT NOT NULL REFERENCES parcheta(id),
    blizost       REAL,
    PRIMARY KEY (sabshtenie_id, parche_id)
);
РешениеЗащо
Отделна таблица за съобщениятаразговорът расте; един ред на съобщение е естествената форма
rolyaсъщите роли, които се подават на модела — историята се възстановява директно
Токени и време на съобщениеразходът се смята по потребител, по ден и по функция без допълнителна работа
Таблица за източницитевръзка много към много между отговор и използвани парчета — позволява после да се провери на какво е стъпил отговорът
ON DELETE CASCADEизтриването на разговор трябва да отнесе съобщенията му

Възстановяване на историята

При ново съобщение се четат последните N съобщения от разговора и се подават на модела. Цялата история рядко се подава — прозорецът е ограничен, а и всеки токен струва.

  1. Взимат се последните 10–20 съобщения.
  2. Ако разговорът е дълъг, по-старата част се заменя с обобщение.
  3. Системното указание се добавя винаги, независимо от историята.
  4. Контекстът от документите се добавя за текущия въпрос, не се пази в историята.

Обобщаване на стара история

Когато разговорът мине определена дължина, старите съобщения се заменят с абзац „дотук потребителят пита за X, установено е Y“. Обобщението се пази в таблицата с роля system.

Обратна връзка

Обратна връзка от потребителя

Оценка на конкретен отговор — палец нагоре или надолу, звезди, кратък коментар.

ALTER TABLE sabshtenia
    ADD COLUMN ocenka SMALLINT CHECK (ocenka IN (-1, 1)),
    ADD COLUMN komentar TEXT;
  • Двете стойности (полезно / безполезно) събират много повече отговори от петстепенна скала.
  • Отрицателните оценки са най-ценният източник за нови тестови случаи.
  • Показвайте въпроса и отговора при преглед на оценките — без тях числото не значи нищо.

Лични данни и срокове

Какво съдържат записите

Потребителите пишат каквото им дойде — включително имена, адреси, здравна информация. Разговорите са лични данни и се третират като такива.

Мерки

  • Определен срок на съхранение и задача, която трие по-старото.
  • Достъп само за тези, които наистина имат нужда.
  • Възможност потребителят да изтрие свой разговор.
  • Обезличаване при използване на разговорите за анализ.

Изтриването трябва да работи

Ако предлагате бутон „изтрий разговора“, той трябва да трие наистина — включително от журналите и резервните копия според политиката ви. Половинчатото изтриване е по-лошо от липсата на бутон.