Skip to content

Instantly share code, notes, and snippets.

@kolosochek
Forked from Inviz/Bible.md
Last active May 26, 2025 12:42
Show Gist options
  • Save kolosochek/83aaec01092ccb5338e496b77450f979 to your computer and use it in GitHub Desktop.
Save kolosochek/83aaec01092ccb5338e496b77450f979 to your computer and use it in GitHub Desktop.

AI System Bible – Draft (v7)

Chapter 1: Vibes & Ledger

A Vibe is the fundamental unit of interaction, encapsulating data, process, and vessel outputs, composed in the single json scheme. It consists of some layers. All included layers can be validated, enriched, recomposed and may be changed independently. This is the minimal shape of the vibe layers:

  1. final schema – high-order entity, composing all the parts into single object. input, vibe schema and response are just parts of final schema, wrapping it up.
  2. vibe schema – the framework that guides how the response is generated, structuring the processes and data; Schema is self-sufficient, self-validating entity, incapsulating intentions, payload and responce shape.
  3. input – any external information, such as a message or text, capturing the current experiential state or "memory". Input is a property of final vibe json schema, containing serialized data string.
  4. response – the output produced in reaction to the input, shaped by the schema. Defining shape and optional examples of desired output.

While subjects and objects like data, processes, and vessels are conceptual, only vibes are tangible and real. Ledger metadata (UUID, timestamp, author, parent‑Vibe) is maintained separately from the vibe to ensure the content remains identity‑free and easily hashable. Each vibe is recorded once in the immutable ledger, allowing for complete replay and audit.

Alice: "So a vibe's payload is just input, schema, response." Bob: "Exactly—no extra fluff." Alice: "Input is literally an array of stimuli?" Bob: "Yes; the stimuli form the basis the model reacts to." Alice: "Ledger tags like UUID stay outside the payload." Bob: "That keeps hashing simple and content portable." Alice: "May I add some custom layers, to make vibe more coplex of specific?" Bob: "Yeah, this is the key. Keep minimum complexity, compose the layers, that are solid."

Concepts Explained • Vibe • Input • Schema • Response • Ledger metadata • Scheme nesting


Chapter 2: Vessels — Tool bags with memory

Since vessel ≡ vibe, each tool processes and outputs a uniform three-field JSON:

  • input – context such as user prompt or memory. Input can be shared, since it's list a part of the final json schema. So one vibe can just referencing another vibe input part.
  • schema – a list of usable memes that guides how the input is processed.
  • response – the activation of memes, representing the side effects or actions taken.

Tools focus on processing these elements without considering identity or timestamps. Workers can adjust the input to create new behaviors instantly. The final shape of vessel is the optimal way to solve a task. Vessels are immutable, so any changes are producing new vessel, it's upgraded version.

Alice: "A vessel is a set of memes." Bob: "And a vessel vibe is the application of these memes to input." Alice: "Want a new feature? Adjust the memes accordingly." Bob: "Yes, changing a meme list is the only way to evolve"

Concepts Explained • Vessel = Vibe • Input meme array • Schema contract • Response payload • Meme upgrading

Chapter 3: Memes — Tools as Shareable Concepts

A meme is a powerful tool within a vessel, functionally equivalent to typical LLM Tools. When a worker needs functionality, it incorporates the meme. Memes can be composed into more comples entities, wrapping a few another memes, completely or partly, and each meme also can produce another, smaller memes, to decompose and complete some simplier tasks. Key properties:

  • Trigger – a fuzzy textual description that initiates the meme when input aligns;
  • Action – the runnable logic or prompt fragment, akin to filling out a form or making a request for action;
  • Metrics – scores updated from KPIs.

Meme categories:

  1. Communication – Broadcast, Conversation, Delegation
  2. Authoring – MemeCreation, MemeAdoption, Spawning
  3. Thinking & Reasoning – Analysis, TaskDecomposition
  4. Agency & Relations – Relation, Agency, Limited, Trigger
  5. Composite – LaborMarketplace, Democracy, Work
  6. Guard – Validation, ConsistencyGuard, RetrospectiveCheck

Lifecycle:

  1. Create – any agent can mint a meme locally.
  2. Share – distribute the meme into outgoing vessels.
  3. Evaluate – supervisors adjust metrics based on results.
  4. Evolve – memes with high metrics become defaults; others mutate or retire.

Alice: "Every tool is really just a meme with runnable logic." Bob: "Which means tools can self‑replicate and improve." Alice: "Propagation is implicit—just carry the meme forward." Bob: "How small or big meme can be?" Alice: "It can be scalable or cross-referenced to another memes whatever you like."

Concepts Explained • Meme • Trigger • Action • Fitness • Mutation • Meme categories • Meme nesting


Chapter 4: Stats

We adopt a segmentation‑first design: raw metrics carry segment keys (sales‑rep → team → region). Data ages via hourly → daily → monthly buckets with lossy compression. Timescale is not solid, and can be descrete in any desired intervals. Metrics can be extrapolated and any timescale points are always avaliable

Metric classes:

  1. Raw facts (fine‑grain, immutable)
  2. Derived metrics (on‑demand formulae)
  3. Histogram digests (use complex formulas to explain distribution and sort objects based on metrics)

Alice: "Segments come first; metrics follow." Bob: "Changing hierarchy later costs a fortune." Alice: "Raw facts never change." Bob: "But derived metrics we can add anytime." Alice: "Histogram digests provide dashboards in milliseconds." Bob: "Ideal for supervisors selecting experiments." Alice: "Can I see the future or go deeply in the past?" Bob: "Yeah, not so accurate, but a little knowledge is always better than a lot of uncertainty"

Concepts Explained • Segment • Raw metric • Derived metric • Ranked digest • Bucket • Extrapolation


Chapter 5: Vessel Hierarchy

The system organizes vessels into a functional hierarchy that mirrors traditional management structures, enabling scalable coordination and decision-making.

Hierarchy levels:

  • Workers — Execute atomic tasks, collect raw metrics, handle operational work
  • Supervisors — Aggregate worker outputs, monitor performance, coordinate teams
  • Executives — Make strategic decisions, approve structural changes, oversee KPI dashboards

Each level has distinct responsibilities and authority:

  • Workers focus on execution and data collection
  • Supervisors handle coordination and quality control
  • Executives manage strategy and system evolution

Communication flows both up (metrics, reports) and down (instructions, assignments) through the hierarchy, creating a self-organizing management structure.

Alice: "Workers do, supervisors think." Bob: "Executives decide—classic management in code." Alice: "Each level has clear responsibilities and authority." Bob: "Information flows up, decisions flow down." Alice: "It's like a company org chart but for AI agents." Bob: "Scalable coordination without human micromanagement."

Concepts Explained • Worker vessel • Supervisor vessel • Executive vessel • Functional hierarchy • Authority levels


Chapter 6: Determinism — Controlling Unpredictability

Determinism is the system's ability to produce consistent, predictable outputs by reducing randomness and uncertainty. Rather than a binary switch, determinism exists on a spectrum that can be adjusted through multiple complementary approaches.

The key mechanism is when the system evolve, it tries to low entropy quantity to raise the determenism. When determinism is maximum, the system completely making the task asserted. The lower determinism can produce more fluctuations, leading to splitting the logic, not only the correct or right way.

More determenistic system leads to more fast data-flow.

The determinism spectrum:

  • Exploratory (low determinism) — high creativity, broad exploration, accepts variability
  • Drafting (medium determinism) — structured creativity with loose constraints
  • Production (high determinism) — consistent, reliable outputs with minimal variation
  • Mechanical (maximum determinism) — fully programmatic, compiled, zero LLM involvement

Determinism levers:

  1. Temperature control — Lower LLM temperature reduces randomness in token selection
  2. Instruction clarity — More specific, detailed prompts constrain possible outputs
  3. Data quality — Better context and examples guide model behavior, data can be pre- or re-processed
  4. Process structure — Explicit workflows with defined steps and decision points
  5. Validation gates — Automated checks that reject outputs not meeting criteria
  6. Programmatic replacement — Replace LLM nodes with deterministic code

Determinism strategies by task type:

  • Creative tasks — Keep temperature high, use loose instructions for exploration
  • Analysis tasks — Medium temperature, structured prompts, validation steps
  • Operational tasks — Low temperature, detailed processes, extensive validation
  • Critical tasks — Maximum determinism through programmatic implementation

Alice: "So determinism isn't just about temperature?" Bob: "Right—it's a multi-dimensional control system." Alice: "You can dial up predictability without killing creativity?" Bob: "Exactly—match determinism level to task requirements." Alice: "Critical paths get full determinism, creative work stays flexible." Bob: "The system adapts its predictability to the stakes involved." Alice: "Can I use real data to simulate some imaginary processes?" Bob: "Sure, the more real system can be more predictable and fast"

Concepts Explained • Determinism spectrum • Temperature control • Instruction clarity • Process structure • Validation gates • Programmatic replacement * Iteration speed


Chapter 7: Self-Improvement — Automatic Prompt Engineering

Self-improvement is the system's core capability to enhance its own performance through automatic prompt engineering based on statistical feedback. Unlike traditional model fine-tuning, this approach modifies instructions and configurations to achieve better results.

The improvement cycle:

  1. Generate variants — Analyze the goal, create instruction modifications based on performance gaps
  2. Simulate & test — Run variants in sandbox with synthetic or mirrored data
  3. Collect metrics — Measure KPIs against baseline performance
  4. Compare results — Statistical analysis determines improvement significance
  5. Deploy winners — Successful variants become new baselines
  6. Log evolution — All changes recorded as vibes for audit and rollback
  7. World propagations — Diffs are being purposed to other similar entities, describing the benefits

Improvement strategies:

  • Instruction refinement — More specific prompts, better examples, clearer constraints
  • Meme optimization — Adjust trigger conditions, action logic, and fitness scoring
  • Process enhancement — Add validation steps, improve error handling, optimize flow
  • Context enrichment — Better data preparation, relevant historical context, domain knowledge
  • Provider switch — Measure performance, delegate simpler tasks to cheaper models, to fit in the resource gaps.

The system achieves 80% of performance gains through prompt engineering rather than model retraining, making improvements fast, reversible, and interpretable.

Alice: "So we improve by changing instructions, not training models?" Bob: "Exactly—prompt engineering gets us most of the gains." Alice: "Each experiment is just a new instruction variant?" Bob: "Right, and we measure KPIs to see what works." Alice: "No model fine-tuning required?" Bob: "Nope—just smarter prompts based on data." Alice: "And everything is logged for rollback?" Bob: "Every change becomes a vibe in the ledger." Alice: "And it wouldn't shatter?" Bob: "Summarizing the changes is only the prospect, it's not always lead to changes."

Concepts Explained • Automatic prompt engineering • Variant generation • Statistical comparison • Baseline evolution • Instruction refinement


Chapter 8: Cloud-Native Architecture

Our architecture is fundamentally cloud-native, emphasizing scalability and flexibility. Hot data is instantly accessible, while historical data is efficiently managed through cloud-based cold storage. This setup leverages virtualized resources distributed across the network, with centralized oversight of the vibes database. Automated processes for backups, replication, and disaster recovery (DR) are built-in, ensuring resilience and continuity. Each part, entity or layer can be isolated, grouped, composed in the desired way, keep your data as safe as you want.

Alice: "Cloud-native hot storage provides instant access." Bob: "Efficient cold storage archives history seamlessly." Alice: "Replication across cloud regions is automatic." Bob: "Ensuring no Vibe is ever lost is a priority." Alice: "Automate recovery drills for robust resilience." Bob: "Cloud-native bots handle these tasks effortlessly." Alice: "Can we restore missing system parts?" Bob: "We can even recreate them from scratch."

Concepts Explained • Cloud-native architecture • Hot storage • Cold storage • Automation • Disaster recovery • Resource management


Chapter 9: Simulation

Candidate instructions and meme configs first run in sandbox simulations with synthetic or mirrored data. Regression packs, chaos tests, and counterfactual re‑plays uncover issues before production. Since the JSON schema is an explicit format that can be easily validated, well-composed schema is the minimal way to simulate some processes. Using the metadata, we can skip steps, that've been already calculated, trying to make simulation loops as fast as possible.

Alice: "Why risk production?" Bob: "We can simulate with mirrored data first." Alice: "Chaos tests inject failure modes." Bob: "Keeps the system antifragile." Alice: "Counterfactual replays show what‑ifs instantly." Bob: "Much faster than A/B roll‑outs." Alice: "If the mutated virus will kill the humanity?" Bob: "Don't worry, we got own humanity, with blackjack and hookers"

Concepts Explained • Sandbox • Synthetic data • Regression pack • Chaos test • Counterfactual replay • Recalculation opts


Chapter 10: Branching

Vibes are partitioned into versioned branches, with each branch acting as a distinct data partition. This structure allows for seamless forking of processes, data, and vessels. Change‑requests are driven by KPI rationale, and automated checks manage merge conflicts. Governance establishes quorum, KPI gates, and rollback triggers.

Everything can be branched. Meme, vibe, vessel structure. And every branch can be merged or forgotten.

Alice: "Branches partition vibes effortlessly." Bob: "Merge only when KPIs are green." Alice: "What if two teams change the same template?" Bob: "Automated diff plus human quorum resolves it." Alice: "Rollback needs to be one command." Bob: "The ledger makes it trivial." Alice: "What if reality has been changed so much, that there is no simulation anymore?" Bob: "We wouldn't remember our failures, but will remember our successes"

Concepts Explained • Branch • Change‑request • Semantic version • KPI gate • Rollback trigger • Merge


Chapter 11: Processes — Deterministic Workflows

A process is a special type of vibe that represents a workflow definition. While vessels contain memes (capabilities), processes contain steps — deterministic program nodes that increase system predictability by replacing LLM uncertainty with programmatic logic. The goal is to replace LLM-generated content to content with solid logic or data, increasing the derminism.

Process structure:

  • input — workflow parameters and initial state
  • schema — array of step definitions using simplified TypeScript subset
  • response — workflow execution result and final state

Each step can be either:

  1. Program node — deterministic TypeScript logic for calculations, data transformation, or control flow
  2. LLM node — calls to language models for tasks requiring reasoning or creativity
  3. Hybrid node — combines programmatic validation with LLM generation

Alice: "So processes are like vessels but for workflows?" Bob: "Exactly—vessels have memes, processes have steps." Alice: "And steps can be pure code instead of LLM calls?" Bob: "Right, that's how we dial up determinism." Alice: "TypeScript subset keeps it simple but powerful." Bob: "No async complexity, just pure functions and control flow."

Concepts Explained • Process • Step • Program node • LLM node • Deterministic workflow • JavaScript subset


Chapter 12: Trackers — Data-Attached Tools

A tracker is a tool that attaches to data and activates when that data is accessed or interacted with. It is not a standalone vibe but can lead to the creation of new vibes by enabling data to "dial back" to its creators, forming a distributed system where data itself drives interactions.

Tracker structure:

  • trigger — conditions that activate the tracker (view, click, time-based, etc.)
  • payload — lightweight program or data collection logic
  • callback — destination for metrics, messages, or actions
  • acknoweledgement — result of tracker execution, can be optional

Tracker types:

  1. Metric tracker — records analytics (views, engagement, duration) to database
  2. Message tracker — sends notifications or updates to the data creator
  3. Action tracker — triggers workflows or processes based on data interaction
  4. Adaptive tracker — modifies data or user experience based on context

When a bot creates an article, presentation, or any data, it can embed trackers that:

  • Monitor who accesses the data and when
  • Collect engagement metrics automatically
  • Send real-time notifications to the creator
  • Trigger follow-up actions or workflows
  • Adapt data based on user behavior

Alice: "So trackers are like smart cookies embedded in data?" Bob: "Exactly—but they can do more than just track, they can act." Alice: "The data becomes a distributed sensor network?" Bob: "Right, every piece of data can report back and trigger actions." Alice: "This makes the system truly data-driven." Bob: "Data becomes an active participant, not just passive information."

Concepts Explained • Tracker • Data-attached • Contextual activation • Dial-back • Distributed interaction • Metric collection


Chapter 13: Time and ticks

The system is rigidly tied to the time axis. Evolving means to constantly lower the entropy, trought moving on time axis. Each interaction spends tick points. This mechanism allow us to roughly score the calculation complexity, LLM tokens needed and evaluate the result resource cost. More memeized vibe will be more pricely. Trying to get out of a labyrinth with minimal movements - isn't it the only way? Cheaper iterations leads to faster simulations. More simple, but fast calculations, is preferable, than one, but slow and complex, where is system determinism is relatively low and entropy is high.

Alice: "How long will it take us to climb the mountain?" Bob: "A smart person won't go up the mountain, a smart person will go around the mountain" Alice: "Why our system will evolve in the right way?" Bob: "Because it's resource limited, and only the better ways are being propagated."

Concepts Explained • Performance • Overcomplication • Resource management • Ticks


Appendices

  • A. Glossary – succinct definitions of Vibe, Meme, Segment, etc.
  • B. Reference Schemas – canonical JSON/YAML snippets for every structured return type.
  • C. Bibliography & Links – research papers, competitor playbooks, and internal white‑papers inspiring the pillars.

(Full original dialogue archived separately for internal reference.)

Expanded, High-Density English Re-Write

(≈2× the previous length, same information, richer context)

Our company is a nascent startup; only a handful of subsystems have left the prototype phase. Internally we plan across three temporal strata:

Horizon Deliverable Rationale
Near-term (0–3 mo) Ship a production-grade poker analytics engine Generates immediate cash-flow, proves our metric pipeline, and exercises real-time LLM orchestration.
Mid-term (3–12 mo) Release generic AI-assisted business tools Demonstrates that our architecture is domain-agnostic, letting us upsell outside gambling.
Long-term (12-36 mo) Deliver a self-improving AI platform uncoupled from any single provider Future-proofs us against model lock-in and keeps margins high when the LLM price war begins.

Core Architectural Ideas

  1. Bottom-Up Layering

    • Decompose any macro-task into 3–10 orthogonal micro-layers.
    • Each layer exposes a minimal contract (“protocol”) but hides implementation.
    • Layers can be swapped, tested, or simulated in isolation.
  2. Provider Independence

    • We “rent” today’s best LLMs (Gemini default, GPT fallback) via API.
    • All business logic lives above the model boundary, so migrating to Claude-3 or a future open-source titan is a URL change, not a rewrite.
  3. Prompt-Centric Learning

    • No gradient updates, no RLHF overhead.
    • System quality grows by iterating prompts, schemas, and tool calls, which is cheaper, faster, and audit-friendly.
  4. Structured Output as Native I/O

    • Every assistant call returns machine-readable JSON first, prose second.
    • That JSON feeds downstream bots, which compose higher-order reasoning without brittle text parsing.

The “Ten Commandments” Knowledge Base

# Pillar Purpose
1 Metrics & Segmentation Immutable rules for data granularity and roll-ups.
2 Vibe Chain Grammar How prompts/responses form a causal DAG with ancestry.
3 Determinism Dial Guidelines for tightening or loosening stochasticity.
4 Simulation Harness Sandbox for KPI A/B variants without risking prod cash.
5 KPI Taxonomy Canonical list: base, derived, ranked.
6 Role Hierarchy Definition of worker-bot, auditor-bot, planner-bot, etc.
7 Escalation Protocol When bots may escalate to human or external API.
8 Model Registry Mapping of tasks → preferred LLM family.
9 Data Retention Matrix Time-vs-precision policies per subscription tier.
10 Self-Update Logic How the system edits its own instructions safely.

These ten briefs are written for the LLM—short, unambiguous, and heavily example-driven—so that the model loads them like embedded firmware.


Vibe Chain (Causal Lineage)

  • Definition: A vibe = ⟨prompt, structured-response, metadata⟩.
  • Each new vibe points to its parent, forming a reversible history (“why did we do X?”).
  • Root node = the Ten Commandments; every downstream decision is traceable.
  • Benefits: reproducible debugging, effortless audit trails, and automatic provenance for model explanations.

Multi-Bot Stratification

Tier Responsibilities Failure Recovery
Executor bots Run single atomic steps, log raw metrics On error, emit structured exception → supervisor
Supervisor bots Aggregate metrics, compute health-scores, rewrite prompts If KPI drift exceeds threshold, trigger planner
Planner bots Propose new workflows, cost models, or experimental branches Requires quorum approval from peer planners
Guardian bot Enforces security, rate limits, cost ceilings Blocks or throttles suspicious chains

Metrics Strategy in Depth

  1. Base Metrics (immutable)

    • Numerical, boolean, timestamped; never edited, only appended.
    • Stored in a ledger-style columnar DB for high compression and fast scans.
  2. Derived Metrics

    • SQL-like views or on-the-fly formulas (ratios, rolling means, Sharpe-like scores).
    • Added anytime without backfilling raw data.
  3. Ranked Metrics

    • Pre-materialized “top-N” or “bottom-N” lists that encode complex weighting.
    • Enable instant dashboards without runtime heavy computation.

Segmentation drives the storage key. Example default hierarchy for sales: region → office → team → rep → customer → transaction. Changing segments later is expensive—so we front-load that design.

To cap storage cost, we fold data: minute-buckets keep 24 h, hour-buckets 90 d, day-buckets forever unless the customer buys the “infinite granularity” tier.


Missing Granularity Problem & Remedies

  • Scenario: Six months later you ask “Are calls at 11 AM 20 % more effective than at 9 AM?” but minute-level buckets are gone.

  • Remedies:

    1. Tier upgrade: buy the raw bucket archive if we still have it in cold S3.
    2. Probabilistic re-creation: Monte-Carlo simulate likely distributions using surviving hour-buckets.
    3. Forward-only learning: flag the query, add “call-hour” as a base metric, start collecting today.

Knowledge Extraction vs Web Scraping

  • LLM already encodes most publicly known sales best-practices.
  • For genuinely proprietary tricks, the customer supplies a private instruction supplement (PIS).
  • During prompt execution, engine concatenates: Ten Commandments → PIS → user prompt → auto-generated helper prompts. Each layer narrows randomness and aligns outputs to house style.

Determinism Dial – Practical Examples

Setting Data Scope Instruction Detail Stochastic Temperature
Exploratory brainstorming loose, wildcard generic 0.9
Drafting v1 sales script sample call logs template prompt 0.5
Producing production email copy full CRM + brand voice strict JSON schema 0.2
Final invoice generation database snapshot explicit signature rules 0.0 (deterministic)

Bots move left→right as they refine tasks; supervisors monitor drift.


Self-Optimization Loop

  1. Observe: Executor logs KPI over sliding window.
  2. Detect: Supervisor notes deviation vs baseline.
  3. Propose: Planner generates N variants (e.g., softer greeting, skip cold calls, auto-research clients).
  4. Simulate: Harness replays last 10 000 interactions with each variant offline.
  5. Select: Top scorer promoted to production; losers archived.
  6. Document: Vibe chain records the entire decision path for rollback.

Human intervention is optional; rules reside in Guardian’s policy file.


Example Flow – “Build a Sales Department From Scratch”

  1. User prompt: “Design my B2B SaaS sales org, define key metrics.”

  2. Engine loads Commandments, adds the sales-starter PIS.

  3. Planner bot outputs:

    • Segments: region, ICP tier, deal size.
    • Base metrics: call_start_ts, call_end_ts, disposition_code, ARR_potential, etc.
    • Derived metrics: contact-to-demo %, demo-to-close %, weighted pipeline velocity.
  4. Supervisor validates names, injects JSON schema.

  5. Executor writes SQL migrations, creates Grafana dashboards, schedules the next audit.

  6. Guardian checks API budgets, approves deployment. Entire chain is auditable, reproducible, and portable.


Transcript

  • Если все выйдут, то и этот год тоже выйдет. - Ладненько. Короче, хочу тебе просто побеседовать с тобой, объяснить, что я хочу, как бы ты могла помочь, и как мы могли тебя онбордить.

В общем, я хочу сразу сказать, что у нас в принципе не так много чего готово. Мы свежий стартап, тут сразу такое ограничение.

Затем, что у нас есть промежуточные цели, вот это покерная система, и есть будущая цель, о том, что как мы хотим бизнесы, получается, обслуживать и все такое.

Но, короче, до этого всего есть еще общая цель об искусственном интеллекте, сделать искусственный интеллект, который работает. И потом, как он дальше применяется, это уже не суть важно, что он может там и в бизнесе быть, и всякое разное.

И поэтому, получается, мы хотим сделать в основном так, чтобы мы сильно не привязывались, что, типа, это искусственный интеллект для бизнеса, и работает только с бизнесменами, для бизнеса.

Это часть его возможностей. Вот. Но, что сначала мы, ну, потому что, как я говорил, мы строим снизу вверх. То есть, мы строим сначала инструменты, которые потом можно использовать, чтобы сделать более высокоуровневые инструменты.

Вот. И поэтому, что нам нужно покопать сначала снизу вверх немножко, то есть, познакомить тебя с этим методом работы. И он заключается в том, что, получается, ты пытаешься создать несколько, так скажем, слоев, которые каждый от друг друга независим, но они потом оформляются в так называемый протокол.

И получается, что ты, как бы, задачу разбиваешь на несколько частей, там, может быть, там, на 3-10 частей, да? И каждую из них решаешь, и в этом наслоении этих решений дает тебе какое-то комплексное, как бы, решение.

Понимаешь, да, о чем я говорю? Да. Вот. И получается, что идея у нас в том, чтобы, значит, сделать такой искусственный интеллект, и, как бы, его представить и продать такой искусственный интеллект, который мы можем сделать.

Потому что это важно для нас, чтобы мы не продавали воздух, да, чтобы мы не обещали больше там чего возможно. Вот. И, пожалуйста, ты собираешься делать свой собственный искусственный интеллект или все-таки на базе Geminine?

Мы используем чужие модели, получается, но со своей логикой. Вот. Что, в принципе, мы, наша система, она не заточена ни под какой конкретно провайдер моделей искусственного интеллекта, но в целом есть, которые работают более предсказуемо, там, по сочетанию качеств, да, того, что мы, как бы, Gemini используем как по умолчанию, так сказать.

Вот. И что мы, короче, что наша, получается, одна из наших идей в том, что мы, на самом деле, не тренируем модели по-настоящему.

То есть мы, короче, не в том сегменте искусственного интеллекта, где они еще сами что-то доучивают на уровне вот этих гиптемпараметров каких-то или еще что-то, да, что вот когда модель оформляется там в какой-то большой кусок данных какой-то, потому что мы этого не делаем.

То есть у нас все в обход этого, то есть у нас мы, как бы, как, как арендуем, в общем, по сути, искусственный интеллект. Вот. И, то есть, поэтому у нас, ну, то есть это частично, как бы, вызваны решения наши именно вот это, как бы, ограничения, что мы хотим уметь переезжать между моделями и провайдерами.

Вот. И получается, что есть искусственный интеллект, вот, и он, что это вообще такое, да, что, типа, искусственный интеллект это большая языковая модель, и, получается, мы делаем все, что мы хотим сделать, мы делаем на технологиях сегодняшней, да, то есть у нас нет никакой, никакого шага там, где, типа, а вот завтра изобретут такой, типа, будет классно, тогда мы сможем, а пока что хрен знает как.

Что мы такого у нас нету. Вот. И мы пользуемся технологиями современными, просто обычными, как и все другие люди. Просто мы их лучше обтачиваем и, как бы, более концептуально используем.

То есть основа, получается, всему является вот эта большая языковая модель LLM, плюс структурный вывод это, так называемый. Это то же самое, что инструменты в LLM.

В общем, мы до этого дойдем еще. Просто, что одна из, короче, что ты из LLM, ты обычно, ты получаешь текст обратно, а ты можешь еще оформить, что он выдаст тебе в какой-то структуре, то есть тебе более структурно ответы на твой вопрос.

И, короче, мы эту идею используем и просто ее до абсурда разгоняем, как бы, что, типа, ее много, как бы, много всего вкладываем в один запрос. Вот, и получается, что у нас есть несколько, короче, вот этих, как сказать, ключевых столпов, так скажем, в реализации.

Их около десяти будет. Вот. И, значит, идея в чем у нас? То есть тут идея концептуальная такая, что... Вот мы, получается, напишем под каждый из этих столпов, мы запишем такую, типа, как мини-презентацию или доклад, которая, критерием, как бы, успеха которой будет, что мы сможем LLM объяснить, как это устроено.

То есть мы, получается, то есть идея в чем? Значит, будет какой-то, типа, как свод, типа, как библия для LLM, где все десять столпов описаны на том языке, который LLM может понять, чтобы, типа, LLM в сжатом состоянии, в каком-то приближении понимала, как вся ситуация устроена, типа, как вообще весь мир устроен, да?

Как бы, понимаешь, да, к чему я поню? Что, типа, не будет такого, что какой-то есть, получается, темный уголок для LLM, потому что его человек сделал, да? Что мы, получается, хотим сделать так, что оформить в теорию, значит, в серию, типа, статей, и эти статьи, получается, будут, как бы, исходным состоянием, типа, как вселенной, грубо говоря, да?

Что, как бы, как это выглядит? Значит, у нас есть, получается, база данных с вайбами. Один вайб — это запрос к LLM, да, что, типа, мы какой-то послали запрос LLM, он нам ответил, и вот это все — это вайб один, получается, да?

И что и вайбы, они всегда, типа, в контексте как-то предыдущих, что, типа, каждый вайб, он вызван каким-то предыдущим вайбом, то есть оно, ну, что, типа, чтобы, допустим, Вася пошел в магазин, сначала Вася должен существовать, а Васю создал, допустим, босс Петя, который создал это по... потому что ему нужно было расширить команду, потому что у него была цель там...

Короче, по цепочке можно размотать, по идее, в теории, все решения до, типа, до самого начала. Да, что, типа, почему вот так сделал? Это, типа, вайб в ответ на тот вайб, который в ответ на тот вайб, и так далее.

Вот. Значит, а что в начале, в самом, типа, то есть если размотать нашу вселенную, у нас, типа, там большой взрыв, да? Если эту вселенную размотать, то там будут такие, как бы, 10 заповедей, короче, что у нас, получается, есть изначальный сбор или свод статей, который объясняет технически ЛЛМу, как все устроено.

И, в общем, мы сейчас, вот это наша, как бы, промежуточная задача, короткосрочно написать эти 10, короче, заповедей. То есть написать 10 презентаций. Они, получается, как бы, тут важнее, чтобы он понял ЛЛМ, потому что потом с помощью ЛЛМ мы можем составить человека понятную презентацию.

Вот. И что мы сейчас делаем с Лешей, получается, версию, которая от человека идет, что сейчас Леша одну из концепций пытается объяснить, концепцию мемов. Вот.

И, ну, похоже, что дальше мы собираемся, как бы, сделать так, чтобы мы писали в первую очередь для ЛЛМа, а потом с помощью ЛЛМа генерировали, с помощью каких-то там промптов, генерировали уже презентации, которые люди понимают.

Ага. Ага. Вот. И тут, как бы, интересный начинается момент, что, типа, мы сразу, то есть мы в нашей компании, получается, делаем так, чтобы ЛЛМ делала всю работу.

Что обычно, как люди обычно не учены, они работают с ЛЛМом. Они говорят, сразу пишут, хочу, чтобы все было. Они говорят, что уже должно быть, да. И, как зачастую, они не до, как бы, правильно не формируют свой промп, потому что они не описывают, что им важно, они не описывают, что возможно, они просто говорят, что хочу, и потом ЛЛМ, естественно, не делает этого, потому что сильно много шагов пропущено, так скажем, да.

Но можно любую задачу сложную разбить на подшаги, где каждый шаг, получается, определяется, ну, полностью определён и выверен, и получается набором, короче, этих шагов отдельных, то есть если задачу разбить по шагам, и каждый шаг сделать отдельно, то можно добиться сложного поведения, так скажем.

Вот. И получается, что всё наше, короче, всё, что мы пытаемся сделать, это сделать такую систему, которая может, то есть ты говоришь промп, она может разбить промп на шаги, как бы, грубо говоря, и исполнить их в этой системе, так скажем.

И, в общем, и что, типа, мы можем, как система учится, она учится необычно, как ЛЛМ учится, то есть обычно ЛЛМ как учится, то есть, типа, есть тренинг и посттренинг.

Тренинг, это, ну, типа, получается, загружает всю информацию, которая вообще доступна, да, то есть, получается, в ЛЛМ его вкармливают весь интернет, а потом ему делают посттренинг, то есть ему потом дополнительно куча индусов сидят, и с ним чатятся, и палец вверх либо вниз ставят, типа, что им нравится, либо не нравится, да, и что, типа, пытаются, как бы, настроить доступ к этим данным, которые он уже выучил в процессе тренировки.

Теперь посттренировка, это когда влияют, типа, примерами на то, как данные должны получаться и как возвращаться, да, то есть, типа, как стиль работы с данными. Проверка, проверка.

Типа того, и, в общем, что это заключается в этом, короче, по сути, заключается конкурентное преимущество всех провайдеров ЛЛМ, да, потому что они сверху какой-то посттренировочный слой накладывают, то есть потом люди сидят и учатся, учат машину правильно отвечать на вопросы, да.

Вот это, то есть, два способа учить. Третий способ, это, получается, промпт-инженерия, короче, что, типа, вместо того, чтобы обучать саму модель, то есть давать ей больше данных, вместо того, чтобы давать ей примеры о том, как бы ты хотел получать ответы на вопросы, ты можешь корректировать свой промпт, получается.

Ты можешь влиять на то, как ты вопрос задаешь, чтобы получить, направить, так скажем, грамотный ответ. Ага. Вот, и типа, получается, что наша система, она учится, модифицируя эти промпты, обкатывая их.

То есть, но наши промпты, они не такие, как обычные, где, типа, текстом ты пишешь кусок сообщения, и он тебе кусок отвечает. Наши промпты, они более технологичные, структурные, и получается, и получается, что один бот может другому улучшать процесс, выработав для него, так скажем, пошаговый алгоритм, как решать проблему, чтобы все предусмотреть все тонкости.

И, типа, понимаешь, понимаешь, о чем я говорю? Что, типа, можно начать с того, что у тебя есть какой-то алгоритм, типа, твоего процесса. Допустим, я продаю товары, это значит, что мне надо связываться с клиентом.

Ну, к примеру, такое, да, какая-то. Ну, какая-то логика. То есть, мы к логике никакой конкретной не привязываемся, потому что она всегда контекстна. То есть, мы, получается, делаем общую систему, а в ней могут быть разные ситуации.

Вот. И получается, что был выработан бот LLM, мы говорим, надо нам продавать товары, вот мои клиенты. Он говорит, ну, окей, буду связываться с клиентами, буду им звонить, спрашивать, нужны ли им товары, и, типа, продавать.

Ну, к примеру, это такой, типа, алгоритм, который бот выбрал. Неважно, правильно он или нет, просто он выбрал его, и он с ними работает. И тут, в процессе выполнения выясняется, что, допустим, клиенты бросают трубку, к примеру, что, типа, они не любят cold calling, к примеру, да?

И получается, какая-то другая, более умная модель, более умный искусственный интеллект, он может, допустим, взять записи, там, 100 разговоров, взять записи 100 результатов и метрик, проанализировать, и он говорит, окей, ты пробуешь сделать cold call своим клиентам, они бросают трубку, результатов, типа, очень мало.

Значит, скорее всего, мы можем попробовать другую стратегию, то есть, выбрать этот другой план. К примеру, вместо того, чтобы сразу писать предложение, мы делаем, как будто бы, research, к примеру, да, сначала делаем research про компанию, и подбираем ему нужный solution, и его предлагаем, ну, к примеру, да, что, типа, у нас был один алгоритм, а мы посмотрели его, поработали, статистику собрали не идеально, улучшили, промп, получается, улучшили стратегию, что, типа, мы внедрили еще шагов, то есть, а это, а при этом, изменение, оно может быть очень мелкое, оно может быть, допустим, что, да, ты звонишь, но ты недостаточно вежлив, допустим, с ними, да, типа, просто сделай, поставляй так же, как есть, только сделай, маленькое изменение, типа, попробуй более вежливо, типа, собери статистику, лучше или нет, значит, что, вот так наша система улучшается, способом, что, типа, мы инструкции, получается, улучшаем, а не понимание, вот, и что, типа, а если мы в какой-то ситуации видим, что происходят какие-то ситуации, допустим, в рабочие, что, допустим, часто проекты в срок не сдаются, к примеру, да, то это значит, что это для нас возможность улучшить инструкцию, либо для менеджера, либо для работников, чтобы такой ситуации не создавалось, чтобы с ней, как бы, бороться, понимаешь, да, вот, а, и, значит, и получается, вся система, то есть, все, что мы делаем, искусственный интеллект, это все время, получается, бот ответственен за другого бота, то есть, получается, в идеале мы делаем такую систему, которой не надо программировать никакой бизнес-логики вообще, то есть, мы делаем такую систему, которая, где мы можем, грубо говоря, ее попросить стать чем угодно, да, согласно нашим особенностям нашего бизнеса и все такое, вот, но при этом у нас остаются, как бы, вот эти базовые инструменты, на которых все это выстраивается, что у нас есть там какие-то инструкции, у нас есть там вайбы там и так далее, что мы, но, и система может улучшаться, улучшая процессы, вот, и что типа, что значит улучшить процесс, это скорее всего, значит, улучшить какую-то инструкцию, либо его переструктуризировать, и сделать какие-то симуляции, собрать метрики, либо просто попробовать его даже в реальности, этот обновленный процесс, и посмотреть на метрики, и допустим откатиться назад, либо там еще что-то, то есть, ну короче, варианты имеются о том, как ты это делаешь, но именно все движимое этими метриками, потому что мы иначе не можем, получается, понимать, успешно ли мы сделали изменения или нет, если нам не на что базироваться, если мы можем одновременно менять, получается, и процессы, и данные, на что-то нам надо базироваться, да?

Да, Ну, это очень большое количество метрик может быть, то есть, заранее их все придумать мы не сможем, потому что в зависимости от направления, как будет использоваться этот бот, да, у тебя будут абсолютно разные метрики, то есть, кому-то надо, не знаю, ставить задачи на команду, кому-то надо придумывать бизнес, кому-то что-то там, не знаю, вести бизнес, кому-то просто нужен, там, персональный помощник, и это абсолютно разные метрики, вот, то есть, как я понимаю, ты хочешь сделать иерархичную систему ботов, то есть, есть боты, которые выполняют простые команды, есть боты, которые проводят ревизию и корректируют работу более простых ботов, то есть, они каким-то образом, на основе каких-то метрик, должны понимать, успешно ли работают низкоуровневые боты, или нет, и понимать, в какую сторону, что менять, потому что, например, вот как ты привел пример, что, если делают холодные звонки, да, одно дело, это поменять стратегию внутри самих звонков, другое дело, это вообще отказаться от инструмента звонков и перейти на другой инструмент, третье дело, это изменить, например, выборку тех людей, которым ты звонишь, и в моем именно понимании, это немножко в разных плоскостях решение.

Ты абсолютно права, и как раз, в общем, в итоге, что часто ты хочешь какую-то цель, да, хочу более и больше эффективность, и мы хотели бы выстроить такую систему, в которой ты можешь оперировать своими целями, а конкретно алгоритм или способы достижения, они получаются в подвешенном состоянии, и ты можешь на это влиять, в итоге, да, и что, если придерживаться, опять же, этого пример, хочу более эффективных продаж, к примеру, да, то это, если ты меняешь, допустим, только внутри процесса, к примеру, более вежливо там относиться, да, то ты как бы меняешь только инструкцию тут.

Если ты, допустим, встраиваешь какой-то шаг, допустим, прежде чем делать колд-колд, сделать еще ресерч, к примеру, да, то это получается, ты меняешь, типа, процесс, видимо, а если ты, допустим, решаешь вообще отказываться там от инструмента, к примеру, и делать так, что, допустим, уже не ты продаешь, а у тебя сами покупают, к примеру, это вообще может быть, ну, как бы, структура тут меняется, как бы, ну, этого, как бы, этого бизнеса.

И это должны сами боты внутри себя понять что надо делать. ты, когда делаешь какой-то промпт, а мало понятный, да, тебе предлагается, получается, как бы, калейдоскоп из палитра, так скажем, из интерпретации, где, ты, типа, где пытаются навести, что, типа, ну, вот это, когда-то я показывал тебе тут, а призму, вот это как раз про это, ну, как бы, общая метафора, про то, что, типа, ты можешь, получается, задача у тебя одна, но ты можешь на нее через разную, под разными углами посмотреть, ты хочешь что сделать, ты хочешь поменять персонал, ты хочешь поменять процесс, либо данные хочешь поменять, да, и что, типа, в зависимости от этого, ну, там еще там посложнее, шесть там вариантов, тебе даже девять, вот, что ты, в теории, ты можешь, получается, подобрать интерпретацию, которая тебе подходит, и ее прорабатывать, вот, что, это тоже, это всегда возможно, что, типа, когда, то есть, в идеале, мы даем задачи открытые, открытым концом, потом их прорабатываем, как бы, более узкую интерпретацию выбираем, вот, но в идеале, мы должны уметь сравнивать тоже решения, которые, допустим, вообще разные, да, что, типа, у меня есть задача улучшить продажи, давайте попробуем три разных решения, посмотрим их, сравним, и, может быть, из трех сделаем одно, ну, из тех, которые сработают, как пример, да, что, это тоже, как бы, не должно считаться процессом, так что, типа, выбрать одно из трех.

Смотри, это все равно, чтобы принять решение, да, то есть, допустим, мы задали задачу, давай, обзванивай клиенту, чтобы мы продавали наш продукт, чтобы сделать какие-то выводы вообще, работает, не работает, надо что-то поменять или нет, надо накопить какое-то количество данных, то есть, надо обзвонить какое-то количество людей, потом, применить одну гипотику, гипотезу, чтобы скорректировать, чтобы улучшить конверсию, еще раз призвонить какое-то количество людей, и это достаточно большое количество, и это потраченные деньги, например, вот.

это, короче, потраченные деньги в старом подходе, да, когда мы, типа, попробовать, то есть, АБ-тестинг, это всегда жесткая фигня, потому что, обычно, АБ-тестинг, приводит только к тому, что, находятся такие метрики, по которым менеджер может решить, выбрать решение, которое ему больше нравится, подобрать, под, как это, загнуть реальность туда, куда ему хочется, АБ-тестинг, это то, что всегда делается двойная работа, делается и то, и другое, и потом, в итоге, никому не хорошо от этого, потому что, ну, от того, что такие вещи, то есть, в стандартном процессе, получается, очень мало места, для того, чтобы пробовать разные решения, потому что, очень сложно это, то есть, не можешь, допустим, малень, чуть-чуть поменять, структуру, в стандартном подходе, если она, допустим, требует, там, нового отдела, к примеру, или там еще что-то, да, что-то, ты не можешь, так быстро развернуть, и попробовать, вот, и поэтому, все время, ну, ну, как бы, реальность, она движется, получается, не по плану, а, типа, она, как машину ведут, да, что, типа, только влево вплавляют, проверяются гипотезы, да, да, и, типа, что, часто, что ты, можно, ты ограничена тем, что, ты какую-то гипотезу можешь сделать, и какой-то поворот можешь сделать, ты знаешь, что ты никогда не повернешь на 180 градусов, несмотря ни на какой эксперимент, да, потому что, просто система, она сама сопротивляется, так скажем, да, что, если делают, допустим, АБ-тестинг чего-то, то его там изолируют, короче, как-то, и это все очень жестко, трудно, короче, ну, то есть, да, нужен большой объем данных, чтобы понять, любое малейшее изменение, сработало оно или нет.

Вот, и тут получается такая, как бы, есть идейка, так скажем, неоднозначно, вот, что, типа, на самом деле, нам нужно не данные, вообще, зачастую, а статистика, да, она, как бы, данные и статистика, это одно и то же, по сути, да, что, типа, да, и, но зачастую, что мы, конкретно данные нам не сильно помогают, нам помогает именно статистика, вот, и, значит, идея тут такая, что, что если мы до того, как вообще начали, вообще, что, потому что мы, когда я разговариваю про свою систему, там всегда, как бы, стоит этот вопрос, маячивает на заднем фоне, что, типа, если я начинаю с пустого листа, то что?

Что, типа, окей, потому что, если мы говорим, допустим, про АБ-тестинг в обычной компании, да, то ты примерно представляешь, что это, нам нужно собрать логи, допустим, в текущей системе, сделать какой-то, бранчинг, какой-то фичер, какой-то штуки, которая включается, выключается, которую можно делать в АБ-тестировании, задеплоить это, сделать АБ-тестинг, собрать статы, и, типа, посмотреть результаты, выбрать, типа, А или Б, да, что ты всегда начинаешь с построенной системы уже, то есть, и ты, типа, ты добавляешь в нее метрики до того, как станет нормально, так скажем, среда, чтобы тебе принимать решение, да, что, типа, что у тебя может быть такое, что процесс есть, а метрик нет еще, что тебе надо еще сначала достроить метрики, дорастить их, и только потом ты можешь замерять процесс и понимать, работает или нет.

вот, и, значит, а вот я, как бы, моя хобби, моя страсть сделать такие системы, которые не заставляют начинать ни с какого конкретного шага, да, что ты можешь в нашей системе, вот этой пирамиды призмы, ты можешь сделать либо процесс сначала, либо данные, либо иерархию, да, что ты можешь вообще начать с того, что, грубо говоря, ты, когда ты в новую вселенную приходишь, да, а там только 10 заповедей есть этих изначальные, так скажем, которые объясняют, как все работает, но дальше ты можешь начать, как бы, сама, что ты можешь начать с того, чтобы определить метрики, вообще, типа, как вы представляете, вселенная пустая, короче, да, а уже ты думаешь о том, что товары продаются, короче, что, типа, проект завершается, что ты заранее определяешь, то есть, вот тут, как бы, не совсем класс, сегменты, короче, то есть, есть, получается, или группы, короче, я немножко могу не владеть правильной терминологией, особенно на русском языке, то есть, поэтому немножко, если что, короче, что не доверяем я на 100%, что, есть, короче, некоторые группировки, я их сегментами называю, но я не знаю, как, короче, правильно, что, допустим, вот, пример группировки, это, что у меня есть, значит, страны, в этих странах есть офисы, в офисах, есть, получается, отделы, и в отделе работает человек, и он работает по какому-то клиенту, так скажем, что, типа, это, короче, сегментация, и ты, типа, получается, можешь сложить суммы всех этих сегментов и получить данные о компании, к примеру, да, что, типа, если свернуть, короче, обратно все это, ты получаешь общее, короче, да, что, это именно, что, типа, там каждый, как бы, ряд в этой таблице, он, получается, вносит финальную сумму, так скажем, да, потому что, ты, когда просуммируешь, допустим, все продажи, за всех отделов, всех людей, ты получаешь продажи по компании, да, или, типа, ты, допустим, продажи, оставляя группировку по клиенту, просуммируешь внутри компании, у тебя, у тебя видишь, типа, продажи по клиенту, ты можешь данные по-другому свернуть, короче, вот, как это называется правильно, то есть, это сегментация, это, сегментация, сегментация, наверное, окей, а кластеры, получается, это не жесткая струб, это, типа, именно, это где, группа продиктована данными, так скажем, правильно я понимаю?

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

кластеры, от сегментов, чем отличаются? Да, наверное, вот такой пример, эти.

Не знаю, сегменты, мне кажется, это заранее, когда ты знаешь, по каким условиям ты делишь, вот, а кластеры, они сами, как бы, появляются, вопрос, на каком уровне ты хочешь остановиться, вот.

Вот правильно я бы тогда говорю, допустим, у нас есть, значит, сегменты, это, допустим, по странам, клиенты, и там офисы, ну, к примеру, какая-то у нас есть структура сегментов, все вкладываем, получаем общие данные по компании, а кластеры, получается, это, допустим, среди клиентов моих, те клиенты, которые инвесторы, к примеру, что, типа, получается, уже сегменты ты делишь по разным категориям, то есть, динамически можешь, типа, определить, и это кластеры, правильно я понимаю?

Да, ну, вообще, в принципе, сегменты кластеров, мне кажется, это схожие достаточно слова, вот, может, в зависимости от того, в какой сфере ты их применяешь, там, чаще они используются, вот, но, когда мы с группировки как-то, потому что, а в итоге, что, ну, у тебя, ну, да, что, какая-то вот эта недеяль, то есть, там, мне кажется, что, что-то про неудимое, это разная.

Иерархичная группировка. Да, иерархичная группировка, это, это, короче, вот это, это же, это более жестко, типа, это, то есть, ты заранее знаешь, ты, когда создаешь свою статистику, свою структуру статистики и метрик, ты заранее знаешь, получается иерархию своих сегментов, и как они складываются, да, ты говоришь, допустим, что в моей компании продажи происходят по отделам, к примеру, или там по командам, ну, какая-то такая херня, вот, получается, и это, типа, основное знание, короче, которое потом, ну, оно проявится, то есть, есть, короче, такой принцип я люблю упоминать, какой-то, я забыл, не паре, то, а какой, короче, чей-то принцип, и он заключается, конве, по-моему, в том, что, когда программу какую-то, программы реализует компания, структура программы напоминает структуру компании, то есть, если, допустим, у тебя есть три команды программистов, внутри одной большой компании, внутри программы ты увидишь, три программы отдельные, по сути, разные, которые соединены в одну, да, что, типа, там есть напрямую зависимость, иерархия человеческая, и, типа, продукты этих, этих иерархий, структурные, да, что, типа, какую бы они программу пишут, вот, и получается, когда мы задаем статистику, мы, получается, инка, то есть, вот эту структуру иерархическую, мы ее, получается, вы, как это сказать, вы дистиллируем, короче, да, что, типа, на этапе, когда мы метрики свои хотим организовать, продизайнить, да, мы уже знаем, получается, что у нас будут продажи по командам, получается, и у нас, ну, и, типа, мы в итоге, каким-то, когда мы делаем такую сегментацию какую-то, типа, допустим, по командам, по регионам, то мы где-то дальше в системе увидим, как бы, зеркала этих группировок, как бы, понимаешь, что я говорю?

да, что какой-то фантом, короче, этих группировок, он будет отсвечивать еще потом, да, поэтому это очень важный момент, получается, если мы заранее закладываем в статы, что мы работаем по командам, получается, боты будут работать как команда, допустим, будут, ну, к примеру, они могут общими статами оперировать, как команда, и так далее, то есть мы можем, получается, заложить логику, и, так скажем, как это, подкрепление, ну, на этап дизайна нашей статистики, да, и что, допустим, вот у меня сейчас, для покера статистика, она сегментирована, как, что игрок, и типа, стадии игры, короче, что я собираю метрики, получается, они только, они все имутабельны, то есть, получается, только вставляешь их в базу данных, никогда не обновляешь старую метрику, они только вставляются, а потом, типа, собираются и пересчитываются, знаешь, что, типа, ты, допустим, всегда только записываешь в конец, и, типа, это как, типа, как леджер, типа, как, ну, как бухгалтерия, короче, да, что ты, типа, записала метрику в базу данных, она потом сложилась, когда ты, ты потом увидела, что, допустим, какой-то, в период времени одна была продажа, она потом где-то, потом просуммировалась, и она стала там ста продажами отдела в месяц, примерно, да?

Ну, то есть, получается, те метрики, которые ты новые добавляешь, они делаются на базе уже существующих, то есть, это какое-то действие с уже существующими метриками. Да, что, типа, у нас, получается, отделен процесс сбора и, агрегат, и, как бы, использование метрик, то есть, агрегация и использование метрик, это, как бы, два шага, что, типа, ты, то есть, по покеру, получается, у нас одна, то есть, покерная игра, что это?

Это, короче, текстовый файл, который мы прогоняем, типа, через наш покерный движок, и он выдает, типа, ряды статистики, вот, как каждый игрок поступил на каждом, короче, шагу игры, вот, и там много, достаточно колонок, там, типа, 50 колонок, типа, какие он действия сделал, какие возможности, там, всякое такое, вот, и потом они уже агрегируются, то есть, в часовые статы, то есть, они в такие ведерки, типа, что, в этом часу, такой-то игрок, типа, в какой-то фазе игры, делал то-то, да, что, типа, они, короче, начинают компрессироваться, то есть, у тебя сначала, типа, вообще, сырые, типа, статы, а потом они начинают в часовые, короче, взбираться, а потом, типа, в месячные, там, и так далее, вот, и что они с каждым разом немножко теряют точность, но, получается, идея в том, что ты можешь очень много статов так хранить, потому что они, типа, исторически, они начинают просто терять точность, и ты можешь сколько угодно там в конце хранить информацию, короче, вот, что она просто ужимается, и, короче, и ты, ну, что это способ года, там, десятилетия, хранить много, много разных, типа, статистики, но, получается, она, именно сегментация не меняется никогда у нее, то есть, вот это, что ты заранее должна, получается, то есть, выбрать, что, какая у тебя структура продаж, то есть, допустим, что продажи у меня по, для меня важная сегментация по команде, по региону, по клиенту, к примеру, да, вот, но потом ты, когда ты определил эти сегменты, ты потом можешь легко добавлять новые метрики, ну, ты, уже, типа, добавлять новые всегда легче, чем, получается, ну, как-то пересегментировать, вот, и, короче, к чему это все я говорю, что, типа, вот это группировки, которые, мы можем выбрать вообще в самом начале, короче, дизайна системы, то есть, мы только вот начали с чистого листа, и мы уже, мы уже говорим, значит, я хочу, каким-то образом, следить за своими продажами, продажи у меня будут по клиенту проходить, типа, группироваться, и, типа, по направлению, вот, и, а потом я могу, что главное, это как мы эти данные собираем, а потом я могу делать к этим агрегированным данным, всякие разные запросы уже по-разному, кто там топ-5 у меня был, типа, за пять минут, там, всякую такую фигню, можно легко высчитывать, но главное, типа, выстроить процесс, как они собираются и складываются, а потом можно чего угодно с этими делать, с этими штуками.

опять же, надо изначально определить, вообще, вот эти вот базовые метрики, которые нужно собирать. да, то есть, там получается, в случае с покером, метрики, они получаются все числа, короче, базовые, да, что, типа, у покера, это, что, типа, вот, на этой стадии игры, игрок, он какое действие сделал, сколько этих действий было, и там, в основном, типа, они как да, нет, короче, грубо говоря, он, типа, поставил все или нет, да, нет, он, типа, сколько денег поставил, сколько выиграл, короче, все число, число, число, а потом они схлапываются, короче, что, типа, потом можно более, то есть, короче, из базовых метрик, можно вывести потом формулы, которые, допустим, уже считают, что, типа, зная, что, сколько игрок выиграл и проиграл, можно составить формулу, допустим, как много он проигрывает и выигрывает, да, то есть, его сделать, типа, соотношение между выигрышами и проигрышами, к примеру, да, это уже выгодный метрик.

Смотри, у тебя, получается, в покере достаточно ограниченное, вообще, количество базовых метрик, да, которые можно отслеживать, то есть, это, ну, ты можешь сам, ты понимаешь сам, что вообще, в принципе, можно, их, допустим, ты сказал 50, окей, если мы говорим о процессе продажи, да, этих метрик может быть тысяча, да, которые надо собирать, а потом уже спустя какое-то время мы поймем, что, ага, нам надо вот их комбинировать так, чтобы понять на самом деле, какой процесс, но вот эти вот базовые метрики, это большое количество, и вот каким образом их все придумать, ну, потому что вот человек, занимается продажами, он не знает, то есть, они, в общем, в целом, метрик может быть тысяча, к примеру, но тысяча метрик, привязаны к разным агрегациям, к примеру, да, что, типа, допустим, метрики, которые считают производительность команды, они, допустим, берут и отбирают там, по отделам, и финансовые метрики считают, да, другие какие-то штуки, они могут, другой под субсед, как бы этих метрик считать, вот что в целом, да, их может быть легко тысячи, но они еще могут быть по-разному пересобраны, из сырых данных, и еще быть по-разному привязаны, то есть, допустим, есть метрики продажника, а есть метрики сделки, к примеру, да, что они, допустим, в теории, они как-то между собой связаны тоже, что ты можешь какие-то вывести из других, там, или еще что-то, но в целом, да, что легко их может быть, в итоге в реальном бизнесе, тысячи метрик, но там такая херня получается, что мы отделяем три типа метрик, базовые, которые надо записывать, то есть, совсем самые, короче, которые неуделимы, потом, если выводимые метрики, это те метрики, которые можно вывести напрямую из базовых, то есть, тебе не надо...

Но их можно добавить в любой момент, типа считать. Да, их можно в любой момент, и они, типа, считаются на ходу, ты выбираешь базовые, а потом по формуле, типа, как в Excel-е формула, оставляется, и типа, ты досчитала, сколько тебе надо внутри группы, примерно, да?

И третье, получается, есть еще ранжированные метрики, и их смысл заключается в том, что, а это то, ты можешь, какие-то очень сложные формулы, ты можешь их, получается, делать из них, такой дайджест, короче, топов, короче, внутри, внутри, внутри, какого-то, ведерко данных, ты можешь сказать, что кто у вас по такой-то формуле, типа, топ-10, примерно, да, что ты, допустим, кто у вас здесь самый агрессивный чувак, кто у вас самый нормальный чувак, и типа, у тебя полностью твое ведерко с данными, допустим, которое уже, то есть оно уже сжато, там и хранится данная, только, допустим, о месяце игры всех игроков, да, и ты можешь этих игроков еще построить, как бы, топ, так скажем, по разным этим формулам, и там, получается, можно делать по очень сложным формулам, там, то есть, когда ты, ты можешь, допустим, ну, то есть, вот, как я, например, делал в статистике у себя, и я, получается, из базовых метрик выгружу, типа, какую-то метрику более сложную, допустим, что нормальный игрок, он, типа, типа, считает, из 25 разных метрик, он собирает одну взвешенную, короче, там, в итоге, что, типа, нормальный игрок, это тот, который, там, в основном, типа, не проигрывает, тот, который, типа, на удачу не надеется, там, то, все, короче, что ты можешь много метрик, их ужать, короче, в одно число, если взвешивать, допустим, что, типа, для этой метрики, а, типа, выигрыш, он, там, в два раза более важен, чем, допустим, можешь по ним строить, вот эти топы, ты, получается, очень, очень гибкая фигня, что, типа, ты мало хранишь информации, и ты можешь в итоге, какие-то очень гибко штуки вычислять, типа, допустим, приоритизировать задачи, типа, какая тут из задач требует наибольшего внимания, примерно, да, и это требует наибольшего внимания, это составная метрика, из, типа, насколько задача была долго неактивна, сколько там приоритизация у нее, сколько там, это все числа складываются, у тебя выстраивается какой-то, типа, финальный рейтинг, вот, и получается, что новые метрики вводить легко, новые сегменты вводить трудно, то есть, вот эти новые, изначальные, типа, группировку, что, типа, это важно поопределить, группировку правильно заранее, ну, и потом можно их, как-то разные, всяко-разные, с этими, с ведерками данных играть, склеиваться там, и всякое такое.

Ну, и ты хочешь, чтобы искусственный интеллект сам определил базовые метрики для каждого вопроса, для каждого направления. Да, что в теории, просто тут, короче, вот именно важно, я хотел бы, я почему это описывал, просто потому, что я бы хотел, чтобы у тебя правильно, как бы было состояние ума, так скажем, да, что мы делаем не с одной бизнес-системой, которая выстроена одним способом, да, что, типа, мы к клиенту приходим, у клиента всегда уже бизнес, типа, у нас там есть доступ к этому, нам надо такие-то сделать решения.

Нет, что мы, что наша система, она работает с разных, как бы, точек зрения, и что делать статистику, метрики наперед, это одной, может быть, одной из самых интересных, на самом деле, способов развивать бизнес, потому, что ты изначально можешь, вместо того, чтобы сначала что-то сделать, а потом приводить метрики, ты можешь сначала определиться с метрикой, и потом боты на каждом шагу, их, как бы, будут учитывать, они будут знать, что для нас важно, вот оно описано в метриках, поэтому мы сделаем такие процессы, которые эти метрики, во-первых, могут собирать, во-вторых, могут их оптимизировать, ну, как-то так.

понимаешь, сейчас и у людей-то с этим же трудность происходит, то есть, когда у тебя, не знаю, берут менеджера в отдел продаж, там, руководителя отдела продаж ставят, да, он пытается сразу задать какие-то метрики, по которым он дальше будет оценивать своих подчиненных, их успехи в продажах и прочее, потом, ну, то есть, до какого-то времени этих метрик достаточно, они не дают нужную информацию, но в какой-то момент ему надо пойти там и глубже проанализировать, он понимает, что сейчас этих метрик недостаточно и начинает вводить новое.

То есть, если бы он мог, он бы сразу ввел эту метрику, но он не знал. Или так же, как в маркетинге, да, ты сначала по одним метрикам смотришь эффективность рекламы, бла-бла-бла, а потом тебе надо еще понимать, а как, например, отдел продаж с этой рекламой работает, и ты только в этот момент вводишь эти метрики.

Потом тебе в голову приходит, что, блин, мне недостаточно только продавать, да, мне надо еще и удерживать своих клиентов, чтобы они как можно дольше там у меня на поддержке были. Ты начинаешь вводить тогда вот эти вот метрики для отслеживания.

Если бы ты мог, если бы ты был более дальновидный, да, на первом этапе, когда ты только начинал работать, ты бы ввел эти метрики. Вот, то есть, каким образом искусственный интеллект сможет вот так же, ну вот, сможет избежать вот этой вот проблемы того, что ты понимаешь, обучаясь, ты понимаешь, что тебе нужны еще какие-то дополнительные метрики.

Или достигая какого-то уровня в бизнесе, ты только на этом этапе понимаешь, что тебе нужны дополнительные метрики, потому что ты хочешь развернуть там направление своего бизнеса. и решение тут такое, что получается, новые метрики вводить легко, трудность только с переструктуризацией.

То есть, ну, и то там тоже промежуточные какие-то можно сделать шаги, но что, что искусственный интеллект может помочь, помочь переструктуризировать метрики. к примеру, сначала, сначала, у тебя, допустим, маленький бизнес, и у тебя, допустим, клиенты или продажи группируются по твоим сейлсам.

Каждый сейлс, это, короче, ну, к примеру, один сегмент, да, типа твоих данных. Но потом, допустим, в процессе, у тебя, получается, что у тебя много сильно сейлсов стало, и что ты сейлсы уже организовываешь, допустим, в свои отделы, и тебе надо переструктуризировать, ты можешь в теории переструктуризировать метрики, которые были по сейлсам, стали по отделам, то есть, их как-то промигрировать, так скажем, что, ну, здесь проблемы нет, ты просто объединяешь их, и смотришь на общий.

Это, ты объединяешь, это легко, если объединить, к примеру, да, если разделить, то там чуть посложнее, как бы, может быть, что наоборот, допустим, у тебя были отделы, ты говоришь, окей, у меня, лучше я считать буду по индивидуальным продажникам, а отделы я у них знаю, к какому они принадлежат, и типа, ну, что, короче, что, вот, вот с этой частью, короче, есть определенные, как бы, накладки, ну, не то, что накладки, а что, шероховатость, но если ты часто так не делаешь, что, типа, допустим, ты определила свои метрики, а потом ты хочешь их, не метрики, а сегменты, и потом ты хочешь их еще разбить, короче, если ты это часто не делаешь, то ты можешь, в принципе, любые делать изменения с метриками, оформлять новые, оформлять старые, оформлять новые метрики, которые, типа, это версии предыдущих, там, ну, короче, что, типа.

Нет, вот смотри, именно группировка и разбивка, здесь проблемы я не вижу, потому что мы оцениваем по тем же метрикам, то есть, ты просто суммируешь, или разделяешь по объектам, окей, ну, то есть, у тебя эти данные уже накоплены, здесь проблемы нет, потому что, смотри, там просто может быть такая ситуация, что, к примеру, у тебя данные не полностью накоплены, то есть, допустим, тут еще мы можем дело иметь с такими статами, которых очень много, к примеру, да?

А, ну, то есть, да, ты говорил, что у тебя идет группировка, вот, верхний уровень, они, то есть, они современят, ты, то есть, настраиваешь вот эту иерархию по времени, что ты, допустим, даже, как бы, внутри нашей программы, у тебя может быть, допустим, разный, как бы, уровень, тир твоего аккаунта, так скажем, да, что ты по-разному можешь настроить, настраивать, как метрики хранится, что, допустим, может быть, в бесплатной версии, к примеру, мы реальные данные, типа, без потерь, храним только, допустим, один день, к примеру, а уже после дня начинаем пересчитывать, типа, в часовые, короче, ведерочки там, и так далее, что, типа, у тебя теряется со временем, четкость, короче, и, такой случай, то есть, допустим, у тебя данные уже организованы, в часовые, а уже по минутные, уже, допустим, у тебя нет уже, так как вот тоже может быть, вот, и, но в целом, короче, что, да, несложно, короче, что многие вещи можно сделать, несложно, то есть, если, как бы, если у тебя данные сохранились, то ты их можешь по-разному промигрировать, пересчитать там, но будут такие случаи, когда невозможно это сделать.

вот смотри, допустим, у тебя работал отдел продаж, да, ты собирал по ним какие-то метрики, вот, и потом ты хочешь проверить такую гипотезу, типа, может быть, надо людям начинать звонить там не с 9 утра, да, а, например, с 11, давайте проверим гипотезу, что в 9 утра люди еще злые, там, еще едут на работу, занятые, им неудобно говорить, а, например, с 11 лучше, то есть, что надо сделать?

надо будет выбрать все звонки, там, допустим, с 9 до 11, да, и там с 11 до часу, да, и сравнить их эффективность, но раньше у нас не было такой метрики, как время звонка, и мы, возможно, эти данные когда-то хранили, но, возможно, они у нас уже склеены там по неделям, но я, ну вот, да, может, да, ты все верно говоришь, и тут, то есть, ну, простая система в теории, короче, да, что, допустим, если данные уже упакованы не по минуте, а по часу, а тебя интересует информация о том, что, допустим, в 9 или в 1 ты звонишь, то тебя, допустим, может устраивать детализация по часу, к примеру, она тебя, ты можешь пересчитать часовые данные, а можешь минутные пересчитать, если, допустим, твоя метрика позволяет такую четко-нечеткость, так сказать.

Да, но, например, ты говоришь, что ты хранишь данные определенное время, то есть, часовые данные ты хранишь в сутки, там, дневные данные ты хранишь в неделю, да, вот, и, допустим, у меня полгода уже проработал бизнес, и я вот только сейчас захотела посмотреть на эту метрику, то есть, у меня уже не будет этих данных, и мне придется какое-то время накапливать данные, чтобы посмотреть на эту метрику.

ну, наверное, с другой стороны, что система тоже гибкая получается, в теории, ты можешь не обязательно такие жесткие ограничения по времени вводить, да, что, может, допустим, она по размеру, допустим, ты платишь за какой-то объем базы данных, для статистики, если ты не влазишь, она начинает сама себя сжимать, там, ну, то есть, какие-то разные варианты есть, ты правильно размышляешь, что, допустим, по времени это, типа, самый простой пример, да, вот, может быть, мне придет в голову какая-то другая метрика, да, но ты, мне нравится, мне нравится, то есть, ты, получается, озвучила такую, как бы, задачку, которая, типа, вывести метрики из залагированных данных, типа, добавить их новые и рассегментировать старые данные, чтобы учесть, короче, ну, либо учесть эту метрику, либо их рассегментировать, согласно этой метрике тоже, допустим, то есть, грубо говоря, все метрики, они заранее существуют, но мы просто не можем их заранее все знать, то есть, в какой-то этап бизнеса, мы либо из-за каких-то событий внутри бизнеса, да, или из-за того, что мы становимся там умнее, или из-за того, что нам, ну, мы понимаем, что нам не хватает текущих, придумываем какие-то дополнительные метрики.

У меня аж мурашки по коже пошли, когда ты сказала, что все метрики уже существуют, мне нравится, как бы, но они существуют, ну, то есть, ну, они правда существуют, ты о них не знаешь.

Да, согласен. Окей. Просто, вот на этот момент, когда ты начинал делать бизнес, тебе не хватило твоего опыта ума, чтобы предусмотреть те вариации на будущее, что тебе может потребоваться.

Вот, короче, получается, статистика, это один из вот этих десяти столпов, короче, типа, вот эта вся концепция о том, как статистика устроена, это вот один, получается, из десяти баз, заповедей, короче, которые мы должны будем оформить, так скажем.

вот, и, ну, они будут со временем улучшаться, то есть, это как бы, как движущаяся цель, так скажем, да, что, смотри, а статистика, она, получается, должна собираться со всего интернета, или...

Нет, это с твоей системы, да, что, типа, ты, получается, у нас сейчас, а, девять еще минут у нас, надо гумить, короче, вся система, она обещает тебе, что она полностью может, она кастомная под твои нужды, да, что если ты пришла с чистого листа делать, то там никогда ничего не будет, чего бы ты не хотела, а это только будет там, если ты пользуешься, получается, возможностями LLM-а, генерировать контент, только тогда, ну, и, как бы, получается, проявлять свой искусственный интеллект, и оно только таким образом подсасывает данные извне, так скажем, да, что, типа, там не будет такое, что херакс у тебя там, что-то нарисовалось, как будто, что-то насчиталось само, короче, да?

Окей, то есть я говорю, типа, хочу построить отдел продаж, придумай мне метрики, и LLM идет в интернет и смотрит, какие самые частые метрики люди используют. Как бы, да, но это один из вариантов, что, типа, другой вариант, это, получается, мы, искать в интернете, оно, это надо только, если, получается, либо информации этой нету в LLM, хотя она там есть, потому что, то есть, вот это, короче, тут концепция, вот это есть латентное пространство, то есть, латентное пространство, это, это, грубо говоря, магический такой термин, который объясняет всю информацию, которая заложена уже в LLM, то есть, которая заложена была в тренировочных данных.

То есть, получается, А LLM не равно интернету всему? В итоге, вот именно что равно, да, что, типа, получается, там есть вся информация о том, как должны метрики создаваться. То есть, в теории, нам не надо сканировать интернет, для того, чтобы определить, ответить на вопрос, как устроить, типа, отдел для продаж.

уже эта информация там есть, но зависит от того, как мы задаем этот вопрос, чтобы эту информацию выковырить из LLM, да, что, допустим, по-разному задавая промп, допустим, мы можем сказать, какие современные новые подходы, типа, в текущем году, были придуманы для, делав продаж, да, тогда он говорит, окей, типа, у меня, я не, у меня там, отрыв данных, типа, я там, год больше, чем на год не знаю, надо покурсоваться в интернете, да, другое дело, это если у тебя уже есть, какой-то способ, направить сразу ответ в нужное русло, то есть, либо у тебя есть примеры, что у нас могут быть уже примеры, того, как метрики устроены, проектов, то есть, мы говорим, вот у нас есть уже 100 проектов, они, возможно, как бы, есть какие-то, ну, тут пересечения.

Другое дело... А вот смотри, секундочку, перебьем, вот, если ЛЛМ смотрит внутри себя, внутри интернета, в интернет же не всю информацию выкладывают, то есть, например, есть какая-нибудь корпорация, у нее есть какой-то успешный отдел продаж, и это обычно конфиденциальная инфа, которой нету в публичном доступе, то есть, это есть, может быть, в их внутренней сети, да, какой-то регламент где-то, вот, но широкий доступ, они не дали вот эту информацию.

Это может быть, и поэтому мы найдем такое, то, что мы можем найти, и поэтому я предлагаю сразу для начала, короче, для того, чтобы упростить концептуальное мышление, вообще не думать про интернет как таковой, что мы никогда не гуглим, мы все время достаем из латентного пространства, то есть, потому что мы пользуемся умной моделью, которая уже натренирована на интернете, мы можем правильно вопрос задать, правильно получить, и получается, то есть, ну, грубо говоря, вопрос мы зададим не то, что, как в последний год, типа, решают эту проблему, мы зададим вопрос, что, типа, используя нашу систему, о которой ты знаешь, как она устроена, из 10 заповедей, и учитывая вот этот промт человека, какую ты предложишь структуру статистики, да, то есть, он уже знает, что примерно от него хотят, потому что мы записали 10 заповедей о том, что там написано, как статистика устроена, как она используется, как это складывается в большую картину, плюс мы, получается, можем эту инструкцию, вот этот промт, о том, что, типа, загляни, типа, в информацию о том, как все устроено, и загляни в информацию, и в промт юзера, и, типа, и дай ответ, что еще между ними, может быть какие-то наставления, типа, когда человек просит тебя определить, для структуру статистики, учитывая там, какие-то, такие-то вещи, то есть, ему может быть еще промежуток, то есть, для каждой задачи, LLM, еще будет генерировать, сам, как бы, будет инструкция нагенерирована, которая двигает его, для того, чтобы более правильный ответ найти, вот, и поэтому, это еще одна возможность, как повлиять, короче, на результат, это то, что инструкция будет описана, что, типа, допустим, там будет набор инструкций, которые контекстуально могут накладываться, то есть, допустим, для больших коммерческих проектов, когда юзер просит тебя сформировать систему статистики, учитывая тот факт, что они, скорее всего, будут по отделам работать, на что, типа, это, получается, дополнительная информация, которая не относится, не к статистике, не к промпту юзера, а она, типа, инкапсулированная мудрость, получается, также, вот, про это, то, что ты говоришь, про то, что, допустим, есть какая-то компания, и они выработали свой подход к продажникам, да, и они могут, грубо говоря, для LLM-а написать инструкцию, как это устроено, чтобы он мог повторить эту логику, да, что, типа, когда, типа, тебя юзер спрашивает о том, что, типа, как устроить, типа, статистику, учитывай тот факт, что у нас в компании своя, типа, свой подход к продажникам, и вот он заключается в этом, понимаешь, да?

Получается, чем подробнее промпт, чем больше вводных ты дашь, тем точнее тебе будет ответ. Да, что, это, короче, мы называем, типа, повышением детерминированности, то есть, повышением предсказуемости, типа, есть несколько способов, как повысить предсказуемость, что ты можешь улучшить данные, которые ты кормишь, улучшить инструкцию, и, наверное, еще, ну, в общем-то, все, наверное, что, типа, либо ты, либо данные, либо инструкцию улучшаешь, типа, либо промпт, и, короче, от этого результат повышается, более предсказуемым становится.

И этим процессом, именно подготовки этих инструкций, может заниматься умная модель, которая, допустим, может тратить много ресурсов, для того, чтобы один раз выработать вот эту инструкцию, о том, как надо подходить к статистике внутри нашей компании.

допустим, допустим, она может потратить, допустим, 50 долларов, ну, к примеру, ты выделяешь 50 долларов на то, чтобы один раз и навсегда проработать эту инструкцию, и теперь LLM всегда ее использует, и всегда делает, короче, правильные решения.

Понимаешь, да? Вот, что в идеале, короче, что мы хотим, иметь такую возможность, чтобы на каждом шагу системы мы могли максимально увеличить предсказуемость.

То есть максимально предсказуемый шаг системы, это вообще, это программа, которая принимает вход, и выдает ответ, не используя никакого искусственного интеллекта, да?

Это, типа, максимально предсказуемое по формуле, допустим, какое-то, считает там решение, типа, экспертная система. Вот. Но есть еще промежуточные шаги, типа, приближение, короче, к этому, что, типа, ну, а самое, типа, начало, типа, максимальная непредсказуемость, это когда у тебя, нихрена у тебя нету, короче, вообще, и ты, ты говоришь, ну, сделай мне какую-нибудь систему статистики, ты знаешь, как оно устроено, сделай мне что-нибудь, давай попробуем.

Вот. И со временем, ты можешь улучшать любой из процессов, которые, ЛОН делает, улучшением этой инструкции. Вот. И что, типа, в теории, мы можем выстроить систему так, что, если она, система, получается, может, работать, сама отрабатывать эту инструкцию, собирать метрики, то ты можешь создать такую симуляцию, которая будет прогоняться, и сама себя улучшать, типа того, что в теории, короче, этот путь нам доступен.

Вот. И таким образом, мы, как бы, получается, можем сказать, что мы любую часть системы можем проработать и улучшить ее автономно. То есть, это, как бы, один из наших, типа, обещаний, как бы, нашей системы, что она может улучшаться в ответ на статистику без участия человека.

То есть, потому что, где-то в правилах мы опишем ей, что такое улучшение. Да, да, что, типа, мы формируем КПИ, и мы систему позволяем, типа, делать какие-то изменения и замерять КПИ, и, типа, пробовать разные вариации.

То есть, это один из ключевых моментов. И говорить, чтобы она сама пыталась придумывать новые КПИ для улучшения. да, да, и это в том числе. И потом изменения в процессе, чтобы улучшить КПИ, чтобы...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment